리눅스 서버 워크로드 최적화를 위한 튜닝 프로필

서버 워크로드 최적화를 위한 튜닝 프로필

리눅스의 기본 설정은 성능이 아닌 호환성을 위해 조정되어 있습니다. tuned 데몬은 특정 워크로드에 맞춰 CPU 거버너, I/O 스케줄러, 커널 매개변수 및 네트워크 버퍼를 조정하는 사전 정의된 프로필을 제공합니다. 이 게시물에서는 프로필의 작동 방식, 일반적인 서버 역할에 적합한 프로필 선택 방법, 그리고 서버 군 전체에 사용자 지정 프로필을 구축하고 배포하는 방법을 다룹니다.

튜닝된 프로필의 작동 방식

프로필은 /usr/lib/tuned/profiles/ (system) 또는 /etc/tuned/profiles/ (사용자 정의) 아래에 위치한 디렉터리로, tuned.conf 파일이 들어 있는 디렉터리입니다. 이 conf 파일은 매개변수를 플러그인별로 그룹화합니다: [cpu], [disk], [sysctl], [vm], [bootloader]등과 같이 그룹화합니다. 프로필을 활성화하면 tuned 데몬은 수십 개의 sysctl 명령을 sysfs 명령을 수동으로 실행하는 대신, 모든 매개변수를 한 번에 적용합니다.

프로필은 include 지시어를 사용하여 서로 상속받을 수 있습니다. 예를 들어, throughput-performance 예를 들어, profile은 vm.swappiness Transparent Huge Pages 설정만 재정의하는 사용자 정의 데이터베이스 프로파일의 기반으로 사용할 수 있습니다.

tuned는 두 가지 모드로 실행됩니다. 정적 튜닝은 활성화 시 프로필을 한 번 적용한 후 시스템에 간섭하지 않는데, 이는 전력 절약보다 일관성이 더 중요한 프로덕션 서버에서 바람직한 방식입니다. 동적 튜닝은 디스크, 네트워크 및 부하 사용량을 실시간으로 모니터링하며 설정을 즉시 조정합니다. 성능 프로필은 모니터링 오버헤드를 피하기 위해 기본적으로 동적 튜닝을 비활성화합니다.

워크로드에 적합한 프로필 선택

tuned는 가장 일반적인 워크로드를 포괄하는 12가지 프로필을 제공합니다. 기본 balanced 프로필을 그대로 두지 말고, 서버가 실제로 수행하는 작업에 맞는 프로필을 선택하십시오.

특정 데이터베이스 엔진의 경우, tuned에는 다음도 함께 제공됩니다 postgresql, mssql, 그리고 oracle 해당 엔진에 대한 공유 메모리 및 커널 스케줄러 매개변수를 조정함으로써 throughput-performance 해당 엔진에 대한 공유 메모리 및 커널 스케줄러 매개변수를 조정하여

다중 소켓 서버에서는 NUMA 토폴로지가 중요합니다. 원격 노드 메모리 액세스는 로컬 액세스보다 2~3배 더 느릴 수 있습니다. 듀얼 소켓 시스템에서 지연 시간이 중요한 워크로드의 경우, 프로필에서 자동 NUMA 균형 조정을 비활성화하고 프로세스를 특정 노드에 수동으로 고정하십시오.

프로필 설치 및 적용

RHEL, Rocky, AlmaLinux 또는 Fedora에 tuned 설치:

dnf install tuned
systemctl enable --now tuned

Debian 및 Ubuntu에서도 해당 패키지는 tuned 라고도 불리며, 다음 명령어를 통해 설치할 수 있습니다 apt를 통해 설치됩니다. 만약 power-profiles-daemon 이미 실행 중이라면, 충돌을 방지하기 위해 해당 프로세스를 일시 중지하십시오:

systemctl mask --now power-profiles-daemon

사용 가능한 프로필을 나열하고, 해당 하드웨어에 대해 tuned가 권장하는 프로필을 확인한 후, 프로필을 적용하고 정상 작동 여부를 확인하십시오:

tuned-adm list
tuned-adm recommend
tuned-adm profile throughput-performance
tuned-adm verify

활성 프로필은 /etc/tuned/active_profile 에 저장되며 재부팅 후에도 유지됩니다. 튜닝을 완전히 제거하고 기준값을 측정하려면 다음 명령을 실행하십시오: tuned-adm off.

AI, ML 및 고대역폭 워크로드를 위한 맞춤형 프로필 구축

기본 프로필로 90% 정도가 해결된다면, 가장 유사한 프로필을 상속받으면서 나머지 매개변수는 재정의하는 사용자 지정 프로필을 구축하십시오. 디렉터리와 conf 파일부터 시작하십시오:

mkdir -p /etc/tuned/ai-gpu
cat > /etc/tuned/ai-gpu/tuned.conf <<'EOF'
[main]
summary=Custom profile for GPU training with high-bandwidth networking
include=accelerator-performance
 
[cpu]
governor=performance
 
[sysctl]
kernel.numa_balancing=0
net.core.rmem_max=268435456
net.core.wmem_max=268435456
net.ipv4.tcp_rmem=4096 87380 268435456
net.ipv4.tcp_wmem=4096 65536 268435456
 
[vm]
transparent_hugepages=never
 
