리눅스 커널 최적화 및 지연 시간 감소를 위한 고급 가이드

인포매텍 디지털 » Recursos » 리눅스 커널 최적화 및 지연 시간 감소를 위한 고급 가이드

리눅스 성능에 대해 이야기할 때, 거의 모든 것이 결국 같은 점을 가리킵니다. 바로 지연 시간, 안정성, 리소스 사용량을 제어하는 ​​핵심 요소인 커널입니다 . 커널을 세밀하게 조정하면 서버, 데스크톱, 클라우드 환경, 심지어 아주 오래된 하드웨어 에서도 시스템이 그저 그런 수준으로 작동하는 것과 원활하게 반응하는 것 사이의 차이를 만들어낼 수 있습니다.

이 가이드는 보안이나 유지보수성을 저해하지 않으면서 지연 시간을 최소화하도록 Linux 커널을 최적화하는 방법에 중점을 둡니다. 기본적인 아키텍처 개념부터 sysctl을 사용한 최적화, 사용자 정의 커널 컴파일, 실시간 패치 적용, 저지연 네트워크(예: EC2)에 맞춘 튜닝, 그리고 최적화가 실제로 성능을 향상시키는지 측정하는 모니터링 및 벤치마킹 기법까지 모든 것을 다룹니다.

리눅스 커널 아키텍처와 지연 시간 관련 주요 사항

리눅스 커널은 애플리케이션과 하드웨어 사이의 중간 계층 역할을 하며 메모리, 프로세스, 인터럽트, 드라이버 및 파일 시스템을 관리합니다 . 모듈식 설계 덕분에 전체 시스템을 다시 컴파일하지 않고도 기능을 유연하게 활성화하거나 비활성화할 수 있습니다.

지연 시간의 원인을 파악하려면 프로세스 스케줄러 , 메모리 관리, 인터럽트 처리와 같은 여러 하위 시스템을 이해하는 것이 중요합니다. 스케줄러 설정이 잘못되었거나, 메모리 정책이 지나치게 공격적이거나, 제어되지 않는 인터럽트가 과도하게 발생하면 강력한 하드웨어에서도 응답 속도가 느려질 수 있습니다.

CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY, CONFIG_SMP와 같은 커널 구성 옵션이 중요한 역할을 합니다 . 이러한 옵션은 커널이 더 긴급한 작업을 처리하기 위해 선점될 수 있는 정도와 멀티코어 시스템을 처리하는 방식을 결정합니다. 적절한 선점 모델을 선택하면 데스크톱, 저지연 서버 또는 산업 시스템에서 체감되는 지연 시간이 크게 달라집니다.

최신 서버에서는 하드웨어 토폴로지 또한 중요합니다. 코어 분배, 소켓, NUMA, 캐시 계층 구조 등이 여기에 포함됩니다. CPU 선호도와 NUMA 정책(예: 프로세스와 메모리를 동일한 노드에 할당)을 세밀하게 조정하면 액세스 시간을 단축하고 캐시 적중률을 향상시킬 수 있으며, 이는 지터와 예측 불가능한 지연 시간을 최소화하는 데 매우 중요합니다.

또한 CPU 스케줄러와 I/O 서브시스템(디스크 및 네트워크) 간의 상호 작용은 애플리케이션이 경험하는 엔드 투 엔드 처리량과 지연 시간을 결정합니다 . 변경 작업을 수행하기 전에 현재 상태(커널 구성, sysctl, GRUB, 로드된 모듈)를 문서화하여 변경으로 인해 성능이 저하될 경우 신속하게 롤백할 수 있도록 하는 것이 좋습니다.

sysctl을 통한 조정으로 지연 시간과 성능을 개선합니다.

sysctl 인터페이스를 사용하면 /proc/sys를 통해 커널 매개변수를 재컴파일 없이 즉시 수정할 수 있습니다 . 컴파일 과정에 얽매이지 않고 튜닝을 시작할 수 있는 이상적인 진입점입니다.

