sysctl을 사용한 고급 Linux 커널 최적화

인포매텍 디지털 » Recursos » sysctl을 사용한 고급 Linux 커널 최적화

리눅스 서버를 어느 정도 관리해 본 경험이 있다면, 평범한 시스템과 부하가 심한 상황에서도 뛰어난 성능을 발휘하는 시스템의 차이는 커널 튜닝에 달려 있다는 것을 알게 될 것입니다. 단순히 RAM을 추가하거나 더 강력한 CPU를 설치하는 것만으로는 충분하지 않습니다. 많은 병목 현상은 몇 가지 매개변수를 신중하게 조정함으로써 해결됩니다.

커널은 수백 가지의 네트워크, 메모리, 파일 시스템 및 프로세스 스케줄링 옵션을 제공하며, 이러한 옵션은 실행 중에 수정할 수 있습니다. 해당 도구를 사용하면 sysctl 그리고 몇 가지 조정 사항이 있습니다. /proc하드웨어를 최대한 활용하여 원하는 결과를 얻는 것이 가능합니다. 지연 시간 감소, 처리량 증가, 안정성 향상 이는 웹 서버와 데이터베이스는 물론 실시간 환경과 쿠버네티스에도 적용됩니다. 하지만 정확히 무엇을 하고 있는지, 그리고 어떻게 측정해야 하는지 아는 것이 중요합니다.

sysctl이란 무엇이며 커널 매개변수를 어떻게 구성합니까?

유용 sysctl 이는 재컴파일이나 재부팅 없이 커널 매개변수를 변경할 수 있는 관문입니다. 런타임에 값을 읽고 수정합니다. 설정을 즉시 테스트할 수 있습니다. 이러한 매개변수는 낮은 계층 구조의 트리로 구성됩니다. /proc/sys/그리고 각각은 시스템의 특정 동작을 제어합니다.

설정은 명확한 범주로 그룹화되어 있어 특정 성능 또는 안정성 문제가 발생할 때 조정해야 할 항목을 쉽게 찾을 수 있습니다. 이러한 구조를 통해 네트워크(net.*), 메모리(vm.*) 또는 파일 시스템(fs.*) 과 같은 특정 설정에만 집중하고 나머지 커널 옵션에 묻히지 않고 필요한 설정을 찾을 수 있습니다.

다음에서 찾을 수 있는 주요 카테고리 /proc/sys/ 다음은 그 예입니다.

• 핵심.*일반적인 커널 옵션(스케줄러, PID, 메시지, NUMA 등).
• vm.*가상 메모리 관리, 스왑, 캐시 및 오버커밋 정책.
• 그물.*IPv4/IPv6 네트워크 스택, TCP/UDP 버퍼, 큐, 혼잡 제어.
• fs.*디스크립터, inode, inotify, AIO 및 VFS 동작의 제한 사항.
• 개발.*특정 장치 및 드라이버의 특정 매개변수.

와 sysctl -a 다음과 같은 명령어를 사용하면 사용 가능한 모든 매개변수를 나열할 수 있습니다. sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse 특정 값을 읽는 것이 핵심입니다. 현재 구성을 감사합니다 변경하기 전에. 특정 항목을 찾으려면 일반적으로 필터링을 사용합니다. grep예 : sysctl -a | grep tcp.

매개변수를 실시간으로 수정하는 것은 다음과 같이 간단합니다. sysctl -w clave=valor하지만 이러한 변경 사항은 일시적이라는 점을 이해하는 것이 중요합니다. 재부팅 후에도 변경 사항을 유지하려면 구성을 백업하는 것이 필수적입니다. /etc/sysctl.conf 또는 파일에서 /etc/sysctl.d/일반적으로 번호가 매겨진 파일(예: )을 사용합니다. 10-network.conf, 20-memory.conf, 99-custom.conf) 적용 순서를 결정하는 요소들입니다.

손대기 전에 측정하세요: 벤치마크 및 시스템 기준선

