제품 동향
공용 이미지 업데이트 동향
운영 체제 공식 지원 종료 계획
제품 공지
TencentOS Server의 특징
클라우드 네이티브 시나리오에서, Namespace 및 Cgroup은 리소스 격리를 위해 기본 지원을 제공하였지만 컨테이너의 전체적인 격리 능력은 여전히 불완전합니다. 특히, /proc 및 /sys 파일 시스템에서 일부 리소스 통계가 컨테이너화되지 않아 컨테이너에서 실행되는 일부 일반적인 명령(예: free, top)이 컨테이너 리소스의 사용을 정확하게 표시하지 못합니다.
이 문제에 대응하여 TencentOS 커널은 컨테이너 리소스 표시를 개선하기 위해 cgroupfs 솔루션을 출시했습니다. cgroupfs는 업무에 필요한 컨테이너 관점에서 /proc 및 /sys 등과 같은 파일을 포함하는 가상 파일 시스템을 구현하며, 그 디렉토리 구조는 전체 procfs 및 sysfs와 일치하여 사용자 도구와의 호환성을 보장합니다. 이러한 파일을 실제로 읽을 때 cgroupfs는 독자 프로세스의 컨텍스트에서 해당 컨테이너 정보 뷰를 동적으로 생성합니다.
cgroupfs 파일 시스템 마운팅
1. cgroupfs 파일 시스템 마운팅을 위해 다음 명령을 실행합니다.
mount -t cgroupfs cgroupfs /cgroupfs/
캡쳐는 다음과 같습니다.
2.
-v 옵션을 사용하여 수요에 따라 cgroupfs 아래에 있는 파일을 지정 컨테이너로 마운팅하며, docker의 시작 명령은 다음과 같습니다.docker run -itd --cpus 2 --cpuset-cpus 0,1,2,4 -v/cgroupfs/sys/devices/system/cpu/:/sys/devices/system/cpu -v/cgroupfs/proc/cpuinfo:/proc/cpuinfo -v/cgroupfs/proc/stat:/proc/stat -v/cgroupfs/proc/meminfo:/proc/meminfo <image-id> /bin/bash
3. 이어서, 컨테이너 내에서 컨테이너 전용 시각의 cpuinfo, stat 및 meminfo 정보를 확인하였습니다.
pagecache 격리
프로세스 파일 페이지가 너무 많이 사용되면 많은 메모리를 점유하여 다른 업무의 가용 메모리가 줄어듭니다. 이 상황은 기계의 메모리 할당을 비효율적인 경로에 자주 빠뜨리고 메모리 부족(OOM) 오류를 일으키기 쉽습니다. 클라우드 네이티브 시나리오에서, 저희는 커널의 페이지 캐시(page cache)를 확장하여 컨테이너 페이지 캐시 사용량에 대한 제한(page cache limit)을 구현하여 특정 컨테이너의 페이지 캐시 사용량을 개별적으로 제한할 수 있습니다.
전체 pagecache 제한:
sysctl -w vm.memory_qos=1sysctl -w vm.pagecache_limit_global=1
echo x > /proc/sys/vm/pagecache_limit_ratio#(0 < x < 100) page cache limit 제한 활성화. 0이 아닌 경우, 예컨대 30이면 page cache가 시스템 총 메모리의 30%를 점유할 수 있도록 제한합니다.
Dirty page 회수 과정은 상대적으로 시간이 많이 소요됩니다.
pagecache_limit_ignore_dirty page cache 점유 메모리를 계산할 때 Dirty page를 무시할지 여부를 판단하는 데 사용됩니다. 그 위치는 다음과 같습니다./proc/sys/vm/pagecache_limit_ignore_dirty。기본값은 1로, Dirty page 무시를 의미합니다.
page cache의 회수 방식 설정:
/proc/sys/vm/pagecache_limit_async
1은 page cache 비동기 회수를 의미하며, TencentOS는 하나의 [kpclimitd] 커널 스레드를 생성하고, 이 스레드가 page cache의 회수를 담당합니다.
0은 동기 회수를 의미하며, 전용 회수 스레드를 생성하지 않고 직접 page cache limit 트리거를 위한 프로세스 컨텍스트에서 회수하며, 기본값은 0입니다.
컨테이너 pagecache 제한:
TencentOS는 전역 시스템급 pagecache 제한을 지원할 뿐만 아니라 컨테이너 레벨의 pagecache 제한도 지원하며, 사용 방식은 다음과 같습니다.
1. 메모리 QOS 활성화:
sysctl -w vm.memory_qos=1
2. 전역 pagecache 제한 비활성화:
sysctl -w vm.pagecache_limit_global=0
3. 컨테이너가 위치한 memcg로 들어가서 memory 제한을 설정합니다.
echo value > memory.limit_in_bytes
4. pagecache 최대 사용량을 현재 메모리 한계치에 대한 백분율(예: 10%)로 설정합니다.
echo 10 > memory.pagecache.max_ratio
5. pagecache 한도 초과 후의 회수 비율을 설정합니다.
echo 5 > memory.pagecache.reclaim_ratio
읽기/쓰기 통일 속도제한
Linux 커널의 고유 IO 속도제한 솔루션은 읽기/쓰기를 분리하는 방식에 따른 것으로, 이는 관리자가 업무 모델에 따라 IO 대역폭을 읽기/쓰기로 나누어 분할하고 속도제한을 각각 실시해야 하므로 대역폭 낭비의 문제가 존재합니다. 예컨대, 읽기 50MB/s, 쓰기 50MB/s로 구성된 경우, 실제 IO 대역폭이 읽기 20MB/s, 쓰기 50MB/s이면, 30MB/s의 읽기 대역폭이 낭비됩니다. 이 문제를 해결하기 위해, TencentOS는 읽기/쓰기에 대한 통일적인 속도제한 솔루션을 제공합니다. 이 솔루션은 사용자 모드에서 고객에게 읽기/쓰기 통일 속도제한을 위한 구성 인터페이스를 제공하며, 커널 모드에서는 업무 트래픽에 따라 읽기/쓰기 비율을 동적으로 분할합니다. 사용 방식은 다음과 같습니다.
업무에 대응되는 blkio가 위치한 cgroup에 들어간 후 echo MAJ:MIN VAL > FILE 구성을 사용합니다.
여기서 MAJ:MIN는 기기 번호를 나타내고 FILE 및 VAL은 아래 표에 나타낸 바와 같습니다.
FILE | VAL |
blkio.throttle.readwrite_bps_device | 읽기/쓰기 Bps 총 제한값 |
blkio.throttle.readwrite_iops_device | 읽기/쓰기 iops 총 제한값 |
blkio.throttle.readwrite_dynamic_ratio | 읽기/쓰기 비율 동적 예측: 0: 비활성화. 고정 비율(읽기:쓰기 - 3:1) 사용 1~5: 동적 예측 솔루션 활성화. |
buffer io 속도제한 지원
Linux 기본 커널에서 cgroup v1은 buffer IO 속도를 제한하는 측면에서 어느 정도의 결함이 존재합니다. Buffer IO Write Back은 일반적으로 하나의 비동기 과정이며, 커널이 Dirty page 비동기 리프레시 동작을 수행할 때 이 IO를 어느 blkio cgroup에 제출해야 할지를 결정할 수 없기 때문에 해당 blkio 속도제한 정책을 적용할 수 없습니다.
이를 바탕으로, TencentOS는 cgroup v1 아래에 있는 buffer IO 속도제한 기능을 추가로 보완하여 cgroup v2 기반의 buffer IO 속도제한 기능에 일치시켰습니다. cgroup v1에 대하여 하나의 사용자 모드 인터페이스를 제공하여 page cache가 속한 mem_cgroup과 해당 blkio cgroup을 바인딩함으로써 커널이 바인딩 정보에 따라 buffer IO에 대한 속도제한을 수행할 수 있도록 합니다.
1. buffer IO의 속도제한 기능을 사용하려면 kernel.io_qos 및 kernel.io_cgv1_buff_wb를 활성화해야 합니다.
sysctl -w kernel.io_qos=1 # IO QoS 특성 sysctl -w kernel.io_cgv1_buff_wb=1 열기 # Buffer IO 특성(기본적으로 활성화) 열기
2. 컨테이너의 buffer IO 속도제한을 위해, 컨테이너에 대응되는 memcg와 blkcg의 cgroup을 명시적으로 바인딩해야 하며, 그 방법은 다음과 같습니다.
echo /sys/fs/cgroup/blkio/A > /sys/fs/cgroup/memory/A/memory.bind_blkio
바인딩된 후, blkio cgroup에서 제공하는 컨테이너의 buffer IO 리소스에 대한 제한 메커니즘은 다음 인터페이스를 통해 조회할 수 있습니다.
blkio.throttle.read_bps_device
blkio.throttle.write_bps_device
blkio.throttle.write_iops_device
blkio.throttle.read_iops_device
blkio.throttle.readwrite_bps_device
blkio.throttle.readwrite_iops_device
비동기 fork
대용량 메모리 업무가 하위 프로세스를 생성하기 위해 fork 시스템을 호출할 때 fork 호출 프로세스가 상대적으로 오래 걸리기 때문에 업무가 오랫동안 커널 모드에 있고 업무 요청을 처리할 수 없게 됩니다. 따라서, 이 시나리오에 대해 커널의 fork 시간을 최적화하는 것이 특히 필요합니다.
Linux에서, 커널이 fork를 처리하는 기본 절차에서 상위 프로세스는 많은 양의 프로세스 메타데이터를 하위 프로세스에 복사해야 하며, 그중 페이지 테이블의 복사는 시간이 가장 많이 걸리는 부분으로 일반적으로 fork 호출 소요시간의 97% 이상을 차지합니다. 비동기 fork의 설계 아이디어는 페이지 테이블 복사 작업을 상위 프로세스에서 하위 프로세스로 옮기는 것이며, 이로써 상위 프로세스가 fork 시스템을 호출하고 커널 모드로 진입하는 시간을 단축시켜 앱이 최대한 빨리 사용자 모드로 돌아가 업무 요청을 처리할 수 있도록 함으로써 fork로 인한 성능 지터 문제를 해결합니다.
본 기능은
cgroup 를 통해 스위치를 제어합니다. 기본 사용법:echo 1 > \\<cgroup 디렉터리>/memory.async_fork #는 현재 cgroup 디렉터리를 위해 비동기 fork 기능을 활성화합니다. echo 0 > \\<cgroup 디렉터리>/memory.async_fork #현재 cgroup 디렉터리의 비동기 fork 기능을 비활성화합니다.
이 인터페이스의 기본값은 0이며, 즉 기본적으로 비활성됩니다.
피드백