[bootloader]
cmdline=hugepagesz=2M hugepages=16384 <a target="_blank" rel="noopener noreferrer" href="https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit">iommu</a>=pt
EOF
 
tuned-adm profile ai-gpu

여기서 중요한 설정은 다음과 같습니다:

• numa_balancing=0 이 옵션은 훈련 실행 중 커널이 소켓 간에 메모리를 이동하는 것을 방지하며, 이는 듀얼 소켓 GPU 시스템에서 흔히 발생하는 성능 저하의 원인입니다.
• 이 rmem_max 및 tcp_rmem 값은 소켓 버퍼 상한을 256MB로 높입니다. 훈련 노드 간 25G, 40G 또는 100G 상호 연결의 경우, 기본 버퍼 크기는 처리량을 라인 속도보다 훨씬 낮은 수준으로 제한합니다.
• transparent_hugepages=never 는 큰 텐서를 할당하는 PyTorch 및 TensorFlow와 같은 프레임워크에서 THP가 유발하는 지연 시간 지터를 제거합니다.
• iommu=pt 는 IOMMU를 패스스루 모드로 설정하며, 이는 GPU 및 NIC 패스스루에 필요하고 베어메탈 DMA의 오버헤드를 줄여줍니다.

다음보다 작은 값은 [bootloader] 재부팅이 필요합니다. 프로필을 활성화한 후, tuned-adm verify 를 실행하여 런타임 매개변수가 적용되었는지 확인하고, journalctl -u tuned 오류가 있는지 확인하십시오. 다음을 사용하여 활성화 전후의 벤치마크를 수행하십시오 iostat -xz, numastat및 관련 워크로드 도구(iperf3, fio, 또는 실제 훈련 실행)을 사용하여 벤치마크를 수행하십시오.

명확히 짚어둘 만한 절충점이 하나 있습니다. CPU 보안 완화 기능을 비활성화하면 GPU 워크로드에서는 약 3~8%의 성능 향상을 얻지만, 시스템 호출 패턴이 빈번한 워크로드에서는 15~30%의 성능 저하를 초래합니다. 해당 시스템의 위협 모델을 고려하여 결정하십시오. 방화벽 뒤의 전용 훈련 클러스터 내에서는 일반적으로 이를 비활성화하는 것이 더 유리합니다. 다중 테넌트 호스트에서는 해당 기능을 켜두십시오.

서버 군 전반에 걸친 프로필 관리

서버가 몇 대를 넘어서면 수동으로 `tuned`를 적용하는 것은 더 이상 실용적이지 않습니다. Ansible은 이를 깔끔하게 처리합니다. 하나의 플레이북으로 `tuned`를 설치하고, /etc/tuned/ 를 통해 template 모듈을 통해 해당 디렉터리에 사용자 정의 프로필 디렉터리를 생성하고, 인벤토리 그룹별로 적절한 프로필을 적용합니다.

인벤토리 내 역할에 프로필 매핑:

• GPU 및 AI 노드: accelerator-performance, 또는 이를 상속하는 사용자 정의 프로필
• 데이터베이스 서버: throughput-performance 또는 엔진별 프로필
• 대용량 트래픽을 전송하는 CDN 및 엣지 노드: network-throughput
• 로드 밸런서 뒤에 위치한 API 및 웹 서버: network-latency
• VPS 및 KVM 게스트: virtual-guest
• 하이퍼바이저 호스트: virtual-host

설정 편차(drift)가 실제 운영상의 문제입니다. 수동 sysctl 변경, 새로운 기본값을 포함하는 패키지 업그레이드, 또는 다른 구성 관리 도구가 ‘tuned’와 충돌하는 경우 등은 모두 설정이 프로필에 명시된 내용과 달라지게 만듭니다. Ansible 작업을 예약하여 tuned-adm active 그리고 tuned-adm verify 실행되도록 Ansible 작업을 예약하고, 실패 시 경고를 설정하세요. /var/log/tuned/tuned.log "Verification failed"라는 메시지가 있는지 주의 깊게 살펴보세요.

결론

tuned는 커널 및 sysctl 튜닝 과정에서 발생하는 추측 작업을 대부분 제거해 줍니다. 기본 설정만으로도 일반적인 용도에는 충분하며, accelerator-performance, throughput-performance, 그리고 network-throughput 와 같은 워크로드별 프로필을 사용하면 구성 파일을 하나도 작성하지 않고도 최적화에 거의 근접할 수 있습니다.

• 가장 유사한 기본 프로필을 선택하고 tuned-adm verify를 실행한 뒤 벤치마크를 수행하세요
• 기본 프로필을 상속받아 필요한 부분만 재정의하여 사용자 정의 프로필을 구축하세요
• GPU 및 고대역폭 시스템에서 NUMA 균형 조정, hugepages, 네트워크 버퍼 크기를 신중하게 설정하십시오
• Ansible을 사용하여 배포하고, 일정대로 감사를 수행하여 설정 편차를 파악하십시오

이러한 설정을 실제로 활용하기 위해 대역폭 여유 공간이 확보된 베어메탈 인프라가 필요하신가요? 높은 처리량 및 GPU 워크로드를 위해 구축된 전용 서버에 대해 FDC에 문의해 보세요.