네트워크 환경에서 net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_congestion_control과 같은 매개변수는 처리량, 지연 시간 및 TCP 연결 동작에 직접적인 영향을 미칩니다. 트래픽이 많은 웹 서버나 저지연 클라우드 인스턴스의 경우 버퍼와 혼잡 제어 알고리즘을 적절히 조정하는 것이 매우 중요합니다.

메모리의 경우, vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure, vm.overcommit_memory와 같은 값을 사용하여 스왑 사용량, 페이지 캐시 관리 방식, 가상 메모리 동작 방식을 제어할 수 있습니다. swappiness 값을 낮추면(예: 10) 시스템이 스왑을 너무 자주 사용하는 것을 방지하여 디스크 I/O로 인한 지연 시간 급증을 줄이는 데 도움이 됩니다.

대규모 데이터베이스나 대량의 공유 메모리를 사용하는 애플리케이션을 개발하는 경우, kernel.shmmax, kernel.shmall , 그리고 fs.file-max 및 fs.nr_open을 사용하여 열 수 있는 최대 파일 수를 적절히 조정하는 것이 매우 중요합니다 . 제한 값을 잘못 설정하면 부하가 걸린 상태에서 진단하기 어려운 병목 현상과 오류가 발생할 수 있습니다.

작은 변경 사항부터 적용하고 모니터링 도구를 사용하여 그 영향을 측정한 다음, /etc/sysctl.conf 또는 /etc/sysctl.d/ 에 커밋하는 것이 좋습니다 . 컨테이너 환경에서는 많은 커널 매개변수가 호스트 전체에 전역적으로 적용된다는 점을 기억해야 합니다. 부주의한 수정은 모든 서비스에 영향을 미칠 수 있으므로 sysctl을 cgroups 및 네임스페이스와 함께 사용하는 것이 거의 필수적입니다.

사용자 정의 커널 컴파일 및 유지 관리

사용자 지정 커널을 컴파일하는 것은 지연 시간을 줄이거나, 불필요한 오버헤드를 제거하거나, 특수한 하드웨어를 지원 하려는 경우 여전히 강력한 도구입니다 . 배포판에는 상당히 다재다능한 커널이 포함되어 있지만, 특정 시나리오에서는 특정 커널이 결정적인 차이를 만들어낼 수 있습니다.

기존 워크플로는 다음에서 코드를 다운로드하는 것을 포함합니다. kernel.org 또는 xanmod와 같은 패치된 트리 또는 리쿼릭스그리고 다음과 같은 도구를 사용하세요 make menuconfig 옵션을 선택할 수 있습니다. .config 파일을 빌드 스크립트와 함께 자체 Git 저장소에 저장하면 빌드를 재현하고 버전 간 일관성을 유지할 수 있습니다.

데비안이나 그 파생 배포판을 사용한다면, 커널, 헤더 파일 및 관련 라이브러리의 .deb 패키지를 얻기 위해 " 데비안 방식 "으로 컴파일하는 것이 매우 편리합니다. 이렇게 하면 패키지를 설치하고 자체 저장소를 사용하여 버전을 관리하는 것만으로 여러 대의 컴퓨터에 사용자 지정 커널을 배포할 수 있습니다.

실제 환경에서는 오래되었거나 성능이 매우 제한적인 하드웨어를 사용할 때 수동 컴파일이 유용한 경우가 많습니다 . 대표적인 예로 Atom CPU와 1GB RAM을 탑재한 구형 넷북을 들 수 있는데 , 이러한 환경에서는 불필요한 드라이버와 서버급 옵션으로 가득 찬 최신 범용 커널을 사용하면 지연 시간과 과도한 CPU 사용량이 발생하여 감당하기 어렵습니다.