설정을 변경하기 전에 객관적인 성능 기준선을 설정하는 것이 현명합니다 . 사전 데이터가 없으면 변경 사항이 시스템을 개선했는지 악화시켰는지 알 수 없으며, "내 눈에는 더 좋아 보이는데"라는 함정에 빠지기 쉽습니다. 이는 합리적인 결정을 내리는 데 전혀 도움이 되지 않습니다.

시스템 전체적인 차원에서, 대표적인 부하 조건에서 몇 분 동안 CPU, 시스템 부하, 메모리, 디스크 및 네트워크 통계를 수집하는 것이 좋습니다. 다음과 같은 도구를 사용할 수 있습니다. uptime, mpstat, vmstat, iostat -x o sar -n DEV 이를 통해 기본 커널의 동작 방식, 스왑 사용량, 디스크 I/O 응답 속도, 네트워크 포화 상태 또는 대역폭 낭비 여부를 확인할 수 있습니다.

이러한 개요 외에도 최적화하려는 애플리케이션에 대한 특정 벤치마크를 실행하는 것이 중요합니다. 웹 서버의 경우 다음을 사용할 수 있습니다. ab (Apache Bench) 또는 유사한 측정 도구 초당 요청 수, 평균 지연 시간 및 오류데이터베이스에서 유틸리티는 다음과 같습니다. mysqlslap o sysbench 이를 통해 초당 트랜잭션 수와 쿼리 시간을 평가할 수 있습니다.

예를 들어, 튜닝을 하지 않은 시나리오에서는 초당 500개의 HTTP 요청과 평균 응답 시간 200ms, 초당 약 250개의 SQL 쿼리와 40ms의 지연 시간, 약 500Mbps의 네트워크 속도, 그리고 시스템 부하가 스트레스 상황에서 한계에 가까워지는 수치를 흔히 볼 수 있습니다. 이러한 수치는 커널 변경을 적용한 후 처리량의 측정 가능한 증가와 지연 시간의 감소가 실제로 달성되었는지 확인하는 데 사용됩니다.

마지막으로, 변경 작업을 수행하기 전에 명령과 결과를 기록해 두십시오. 기록을 남겨두면 여러 차례에 걸친 조정 작업을 정확하게 비교할 수 있을 뿐 아니라, 커널 업데이트 후 또는 프로덕션 환경에 새로운 sysctl 프로파일을 도입한 후 발생하는 회귀 오류를 감지하는 데에도 도움이 됩니다.

고급 메모리 설정: vm.*

메모리는 커널 변경 사항이 가장 두드러지게 나타나는 하위 시스템 중 하나입니다. RAM 용량은 충분하지만 구성이 잘못된 서버는 불필요하게 스왑 공간을 사용하게 되어 문제가 발생할 수 있습니다. I/O 급증 및 급격한 성능 저하그래서 다음과 같은 매개변수가 필요합니다. vm.swappiness페이지 오류 비율이나 VFS 캐시 동작 방식 또한 마찬가지로 중요합니다.

매개 변수 vm.swappiness 이 설정은 커널이 스왑 영역으로 보내는 메모리 페이지의 양을 제어합니다. 많은 배포판에서 이 값은 60으로 설정되어 있는데, 이는 혼합 데스크톱 환경을 위한 값입니다. 데이터베이스 서버나 저지연 애플리케이션의 경우, 이 값을 10 또는 그 이하로 낮추는 것이 시스템 효율성을 높이는 데 일반적으로 더 효과적입니다. 데이터를 RAM에 유지하는 것을 우선시하고 스와핑을 줄이세요.이러한 조정 후 디스크 트래픽이 급감하고 애플리케이션 응답 속도가 훨씬 느려지는 것은 드문 일이 아닙니다.

또 다른 기본적인 구성 요소는 다음과 같습니다. vm.dirty_ratio y vm.dirty_background_ratio이 값들은 커널이 더티 페이지를 디스크에 플러시하기 시작하기 전에 메모리의 몇 퍼센트가 더티 페이지로 채워질 수 있는지를 결정합니다. 값이 지나치게 높으면 플러시가 발생할 때 모든 애플리케이션에 엄청난 지연이 발생하여 쓰기 작업이 폭증할 수 있습니다. 이 비율을 각각 15%와 5% 정도로 줄이면 일반적으로 다음과 같은 결과가 나타납니다. 보다 일관적이고 예측 가능한 I/O 패턴.

