서버 인프라를 운영하다 보면 분명 하드웨어 스펙은 충분한데 이상하게 서비스 응답 속도가 느려지거나 특정 코어의 점유율만 튀는 현상을 마주하곤 합니다.
이는 멀티 프로세서 환경에서 메모리 접근 방식이 비효율적으로 이루어지면서 발생하는 전형적인 병목 현상인데 이를 해결하기 위해 많은 엔지니어들이 리눅스 커널의 메모리 관리 기법인 numactl 도구를 활용하죠.
numactl 활용하여 서버 성능 한계 돌파하는 법
다중 프로세서 시스템에서는 각 CPU가 자신의 근처에 있는 메모리에 접근할 때 가장 빠른 속도를 내는데 이를 로컬 메모리 할당이라 부릅니다.
하지만 리눅스 커널은 기본적으로 메모리를 모든 노드에 골고루 분산하려고 시도하며 이 과정에서 원격 메모리 접근이 잦아지면 시스템 버스인 QPI나 UPI 링크에 과부하가 걸리게 됩니다.
numactl 명령어는 특정 프로세스가 실행될 때 지정된 CPU 코어와 메모리 노드를 고정하여 이러한 지연 시간을 원천적으로 차단하는 강력한 수단을 제공하죠.
실제 대규모 트래픽을 처리하는 DB 서버에서 numactl --physcpubind와 --membind 옵션을 조합하여 적용하면 평균 레이턴시가 눈에 띄게 줄어드는 것을 확인할 수 있습니다.
단순히 명령어만 실행하는 것이 아니라 시스템의 토폴로지를 먼저 분석하는 것이 우선인데 numactl --hardware 명령어를 치면 현재 서버의 노드 구성과 메모리 슬롯 위치를 한눈에 파악할 수 있죠.
메모리 노드 할당 최적화로 처리량 높이기
데이터 패킷이 처리될 때 CPU 내부 캐시와 RAM 사이의 거리가 물리적으로 멀어질수록 사이클 손실이 발생하는데 이를 NUMA 아키텍처라고 지칭합니다.
프로세스 바인딩을 할 때 주의할 점은 무조건 코어를 고정한다고 좋은 것이 아니라 하이퍼스레딩 구조를 고려하여 물리 코어를 짝지어 할당하는 디테일이 필요하죠.
메모리 인터리빙을 강제로 비활성화하고 로컬 노드에만 데이터를 적재하도록 설정하면 고성능 컴퓨팅 환경에서 초당 처리량인 TPS 수치가 비약적으로 상승합니다.
| 옵션 명칭 | 기능 설명 | 활용 시점 |
| --physcpubind | 특정 프로세서를 강제 지정 | 연산 부하가 극심할 때 |
| --membind | 메모리 노드 위치 고정 | 메모리 대역폭이 좁을 때 |
| --localalloc | 가장 가까운 노드에 할당 | 기본 정책 설정 시 |
병목 현상 해결을 위한 커널 튜닝 포인트
메모리 노드 할당이 제대로 되었는지 확인하려면 numastat 명령어를 통해 노드 간 메모리 할당 실패 수치인 numa_miss 혹은 numa_foreign 지표를 살펴보는 습관을 들여야 합니다.
이 수치가 높게 나온다면 특정 프로세스가 원격 메모리를 과도하게 점유하고 있다는 증거이므로 즉시 배치를 다시 조정해야 하죠.
많은 경우 인터럽트 처리기인 IRQ가 특정 코어에만 집중되어 병목이 발생하는데 이를 방지하기 위해 smp_affinity 설정을 numactl과 병행하는 것이 기술적 완성도를 높이는 길입니다.
특히 대용량 메모리를 사용하는 애플리케이션에서는 HugePages 설정과 함께 numactl을 사용하면 페이지 테이블 탐색 시간을 대폭 단축할 수 있습니다.
이러한 설정들은 서버 리부팅 후 초기화될 수 있으므로 서비스 시작 스크립트에 포함하거나 cgroup 설정을 통해 영구적으로 적용하는 것이 안정적인 운영의 핵심이죠.
실무 환경에서는 무턱대고 모든 설정을 적용하기보다는 벤치마킹 툴을 사용하여 변경 전후의 비교 데이터를 명확히 확보한 뒤 단계적으로 반영하는 전략이 권장됩니다.
소켓 간 메모리 복사 비용이 전체 성능을 갉아먹는 상황이라면 프로세스 간 공유 메모리 설정을 최소화하고 NUMA aware 라이브러리를 사용하는 방식으로 아키텍처를 최적화해야 합니다.
시스템 안정성 유지하는 운영 철학
성능 최적화라는 명목으로 과도한 코어 고정을 강행하다 보면 예기치 못한 스케줄링 불균형으로 인해 서버 전체의 응답성이 저하될 가능성도 존재합니다.
따라서 모든 코어를 타이트하게 조이기보다는 시스템의 전체 부하율을 고려하여 가용성을 확보하는 방향으로 가이드를 잡는 것이 중요하죠.
최근에는 컨테이너 기술인 도커나 쿠버네티스에서도 NUMA topology manager를 통해 이러한 설정을 자동화하려는 움직임이 커지고 있으니 기반 기술을 잘 이해해 두는 것은 매우 유리합니다.
지속적인 모니터링을 통해 시스템 캐시 적중률과 로컬 메모리 사용률을 확인하면서 튜닝값을 미세 조정하는 인내심이 전문가의 역량을 판가름하죠.
하드웨어 수준의 인터커넥트 대역폭을 고려하지 않은 무분별한 튜닝은 오히려 시스템 전체의 동기화 오버헤드를 유발할 수 있으므로 주의해야 합니다.
특정 환경에서는 numad 데몬을 사용하여 동적으로 메모리 배치를 최적화하는 방안도 검토해 볼 만하지만 수동 제어만큼의 정교함은 떨어질 수 있음을 인지해야 합니다.
마지막으로 서버의 바이오스 설정에서 노드 인터리빙 옵션이 활성화되어 있다면 numactl의 효용성이 크게 반감될 수 있으므로 하드웨어 레벨의 설정값부터 먼저 체크하시기 바랍니다.
캐시 일관성 프로토콜이 자주 트리거되는 환경이라면 메모리 할당 영역을 최대한 물리적으로 인접한 곳으로 묶는 작업이 무엇보다 중요합니다.
데이터베이스의 공유 버퍼가 128기가를 넘어서는 대규모 환경이라면 NUMA 노드 경계에서 발생하는 메모리 할당 실패를 막기 위해 cgroups V2 설정을 동반하는 것이 좋죠.
서버 하드웨어의 설계 구조에 따라 메모리 컨트롤러의 배치가 다르므로 서버 매뉴얼의 블록 다이어그램을 한 번쯤 정독하는 것만으로도 문제 해결의 실마리를 찾을 수 있습니다.
단일 노드 내에서의 메모리 할당 정책을 localalloc으로 고정하고 페이지 교체 알고리즘이 빈번하게 작동하지 않도록 swappiness 값을 조정하는 것은 기본 중의 기본입니다.
시스템 성능의 마법은 결국 가장 가까운 곳에서 가장 빠르게 데이터를 가져오는 단순한 원리를 어떻게 구현하느냐에 달려 있는 것이죠.
이러한 과정에서 발생하는 미세한 지연 시간은 수천만 건의 트랜잭션이 발생하는 서버에서는 거대한 차이로 다가오게 됩니다.
오늘 다룬 내용들을 바탕으로 본인의 서버 환경에 맞는 최적의 NUMA 정책을 찾아나가시길 바라며 사소한 설정 하나가 인프라의 품격을 바꾼다는 점을 기억하세요.
(질문 답변) numactl 자주 묻는 질문들
Q. numactl을 사용하면 서버가 더 빨라지나요? A. 무조건 빨라지는 것은 아니지만 메모리 접근 지연을 줄여 병목을 제거함으로써 특정 부하 상황에서 매우 유의미한 성능 향상을 얻을 수 있습니다.
Q. 노드 간 메모리 할당 실패는 어떻게 확인하나요? A. numastat -m 명령어를 입력하면 각 노드별 메모리 사용량과 실패 횟수인 numa_miss 수치를 정밀하게 확인할 수 있습니다.
Q. 모든 프로세스에 적용하는 것이 좋나요? A. 시스템 안정성을 위해 필요한 핵심 서비스나 데이터베이스 엔진 위주로 적용하고 일반적인 OS 프로세스는 커널 스케줄러에 맡기는 것이 안전합니다.
Q. 바이오스 설정이 왜 중요한가요? A. 하드웨어 레벨에서 노드 인터리빙이 켜져 있으면 OS가 메모리 노드를 구분하는 의미가 퇴색되므로 반드시 확인이 필요합니다.
Q. 하이퍼스레딩 환경에서의 주의점은 무엇인가요? A. 물리적인 코어와 논리적인 스레드를 정확히 구분하여 바인딩해야만 성능 하락 없이 최적의 캐시 효율을 뽑아낼 수 있습니다.