일반적인 전략은 현재 커널 구성(예: /boot에서 구성 파일을 복사)에서 시작하여 다듬거나 조정하는 것입니다. 데스크톱의 대화형 응답을 우선시하려면 선점 모델을 " 선점형 커널(저지연 데스크톱) " 로 변경하거나 , 기계식 디스크에서의 사용자 경험을 개선하기 위해 BFQ 와 같은 특정 I/O 스케줄러를 모듈로 추가할 수 있습니다.

컴파일에 오랜 시간을 소모하지 않으려면 더 강력한 컴퓨터에서 빌드하고, 필요한 경우 크로스 컴파일을 사용하는 것이 좋습니다 (예를 들어, ARCH와 해당 툴체인을 조정하여 x86_64 PC에서 Atom용 32비트 커널을 컴파일하는 경우). 그런 다음 대상 컴퓨터에 .deb 파일을 설치하고 GRUB에 적절한 항목을 추가하기만 하면 됩니다.

까다로운 부분은 유지 관리입니다. 카나리아 제도 노드에서 새 커널을 테스트하고 , 부트 관리자에 명확한 롤백 경로를 설정하고, 전환 중에 로그와 메트릭을 기록하여 성능 저하 또는 드라이버 호환성 문제를 감지하는 것이 좋습니다 .

저지연 시스템을 위한 선점 모델 및 PREEMPT_RT 패치

커널의 선점 모델은 우선순위가 높은 작업이 실행을 인계받을 수 있도록 실행 중인 작업을 얼마나 자주 중단할 수 있는지를 결정하며, 이는 응답 지연 시간에 직접적인 영향을 미칩니다 . 여기에는 표준 구성 옵션과 실시간 패치가 모두 포함됩니다.

일반 커널은 여러 옵션을 제공합니다. 선점 없음(서버 처리량에 더 중점), 자발적 선점, 그리고 데스크톱용 선점 가능 커널이 있으며 , 데스크톱용 선점 가능 커널은 대화형 애플리케이션의 빠른 응답 시간을 우선시합니다. 이 설정을 조정하면 데스크톱 시스템, 오디오 애플리케이션, 심지어 구형이거나 부하가 많이 걸린 컴퓨터의 성능을 크게 향상시킬 수 있습니다.

보다 강력한 성능이 필요할 때, PREEMPT 및 PREEMPT_RT 패치가 등장하여 커널의 중요한 부분을 수정함으로써 선점 불가능한 영역을 최소화합니다. PREEMPT_RT는 최악의 경우 지연 시간(평균 지연 시간뿐 아니라)이 매우 낮고 예측 가능해야 하는 시스템, 예를 들어 산업 자동화, 전문 오디오, 통신 또는 고빈도 거래 시스템에 적합합니다.

PREEMPT_RT 도입 여부는 트렌드에 기반하기보다는 지연 시간과 지터에 대한 구체적인 측정값을 바탕으로 결정해야 합니다 . 우선, RT 트리를 추가하여 유지 관리를 복잡하게 만들기 전에 스케줄러 설정, CPU 선호도, sysctl, 그리고 가능하다면 동적 틱리스(dynamic tickless)와 같은 설정을 충분히 검토하는 것이 좋습니다.

호환성 또한 고려해야 할 사항입니다. 일부 드라이버와 서브시스템은 RT에 완전히 최적화되어 있지 않아 특정 버전이나 추가 패치가 필요할 수 있습니다. 따라서 주기적으로 동기화되지만 여전히 다소 지연되는 RT 브랜치에 메인 커널의 새 버전을 언제 어떻게 통합할지 명확하게 명시한 유지 관리 계획을 수립하는 것이 현명한 접근 방식입니다.

CPU 스케줄링 튜닝, 틱리스 동작 및 코어 격리

선점 모델을 선택하는 것 외에도, 특히 RHEL과 같은 기업용 배포판에서는 CPU 스케줄링 및 커널 타이머 동작을 조정하여 지연 시간을 세밀하게 조정할 수 있습니다.