의 설정 vm.vfs_cache_pressure 이 설정은 커널이 inode 및 디렉터리 캐시를 얼마나 적극적으로 삭제하는지를 정의합니다. 기본값인 100은 캐시를 빠르게 삭제하는 경향이 있으며, 50 정도의 설정값은 메타데이터를 더 오래 유지하여 파일 작업의 적중률을 높이고 성능을 향상시킵니다. 파일 시스템의 체감 성능수백만 개의 작은 파일을 처리하는 서버에서 매우 중요한 요소입니다.

그 부분은, vm.min_free_kbytes 시스템이 갑작스러운 메모리 할당 급증에 대응하여 시스템 오류(OOB)를 방지할 수 있도록 최소한의 여유 메모리를 확보해야 합니다. 전체 RAM의 약 0,5%~1% 정도를 여유 메모리로 확보하는 것이 일반적으로 효과적인 안전 장치이며, 이를 통해 극한 부하 시 커널이 메모리 부족으로 인해 중요 프로세스를 종료하는 것을 방지하여 성능을 향상시킬 수 있습니다. 전반적인 호스트 안정성.

마지막으로, 오버커밋 정책에 주목할 필요가 있습니다. 다음과 같은 매개변수들이 포함됩니다. vm.overcommit_memory y vm.overcommit_ratio 이는 사용 가능한 RAM 및 스왑 공간에 비해 프로세스에 할당되는 가상 메모리의 양을 결정합니다. 어떤 경우에는 (예: Redis 또는 특정 데이터베이스) 적극적인 오버커밋이 허용되지만, 다른 경우에는 위험을 제한하기 위해 보다 보수적인 정책이 선호됩니다. 메모리 부족(OOM) 및 메모리가 과도하게 손상된 상황복잡한 사례를 분석하고 진단하는 기법에 대해서는 다음을 참조하십시오. 리눅스에서의 메모리 디버깅.

고급 네트워크 최적화: net.* 및 TCP/IP

네트워크 스택은 운영 환경에서 튜닝 효과가 가장 두드러지게 나타나는 영역일 것입니다. 연결 큐나 버퍼를 간단히 변경하는 것만으로도 500Mbps에서 버벅거리는 서버와 그렇지 않은 서버 사이의 차이를 만들어낼 수 있습니다. 기가비트 대역폭을 쉽게 포화시킵니다.매개변수는 다음과 같습니다. net.core.* y net.ipv4.* 이 분야에서 그들은 당신의 가장 든든한 아군입니다.

우선, 소켓 버퍼 크기는 연결의 최대 처리량에 직접적인 영향을 미칩니다. 특히 지연 시간이 길거나 대용량 링크가 필요한 경우 더욱 그렇습니다. 조정하십시오. net.core.rmem_max y net.core.wmem_max 넉넉한 값(수십 또는 수백 메가바이트)으로 설정하고 정확하게 정의하십시오. net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (최소값, 기본값 및 최대값)을 통해 각 소켓은 다음을 가질 수 있습니다. 교통량 급증을 완화할 공간이 필요합니다 매우 보수적인 공장 가치관이 부과하는 인위적인 제약에 얽매이지 않고.

또 다른 핵심 사항은 연결 대기열의 크기입니다. 다음과 같은 매개변수가 있습니다. net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog 이러한 제한은 시스템이 패킷을 드롭하거나 핸드셰이크를 거부하기 전에 처리할 수 있는 대기 중인 연결 수를 정의합니다. 트래픽이 많은 웹 서버에서 이러한 제한을 늘리면 큐 포화를 방지하고 부하를 크게 줄일 수 있습니다. 최대 부하 시 연결 오류.

TCP 연결의 동작은 다양한 옵션을 통해 세밀하게 조정할 수 있습니다. net.ipv4.tcp_window_scaling 고대역폭 링크에서 큰 창을 지원하려면 다음을 활성화하십시오. net.ipv4.tcp_sack y net.ipv4.tcp_timestamps 손실 및 재전송 관리를 개선하거나 조정하기 위해 net.ipv4.tcp_fin_timeout 그리고 관리 TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) 서버의 리소스 소비를 제어하기 위해 분당 수백만 건의 짧은 연결이 발생합니다..

