Ubuntu에서 Cgroups를 사용하여 프로세스의 CPU 및 RAM 사용량을 제한하는 방법

Ubuntu에서 cgroups를 사용하여 작업 부하를 제한하는 가장 안전하고 일반적인 방법은 systemd가 제어 그룹을 생성하고 관리하도록 하는 것입니다. systemd-run현재 실행하는 명령에 적용하거나, 재시작 후에도 제한이 유지되어야 하는 경우 systemd 서비스를 구성하십시오. CPUQuota=CPU 시간 상한선을 설정하고, MemoryHigh=부하 제한을 위해 또는 MemoryMax=메모리 제한을 위해 둘 중 하나를 선택하십시오. 이러한 제한은 해당 장치와 자식 프로세스 모두에 적용됩니다.

cgroup(컨트롤 그룹)은 시스템이 프로세스의 리소스 사용량을 파악하고 제어할 수 있도록 프로세스를 구성하는 Linux 커널 메커니즘입니다. Ubuntu의 systemd는 이미 서비스를 cgroup에 배치하므로 대부분의 사용자는 /sys/fs/cgroup수동으로 디렉터리를 생성할 필요가 없습니다. 아래 예제는 systemd의 리소스 제어 인터페이스를 사용하며, 사용 중인 Ubuntu 버전에 설치된 systemd 버전에 따라 작동 여부를 확인해야 합니다.

문제에 맞는 대조군을 선택하십시오.

대부분의 대화형 Ubuntu 시스템에서는 임시 스코프가 가장 빠르고 되돌릴 수 있는 선택입니다. 프로덕션 서비스의 경우, 서비스 유닛을 사용하여 정책이 문서화되고 부팅 시 복원되도록 하십시오. 위임된 계층 구조를 의도적으로 관리하거나 컨테이너/런타임 워크플로를 구축하는 경우에만 직접 cgroup 파일을 사용하십시오.

제한을 설정하기 전에 우분투 시스템을 확인하십시오.

먼저 systemd가 사용 가능한지, 그리고 cgroup 파일 시스템이 통합 v2인지 확인하십시오.

systemctl --version
stat -fc %T /sys/fs/cgroup

두 번째 명령 의 결과는 cgroup2fs통합 cgroup v2 파일 시스템을 나타냅니다. Ubuntu 릴리스 및 사용자 지정 시스템은 다를 수 있으므로 모든 시스템의 계층 구조 또는 systemd 기능이 동일하다고 가정하지 마십시오. 첫 번째 명령을 사용하여 현재 systemd 버전을 확인할 수도 있습니다. cgroup 마운트가 v2가 아닌 경우 일부 리소스 속성이나 컨트롤러 동작이 다를 수 있습니다. 구성을 복사하기 전에 설치된 릴리스의 Ubuntu 설명서를 참조하십시오.

작업 부하를 측정한 후 값을 선택하십시오. 시스템의 나머지 부분을 위한 여유 공간을 확보하고, 사용자 서비스에 설정된 제한은 상위 슬라이스의 제한에도 영향을 받는다는 점을 기억하십시오. 하위 cgroup은 상위 cgroup이 허용한 것보다 더 많은 리소스를 받을 수 없습니다.

시작하려는 명령을 제한하세요

사용자 세션에서 명령을 실행하려면 `.`을 사용하여 임시 범위에서 실행하세요 systemd-run --user --scope. 예를 들면 다음과 같습니다.

systemd-run --user --scope --unit=worker-capped \
  -p CPUQuota=50% \
  -p MemoryHigh=700M \
  -p MemoryMax=900M \
  -- python3 /opt/worker.py

파이썬 명령어를 실제로 실행해야 하는 프로그램으로 바꾸세요. 이 예제는 cgroup에 CPU 대역폭을 최대 1개의 CPU 대역폭의 절반으로 설정하고, 메모리 사용량이 약 700MiB에 도달하면 메모리 부족 처리를 시작하며, 하드 메모리 최대 사용량을 900MiB로 설정합니다. 메모리 값은 systemd의 1024진수 단위를 사용합니다. 할당량은 100%최대 1개의 CPU에 해당하는 시간을 나타내며, 200%사용 가능한 경우 최대 2개의 CPU에 해당하는 시간을 사용할 수 있습니다. 이는 컴퓨터 전체 코어의 백분율을 의미하는 것이 아닙니다.

이 명령은 스코프이기 때문에 포그라운드에서 실행됩니다. 명령이 종료되면 임시 유닛이 사라집니다. --user시스템 관리자를 사용하고 필요한 권한이 있는 경우에만 제거하십시오. 시스템 전체에 적용되는 임시 유닛을 사용하려면 해당 명령 옵션을 사용하여 명령을 실행하십시오 sudo. 관리자 또는 cgroup 컨트롤러가 지원하지 않는 리소스 설정은 거부될 수 있습니다.

지속적인 systemd 서비스에 대한 제한을 설정하세요

와 같은 서비스의 경우 worker.service, 공급업체 단위 파일을 편집하는 대신 드롭인 파일을 생성하세요. 다음 명령을 실행 sudo systemctl edit worker.service하고 추가하세요.

[Service]
CPUQuota=50%
MemoryHigh=700M
MemoryMax=900M

드롭인 파일을 저장한 다음 systemd의 유닛 정의를 다시 로드하고 서비스를 재시작하여 수정된 정책에 따라 프로세스가 시작되도록 하십시오.

sudo systemctl daemon-reload
sudo systemctl restart worker.service