예를 들어 Red Hat Enterprise Linux 8은 유휴 CPU에 대해 기본적으로 틱리스 커널을 제공합니다 . 이 커널은 유휴 상태일 때 주기적인 인터럽트를 방지하여 전력 소비를 줄입니다. 지연 시간에 민감한 워크로드의 경우, 여러 커널에 대해 동적 틱리스 모드를 활성화할 수 있습니다 . 이렇게 하면 하나의 CPU("홈 커널")만 대부분의 타이밍 작업을 처리하고 나머지는 주기적인 인터럽트로부터 최대한 자유롭게 유지됩니다.

이 설정은 적절한 매개변수를 추가하여 수행됩니다. GRUB의 커널 명령줄구성을 다시 생성한 다음 RCU 스레드 또는 기타 스레드와 같은 중요 커널 스레드의 선호도를 조정합니다. bdi-flush그래서 유지보수를 위해 마련된 핵심 공간에 위치하게 됩니다.

이 접근 방식은 `isolcpus` 매개변수를 통해 보완할 수 있으며 , 이를 통해 코어를 일반 사용자 공간 작업과 격리할 수 있습니다. 저지연 시나리오에서는 중요한 애플리케이션 전용으로 여러 코어를 예약하고 나머지 시스템 기능(데몬, 인터럽트 등)은 다른 코어에서 처리하는 것이 일반적입니다.

동적 틱리스 모드가 제대로 작동하는지 확인하려면 간단한 테스트를 실행할 수 있습니다. stress 또는 CPU를 잠시 동안 바쁘게 유지하고 관찰하는 스크립트 타이머 틱 카운터 개별 코어에서 초당 인터럽트 횟수가 수천 건에서 단 한 건으로 줄어드는 현상은 주기적 타이머가 사라졌음을 나타내는 신호입니다.

지연 시간에 중점을 둔 메모리 및 스토리지 관리

커널이 메모리와 디스크 I/O를 관리하는 방식은 애플리케이션 , 특히 작고 빈번한 작업을 많이 수행하는 데이터베이스 및 서비스에서 체감되는 지연 시간에 큰 영향을 미칩니다.

메모리 측면에서 vm.swappiness 값을 줄이면 스왑 사용량(거의 항상 RAM보다 훨씬 느림)이 최소화되고, vm.vfs_cache_pressure는 시스템이 inode 및 dentry 캐시를 해제해야 하는 속도를 제어하며, vm.nr_hugepages를 사용하면 데이터베이스나 JVM과 같이 부하가 많은 작업을 위해 정적 HugePages를 예약하여 TLB 오버헤드를 줄일 수 있습니다.

보관 시 선택하세요 디스크 유형에 따라 적절한 I/O 스케줄러를 사용합니다. 이건 매우 중요합니다. 최신 SSD에서는 일반적으로 다음과 같은 방법을 사용하는 것이 좋습니다... none o mq-deadline반면 기계식 디스크와 멀티태스킹 시스템에서는 공정성을 고려하여 설계된 알고리즘이 더 나을 수 있습니다. 예를 들어, 바베큐또한, 다음과 같은 옵션을 사용하여 파일 시스템을 마운트할 수 있습니다. noatime y nodiratime 파일이나 디렉토리에 접근할 때마다 불필요한 쓰기 작업을 피하십시오.

파일 시스템으로는 ext4와 XFS가 여전히 가장 일반적인 선택입니다. 잘 최적화된 ext4는 안정적인 성능을 제공하며, XFS는 높은 동시 접속 환경에서 확장성이 뛰어납니다. 매우 까다로운 시나리오에서는 RAID(데이터베이스용 RAID 10, 임시 스크래치 스토리지용 RAID 0)와 우수한 스케줄러를 조합하여 평균 지연 시간과 특히 변동성을 줄일 수 있습니다.

Linux 및 EC2 환경에서 지연 시간을 줄이기 위한 네트워크 및 커널 최적화