혼잡 제어 알고리즘의 선택 또한 중요합니다. cubic 이는 여전히 많은 배포판에서 기본값으로 유지됩니다. 변경하려면 bbr 최신 커널(4.9 이상)에서 net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq 이 기술은 복잡한 손실이나 지연이 발생하는 환경에서 TCP 처리량을 크게 향상시켜 특정 시나리오에서 기존 구성 대비 2~25배의 성능 향상을 달성할 수 있지만, 그에 따른 비용이 발생합니다. 혼잡한 네트워크에서는 다소 다른 동작을 보입니다..

우리는 안전 및 신뢰성 관련 매개변수를 잊어서는 안 됩니다. net.ipv4.tcp_syncookies리디렉션 처리(net.ipv4.conf.all.accept_redirects, send_redirects) 또는 브리지에서의 필터링 (net.bridge.bridge-nf-call-iptables (Kubernetes 환경에서). 제대로 구성하면 일반적인 공격(SYN 플러드, 스푸핑 등)으로부터 시스템을 보호하면서도 성능 저하 없이 작업을 수행할 수 있습니다. 안정적인 네트워크 성능규칙 및 탐지에 대한 실용적인 가이드를 보려면 다음을 참조하세요. Netfilter 및 Suricata 구현.

파일 시스템, 디스크립터 및 전역 제한: fs.* 및 ulimit

최신 서버에서 파일 디스크립터 제한이 낮으면 피크 시간대에 시스템이 다운되는 가장 빠른 원인이 됩니다. 웹 서버, 리버스 프록시 또는 데이터베이스에서 흔히 발생하는 "열린 파일이 너무 많습니다" 오류는 대개 커널 매개변수와 사용자 제한이 실제 부하에 맞게 조정되지 않았기 때문입니다.

세계적으로, fs.file-max 이 값은 커널이 동시에 열 수 있는 디스크립터의 총 개수를 지정합니다. 수천 개의 동시 연결을 처리하는 애플리케이션의 경우, 이 값을 수백만 개로 늘리는 것이 일반적이며, 이와 함께 다른 값도 함께 증가시킵니다. fs.nr_open이는 프로세스별 설명어의 최대 허용치를 설정합니다. 추가적으로 조정이 필요합니다. /etc/security/limits.conf 따라서 사용자(또는 systemd에서 관리하는 서비스)는 다음과 같은 권한을 갖습니다. 커널 구성과 일치하는 소프트 및 하드 값.

IDE, 웹 개발 도구 및 파일 모니터링 시스템에서 널리 사용되는 inotify 서브시스템은 다음과 같은 매개변수에 의해 제어됩니다. fs.inotify.max_user_watches y fs.inotify.max_user_instances디스크 변경 사항 모니터링을 중지하는 감시자 또는 프로세스와 관련된 오류가 발생하는 경우, 다음 사항을 확인해야 합니다. 이러한 제한을 늘려 조용한 병목 현상을 방지하세요..

또 다른 중요한 특징은 비동기 I/O(AIO)이며, 그 전역 최대값은 다음과 같이 정의됩니다. fs.aio-max-nr비동기 I/O에 크게 의존하는 애플리케이션(특정 데이터베이스 엔진, 큐 시스템 등)에서 이 값을 높이면 요청 부하가 급증할 때 커널이 AIO 작업에 사용할 슬롯이 부족해지는 것을 방지할 수 있습니다.

이러한 매개변수 외에도 디스크 하위 시스템의 성능은 다음 요소의 영향을 받습니다. I/O 스케줄러 각 블록 장치에 구성됩니다. SSD 또는 NVMe 시스템에서는 일반적으로 다음과 같은 경량 스케줄러를 사용하는 것이 좋습니다. none o mq-deadline반면 기계식 디스크의 경우 다음과 같은 다른 옵션이 적합할 수 있습니다. bfq 부하 유형에 따라 다릅니다. 스케줄러를 통해 조정하십시오. /sys/block/<disco>/queue/scheduler 그리고 큐 깊이와 같은 옵션을 세밀하게 조정합니다.nr_requests) 또는 read_ahead_kb 눈에 띄는 차이를 만들 수 있습니다 읽기/쓰기 지연 시간 및 처리량어떤 파일 시스템과 드라이버가 사용되는지도 고려하는 것이 중요합니다. 예를 들어, 관련 기사들을 참고하세요. Linux의 NTFSplus 다른 시스템들은 이질적인 부하를 설계할 때 도움이 될 수 있습니다.