메모리 상한선을 신중하게 설정하십시오. 서비스가 설정된 메모리 용량 이하로 충분한 메모리를 확보하지 못하면 MemoryMax커널이 해당 cgroup 내에서 메모리 부족으로 인한 프로세스 종료를 유발하는 프로세스를 호출할 수 있습니다. 이로 인해 서비스 그룹 내 하나 이상의 프로세스가 종료되고 작업이 중단될 수 있습니다. 안전한 방법은 MemoryHigh메모리 회수 및 스로틀링이 허용 가능한 수준으로 메모리 용량을 설정한 다음, MemoryMax최종 경계값으로 더 높게 설정하는 것입니다. 엄격한 메모리 제한을 적용하기 전에 실제 최대 부하 환경에서 테스트하십시오.

장치를 확인하고 작동 방식을 관찰하십시오.

과도 현상 범위의 경우, 제공하신 단위 이름을 사용하여 상태를 확인하십시오.

systemctl --user status worker-capped.scope
systemd-cgtop

시스템 서비스의 경우 --user상태 명령에서 생략합니다. 상태 보기에서는 장치가 존재하고 활성화되어 있음을 확인할 수 있으며, systemd-cgtop제어 그룹별 실시간 리소스 사용량을 보여줍니다. 구성된 속성을 검사하려면 장치를 직접 쿼리하십시오. 예를 들면 다음과 같습니다.

systemctl --user show worker-capped.scope \
  -p CPUQuotaPerSecUSec -p MemoryHigh -p MemoryMax

cgroup에 대해 보고되는 메모리 양은 개별 프로세스의 상주 메모리 양과 반드시 ​​일치하는 것은 아닙니다. 보고되는 메모리 양은 해당 그룹에 할당된 메모리를 포함하며, 워크로드의 하위 프로세스까지 포함할 수 있습니다. 따라서 모니터링 결과는 워크로드가 시간에 따라 어떻게 변화하는지 보여주는 증거로 활용해야 하며, 단순히 하나의 수치에 의존하여 최적화해서는 안 됩니다.

만약 해당 프로세스가 이미 실행 중이라면 어떻게 해야 할까요?

systemd-run새로운 단위 내에서 새로운 명령을 시작합니다. 임의의 기존 PID를 가져와 해당 범위로 이동시키지는 않습니다. 프로세스가 systemd 서비스에 속하는 경우, 드롭인 파일을 사용하여 해당 서비스에 설정을 적용하거나, 임시 변경을 위해 를 사용하십시오 sudo systemctl set-property --runtime worker.service CPUQuota=50% MemoryHigh=700M MemoryMax=900M. 이 --runtime형식은 임시적인 것이며 영구적인 서비스 구성을 대체하지 않습니다.

데스크톱 세션에서 실행되는 일반 프로그램이라면, 안전하고 간단한 방법은 보통 해당 프로그램을 종료하고 다시 실행하는 것입니다 systemd-run. 사용자 영역 전체와 같이 더 넓은 영역에 속성을 적용하면 관련 없는 여러 응용 프로그램에 영향을 미칠 수 있습니다. 프로세스 ID(PID)를 cgroup 파일에 기록하여 프로세스를 이동하려면 관련 위임 계층 구조를 제어해야 하며 cgroup v2 프로세스 배치 규칙을 준수해야 합니다. systemd로 관리되는 디렉터리에 임의로 기록하지 마십시오.

CPU 및 메모리 정책을 선택하는 방법

• CPU 사용량 상한선을 엄격하게 설정해야 합니까? 값 을 선택하세요 CPUQuota=. 값이 낮을수록 CPU 최대 사용량은 줄어들지만, 작업 완료 속도가 느려지고 대기 시간이 길어질 수 있습니다.
• 낮은 우선순위만 필요하신가요? 할당량 대신 가중치를 고려해 보세요 CPUWeight=. 가중치는 CPU 사용률 경쟁 시 CPU를 상대적으로 분배하며, 고정된 비율을 예약하거나 유휴 CPU 사용을 막지 않습니다.
• 즉각적인 하드 스톱 없이 메모리 압박이 필요한가요?MemoryHigh= 이를 주요 압박 임계값으로 설정하고 지연 시간 및 메모리 회수 동작을 관찰하세요.
• 최종 격리 경계가 필요하신가요? 일반적인 피크를 고려하여 충분한 여유 공간을 확보하세요 MemoryMax=. 경계를 준수할 수 없는 경우 메모리 부족(OOM) 오류가 발생할 수 있으므로 이에 대비하십시오.
• 이미 컨테이너를 사용 중이신가요? 그렇다면 컨테이너 관리자가 지원하는 CPU 및 메모리 플래그를 사용하는 것이 좋습니다. 이 플래그는 해당 컨테이너에 맞게 cgroup을 구성하고 컨테이너의 수명 주기에 적합하게 설정합니다.

모든 작업 부하에 적합한 이상적인 제한값은 없습니다. 데스크톱 배치 작업은 낮은 할당량과 적당한 메모리 제한으로도 충분할 수 있지만, 지연 시간에 민감한 서비스는 CPU 여유 공간이 더 필요하고 MemoryHigh메모리 회수 관련 일시 중단을 방지하기 위해 더 높은 할당량이 요구될 수 있습니다. 처음에는 보수적으로 시작하고, 대표적인 최대 부하 시점에 장치를 모니터링한 후, 한 번에 하나의 설정만 조정하십시오.

참고 자료

• Ubuntu 문서: cgroups 및 systemd 리소스 제어
• Ubuntu 매뉴얼 페이지: systemd-run
• Ubuntu 매뉴얼 페이지: systemd.resource-control
• Linux 커널 문서: 제어 그룹 v2