고성능 네트워킹 애플리케이션에서 지연 시간은 하드웨어나 거리뿐만 아니라 TCP/IP 스택과 커널 자체의 구성 방식 에도 영향을 받습니다 . 이는 특히 ENA 인터페이스를 사용하는 Amazon EC2와 같은 클라우드 인스턴스에서 두드러지게 나타납니다.

우선, 패킷이 거치는 네트워크 홉 수와 같은 외부 요인을 줄이는 것이 중요합니다 . 보다 직접적인 토폴로지를 사용하거나, 백엔드에 가까운 로드 밸런서를 사용하거나, 최적화된 가용성 영역을 구축하면 운영 체제에 도달하기 전에 패킷 이동 시간을 밀리초 단위로 단축할 수 있습니다.

커널 내부에서 네트워크 구성은 파일 디스크립터 증가(ulimit -n) , net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem 을 사용하여 수신 및 송신 버퍼 크기 조정 , 그리고 연결 설정 지연 시간을 줄이기 위해 TCP Fast Open 과 같은 옵션 활성화 등을 포함합니다.

AWS ENA 인터페이스에서 인터럽트 조절은 중요한 역할을 합니다. 기본적으로 드라이버는 패킷을 그룹화하여 IRQ 수를 줄입니다. rx-usecs 및 tx-usecs지연 시간을 최소한으로 줄이려면 이 기능을 비활성화하면 됩니다. ethtool -Crx-usecs와 tx-usecs를 0으로 설정하면 지연 시간은 줄어들지만 인터럽트 오버헤드가 증가하므로 부하에 따라 균형을 찾아야 합니다.

또한 irqbalance를 사용하여 IRQ를 여러 코어에 분산 하거나, 이를 비활성화하고 특정 코어에 대한 인터럽트 및 네트워크 큐(RSS/RPS) 선호도를 수동으로 설정할 수 있습니다. 이는 초저지연 환경이나 DPDK를 사용하여 커널 스택의 상당 부분을 건너뛸 때 매우 일반적입니다.

고려해야 할 또 다른 매개변수는 CPU의 C 상태 입니다 . 깊은 절전 모드는 전력 소비를 줄이지만 코어가 "깨어날 때" 지연이 발생합니다. 응답 지연을 줄이려면 이러한 깊은 절전 모드를 제한할 수 있지만, 전력 소비가 증가하고 다른 코어의 터보 부스트를 위한 여유 공간이 줄어드는 것을 감수해야 합니다. 각 환경에는 전력 소비량과 응답 시간 단축 사이의 최적점이 있습니다.

CPU, 서비스 및 애플리케이션 최적화를 통해 지연 시간을 줄입니다.

커널 자체 외에도 주변 환경은 전체 지연 시간에 많은 영향을 미칩니다. 시스템에서 활성화된 서비스 부터 각 애플리케이션의 특정 구성에 이르기까지 다양한 요소가 영향을 미칩니다.

고성능 서버는 다음 기능만 실행해야 합니다. 진정으로 필요한 악마들블루투스, 프린팅, 네트워크 자동 검색(CUPS, Avahi 등)과 같은 백엔드 시스템의 서비스는 CPU, 메모리, I/O만 소모할 뿐 아무런 이점도 제공하지 않습니다. 검토해 보세요. systemctl list-unit-files --state=enabled 그리고 불필요한 기능을 비활성화하는 것은 가장 저렴하고 효과적인 방법 중 하나입니다.

중요 프로세스의 우선순위를 높이려면 renice, chrt, taskset과 같은 도구를 사용할 수 있습니다 . 프로세스의 우선순위를 조정(renice), 실시간 스케줄링 할당(chrt -f 99), 또는 특정 코어 할당(taskset)을 통해 다른 작업과의 간섭을 줄여 데이터베이스, VoIP, 스트리밍 또는 거래 서비스의 CPU 사용률 예측 가능성을 향상시킬 수 있습니다.