마지막으로, 이러한 커널 제한 사항은 시스템 구성과 같은 요소와 함께 고려되어야 한다는 점을 잊어서는 안 됩니다. ulimit 또한 systemd 유닛을 사용하여 서비스가 정의된 추가 리소스를 실제로 사용할 수 있고 차단되지 않도록 합니다. 상위층의 제한 사항.

커널 일반, NUMA, CPU 선호도 및 대용량 페이지

네트워킹, 메모리, 파일 시스템 외에도 커널 자체는 프로세스 스케줄링 방식, 코어 및 NUMA 노드에 걸친 워크로드 분산 방식, 대규모 메모리 관리 방식 등에 영향을 미치는 다양한 튜닝 옵션을 제공합니다. 코어가 많고 소켓도 여러 개인 최신 시스템에서는 이러한 세부 설정이 서버 성능의 균형을 좌우하는 중요한 요소가 될 수 있습니다. 일부 코어는 포화 상태에 이르지만 다른 코어는 활용도가 떨어지는 상황이 발생할 수도 있습니다. 또한 , 다른 지연 시간 프로필이 필요한 환경에서는 Liquorix 커널 과 같은 대안 커널을 고려해 보는 것도 좋습니다 .

다음과 같은 매개변수 kernel.pid_max 이러한 설정은 시스템이 할당할 수 있는 프로세스 ID의 최대 범위를 정하는 것으로, 많은 수의 컨테이너 또는 임시 프로세스를 실행하는 노드에 중요합니다. 커널 로깅 옵션 조정(kernel.printk)는 중요한 이벤트를 기록하면서도 dmesg의 과도한 노이즈를 줄이는 데 도움이 되며, 이는 간접적으로도 영향을 미칩니다. 진단 기능 및 안정성.

메모리 토폴로지와 관련하여 매개변수는 다음과 같습니다. kernel.numa_balancing 이 설정은 커널이 NUMA 노드 간에 페이지를 자동으로 이동하는 정도를 제어합니다. 특정 환경에서 이 설정을 비활성화하면 와 같은 도구를 사용하여 프로세스 및 메모리 선호도를 보다 명시적으로 관리할 수 있습니다. numactl CPU 및 RAM 사용량이 많은 프로세스가 동일한 노드에 유지되도록 하여 부하를 줄입니다. 원격 접속으로 인한 지연 시간하드웨어와 코어 스케줄링 간의 상호 작용을 더 잘 이해하려면 다음과 같은 기술들을 검토하는 것도 도움이 됩니다. 인텔 스레드 디렉터.

거대한 페이지들 (vm.nr_hugepages이는 대규모 연속 메모리 영역을 처리하는 데이터베이스 시스템이나 기타 워크로드에서 또 다른 핵심 구성 요소입니다. 적절한 수의 대형 페이지(아키텍처에 따라 2MB 또는 1GB)를 예약하면 TLB 오버헤드를 줄이고 실행되는 애플리케이션의 성능을 크게 향상시킬 수 있습니다. 대용량 메모리 블록에 대한 많은 작업이를 효과적으로 구현하려면 커널 구성이 애플리케이션 자체와 조화를 이루어야 하며, 애플리케이션이 해당 메모리를 명시적으로 사용하도록 해야 합니다.

지연 시간 및 스케줄링 분야에는 다음과 같은 스케줄러 매개변수가 있습니다. kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_ns이 설정은 각 작업에 할당되는 CPU "청크"의 크기와 커널이 코어 간에 프로세스를 이동하는 속도를 세밀하게 조정합니다. 값이 작을수록 선점형 시스템이 되어 더 나은 성능을 제공하는 경향이 있습니다. 대화형 작업에 대한 최적의 답변 때로는 처리량이 다소 감소하는 대가를 치러야 할 수도 있습니다.

메모리가 중요한 리소스인 시스템에서 일부 관리자는 초기 오류 발생 시 패닉 모드를 활성화하도록 선택합니다.vm.panic_on_oom) 및 설정 kernel.panic 자동 재시작 시간을 설정합니다. 이 전략은 다소 극단적이지만, 고가용성 환경에서 유용할 수 있습니다. 호스트가 멈추거나 불안정해지는 것보다는 빠르고 제어된 재부팅이 더 바람직합니다. 몇 시간 동안.

특화된 프로필: 웹, 데이터베이스, 저지연 및 쿠버네티스

하나의 만능 해결책을 적용하는 대신, 웹 서버, 데이터베이스, 컨테이너 플랫폼 또는 저지연 시스템 등 다양한 워크로드 유형에 맞춘 sysctl 프로파일을 생성하는 것이 더 효과적입니다. 이러한 설정을 다음과 같은 파일에 배포하면 됩니다. 99-webserver.conf, 99-database.conf o 90-kubernetes.conf 도와 주다 체계적이고 버전 관리가 쉬운 구성을 유지합니다.성능 향상에 초점을 맞춘 배포판 및 에디션도 고려해 볼 수 있습니다. CachyOS 서버 에디션 매우 특정한 환경에 한해서입니다.

웹 서버(Nginx, Apache, 프록시 등)의 핵심은 대용량의 동시 접속과 긴 대기열 및 빠른 응답 시간을 처리하는 것입니다. FIN_WAIT 미세 조정, 확장된 임시 포트 범위 및 매우 높은 디스크립터 제한을 통해 초당 수백 건의 HTTP 요청에서 수천 건으로 늘어나 평균 지연 시간이 줄어들고 오류가 없어지는 경우가 흔합니다. 포화된 대기열 또는 가득 찬 포트.

데이터베이스 측면(MySQL, PostgreSQL 등)에서는 스왑 사용량 최소화, 더티 페이지 쓰기 미세 조정, 엔진에 적합한 공유 메모리 및 세마포어 설정에 우선순위가 주어집니다. 다음과 같은 매개변수들이 고려됩니다. kernel.shmmax, kernel.shmall, kernel.sem 그리고 대규모 페이지 구성은 여러 면에서 차이를 만들어냅니다. 초당 트랜잭션 수 및 응답 시간많은 시나리오에서 기본값에 비해 성능을 두 배 또는 세 배로 향상시킵니다.