애플리케이션 수준에서의 튜닝은 커널 튜닝만큼이나 중요합니다. Nginx나 Apache 같은 웹 서버는 워커, 킵얼라이브, 캐시, 압축 등을 세밀하게 튜닝해야 합니다. PostgreSQL이나 MySQL 같은 데이터베이스는 버퍼 크기, 체크포인트, 연결 풀, 동기 쓰기 매개변수 등을 검토하여 낮고 안정적인 지연 시간을 달성해야 합니다.

JVM 또한 중요한 역할을 합니다. G1GC 또는 ZGC와 같은 가비지 컬렉터를 선택 하고 힙 크기를 조정하면 외부에서 지연으로 나타나는 일시 정지를 줄일 수 있습니다. 가상화 및 컨테이너 환경에서는 vCPU, vRAM 및 I/O 할당량을 적절하게 배분하여 잠재적인 경합을 방지할 수 있으며, 이는 나중에 무한 디스크 대기열이나 CPU 과부하로 나타날 수 있습니다.

커널 및 시스템 모니터링 및 벤치마킹

튜닝을 아무리 해도 그 영향을 측정하지 않으면 소용없습니다. 핵심은 지속적인 모니터링과 재현 가능한 성능 테스트를 결합하여 커널이나 sysctl에 대한 모든 변경 사항을 객관적인 데이터로 평가하는 것입니다.

시스템의 전반적인 상태를 확인하려면 다음과 같은 기존 도구를 사용할 수 있습니다. htop, vmstat, iotop o sar더 자세한 정보가 필요할 때는 다음과 같은 특정 커널 도구를 사용합니다. perf 및 ftrace이를 통해 스케줄러, 인터럽트 및 내부 호출의 동작을 상당히 정확하게 추적할 수 있습니다.

실제 운영 환경에서는 CPU 카운터, I/O, 디스크 및 네트워크 지연 시간, 프로세스 큐 등을 노출하는 익스포터를 갖춘 Prometheus, collectd, sysstat과 같은 메트릭 시스템을 배포하는 것이 좋습니다 . Grafana 또는 유사한 도구를 사용하여 이러한 데이터를 시각화하면 최종 사용자가 문제를 알아차리기 전에 회귀 또는 이상 징후를 감지하는 데 도움이 됩니다.

벤치마킹의 핵심은 실제 작업 부하를 재현하고 각 변경 사항의 "전과 후"를 비교하는 것입니다. sysbench (CPU 및 데이터베이스용), fio (디스크용), iperf3 (네트워크용)와 같은 도구를 사용하면 반복 가능한 시나리오를 구축할 수 있습니다. 시간 경과에 따른 의미 있는 비교를 위해서는 커널 버전, sysctl 구성, 하드웨어 및 테스트 매개변수를 기록해 두는 것이 필수적입니다 .

실제로 리눅스 커널 최적화는 반복적인 과정입니다. 일련의 최적화 작업을 테스트하고 결과를 측정하여 실질적인 이점을 제공하는 부분은 유지하고 나머지는 버립니다. 효과적인 변경 관리 체계를 구축하면 스케줄러, 그래픽, 전력 또는 네트워킹 개선 사항이 포함된 최근 커널 버전 시리즈와 같은 새로운 커널 버전의 개선 사항을 온프레미스 서버, 클라우드 또는 고성능 워크스테이션 등 어떤 환경에서든 애플리케이션에 실질적인 이점으로 전환할 수 있습니다.

커널 아키텍처에 대한 지식, sysctl을 사용한 미세 조정, 제어된 컴파일, 실시간 패치의 선택적 사용, 그리고 우수한 메트릭 시스템을 결합하면 관리자 또는 운영팀은 사소한 문제에도 하드웨어를 변경하거나 시스템 보안을 손상시키지 않고도 더 빠른 응답 속도, 더 낮은 지연 시간, 그리고 전반적인 안정성 향상을 달성할 수 있습니다.