극도로 낮은 지연 시간이 요구되는 애플리케이션(거래, 온라인 게임, 실시간 처리)의 경우, 더욱 세분화된 설정이 추가됩니다. net.ipv4.tcp_low_latency비활성 상태 후 슬로우 스타트 비활성화, 사용 tcp_fastopen바쁜 설문조사 매개변수(net.core.busy_poll, busy_read그리고 많은 경우 투명한 대형 페이지의 비활성화로 인해 /sys/kernel/mm/transparent_hugepage/enabled이 모든 것은 감소시키기 위한 것입니다. 처리 대기열 및 지연 시간이 높은 백분위수에서 최고치를 기록합니다.P99에서 놀라운 개선을 달성했습니다.

컨테이너 및 Kubernetes 환경에서는 네트워크 스택과 연결 추적에 특히 많은 부하가 걸립니다. 다음과 같은 매개변수들이 영향을 받습니다. net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_max수백 또는 수천 개의 파드를 처리하는 노드에서는 NodePort에 예약 포트를 사용하거나 ARP 테이블을 조정하는 것이 일반적입니다. 이러한 설정을 올바르게 조정하면 문제를 예방할 수 있습니다. conntrack에서 연결이 끊어지거나, 시간 초과가 발생하거나, 테이블이 포화되는 문제가 발생할 수 있습니다..

이러한 특정 프로필 외에도 일부 조직에서는 대용량 네트워크 버퍼와 스왑 사용량 감소 등의 조치를 결합하여 보안을 강화한 성능 중심의 아카이브를 선택합니다. tcp_syncookies 또는 위험한 리디렉션을 차단하는 것. 목표는 달성하는 것입니다. 공격적인 성능과 적절한 경화 사이의 균형점.

커널 프로파일링 및 모니터링 도구

측정 없이 커널을 조정하는 것은 눈을 가리고 오디오 믹서를 조작하는 것과 같습니다. 리눅스는 간단한 카운터부터 커널 기능에 대한 자세한 추적에 이르기까지 시스템이 실제로 무엇을 하는지 이해하는 데 도움이 되는 다양한 도구를 제공하여 구성 변경과 측정 가능한 효과를 연관시킬 수 있도록 합니다.

일상생활에 필요한 편의 시설로는 다음과 같은 것들이 있습니다. vmstat, iostat, sar, ss, slabtop, htop o pidstat프로세스, CPU, I/O, 소켓 및 캐시 사용량에 대한 정보를 빠르게 제공합니다. 시스템 로그 및 Prometheus, Grafana 또는 collectd로 내보낸 메트릭과 다음과 같은 리소스와 결합됩니다. 리눅스용 고급 시스템 모니터이 정보는 각 튜닝 전후의 호스트 동작 방식을 상당히 완벽하게 보여줍니다.

더 자세히 설명하자면, 다음과 같은 도구들이 있습니다. perf 이 도구들은 사용자 및 커널 모두에서 함수 수준의 CPU 사용량 프로파일링을 가능하게 하고, 몇 초 또는 몇 분 동안 이벤트를 기록한 다음 대화형 보고서를 제공합니다. perf stat, perf record y perf report 당신은 볼 수 있습니다 CPU 시간이 실제로 어디에서 소비되고 있으며, 그중 어떤 부분이 코어에 해당하는지예를 들어, 업무 중단 사태나 제대로 조정되지 않은 스케줄러를 식별하는 것과 같습니다.

더 자세한 정보가 필요하시면, ftrace 커널의 추적 서브시스템은 특정 추적기(예: 함수 추적기)를 활성화하고 실시간 또는 사후 분석을 통해 어떤 함수 호출이 발생하는지 살펴볼 수 있는 기능을 제공합니다. 적절한 추적기를 활성화하고 그 내용을 분석하면 됩니다. /sys/kernel/debug/tracing/trace 그것은 당신에게 드러납니다 커널 자체 내의 핫스팟이는 상위 수준 지표만으로는 충분하지 않을 때 매우 유용합니다.

이와 병행하여, 주기적으로 주요 데이터(네트워크 통계, 메모리 카운터, 열린 파일 디스크립터 수 등)를 순환 로그에 기록하는 자동화된 모니터링 스크립트를 구현하는 것이 좋습니다. 특정 임계값(예: 지정된 열린 파일 디스크립터 수 초과)에 도달하면 이러한 스크립트가 이메일이나 다른 채널을 통해 경고를 생성하여 문제가 심각해지기 전에 위험한 추세를 감지할 수 있도록 지원합니다.

마지막으로, 장시간 스트레스 테스트 단계(24시간 이상)에서는 다음과 같은 도구가 사용됩니다. stress-ng 지표의 지속적인 수집과 결합하여 (를 통해) vmstat, iostat, sar이 기능을 사용하면 새로운 커널 구성으로 시스템의 안정성을 평가하고, 지속적인 부하 상태에서 OOM 이벤트, 충돌, 예기치 않은 재시작 또는 점진적인 성능 저하가 발생하지 않는지 확인할 수 있습니다.

sysctl 및 기타 메커니즘을 사용하여 Linux 커널을 최적화하는 것은 일회성 작업이 아니라 결과를 측정하고, 매개변수를 조정하고, 모든 과정을 꼼꼼하게 문서화하는 반복적인 프로세스입니다. 명확한 방법론, 각 워크로드 유형에 맞는 특정 프로파일, 강력한 프로파일링 도구 모음, 그리고 엄격한 변경 관리가 있다면 하드웨어를 최대한 활용하여 처리량 증가, 지연 시간 감소, 그리고 기본 공장 설정보다 훨씬 뛰어난 안정성을 갖춘 서버를 구축할 수 있습니다.