NUMA 서버에서 작업 스레드를 늘렸는데 처리량이 떨어졌습니다. 메모리 배치와 CPU 이동이 원인인지 어떻게 확인하나요?

NUMA 서버에서는 CPU와 메모리가 여러 노드로 나뉘며 모든 메모리 접근 비용이 같지 않습니다. 스레드가 속한 노드의 로컬 페이지를 읽는 것보다 다른 노드의 remote page를 읽는 일이 더 느리고, 대역폭도 노드별로 제한됩니다. 그래서 스레드 수를 코어 수에 맞춰 늘렸는데도 데이터가 한 노드에 몰리거나 작업자가 코어 사이를 이동하면 처리량과 p99가 악화될 수 있습니다. 성능 판단은 코어 수가 아니라 작업·데이터·스케줄링의 배치를 함께 보는 NUMA 지역성으로 해야 합니다.

first-touch와 공유 접근을 분리합니다

페이지가 처음 쓰인 CPU의 노드에 배치되는 first-touch 정책을 쓰는 환경에서 초기화 스레드 하나가 큰 배열을 모두 만지면 배열이 그 노드에 몰릴 수 있습니다. 이후 다른 노드의 worker가 배열 전체를 순회하면 원격 접근이 누적됩니다. 반대로 각 worker가 앞으로 처리할 구간을 자기 노드에서 초기화하면 지역성을 얻을 수 있습니다. 하지만 하나의 공유 카운터나 큐를 모든 노드가 계속 갱신하면 캐시 라인의 쓰기 소유권과 coherence 트래픽이 이동하여 지역성 효과가 사라질 수 있습니다. 이때 논리적으로 다른 값이 같은 cache line에 놓인 거짓 공유와 NUMA 원격 접근은 별도 현상입니다.

스레드 migration, 노드별 메모리 사용량, remote access 비율, 메모리 대역폭, LLC miss, run queue를 같이 측정하겠습니다. 작은 데이터셋이 LLC에 들어가는 벤치마크는 원격 메모리 문제를 숨기므로 실제 데이터 크기와 키 분포를 사용해야 합니다. CPU affinity를 강하게 고정하면 local access는 좋아질 수 있지만 한 노드만 바쁘고 다른 노드가 놀면 전체 처리량이 떨어집니다. 따라서 균일한 작업은 노드별 queue와 local-first steal을 사용하고, 불균일한 작업은 이동 비용과 유휴 비용을 비교하겠습니다.

수치로는 두 노드에서 각 8개 worker를 돌리며 64GiB 배열을 순회하는 실험을 하겠습니다. 한 초기화 스레드가 배열 전체를 만진 뒤 원격 worker가 읽는 경우와 worker가 자기 구간을 first-touch하는 경우를 비교하고, remote access 비율·노드별 대역폭·migration·p99를 기록합니다. 작은 배열이 LLC에 들어가는 실험은 원격 비용을 숨길 수 있으므로 실제 크기와 키 분포를 사용하겠습니다.

노드별 queue와 local-first steal은 지역성을 높이지만 한 노드에 무거운 작업이 몰리면 다른 노드가 놀 수 있습니다. 객체를 다른 노드로 넘기는 대신 복제하면 원격 읽기는 줄어도 복사·일관성 비용이 생기고, 페이지 migration은 짧은 burst에서 이동 비용이 이득을 넘을 수 있습니다. affinity를 고정할지 완화할지는 원격 접근 감소뿐 아니라 전체 처리량, 작업 불균형, 장애 시 재배치 시간을 기준으로 선택하겠습니다.

작업을 다른 노드로 훔쳐 오는 local-first steal은 유휴 코어를 줄이지만, 훔친 객체에 대한 원격 접근을 늘릴 수 있습니다. 작업이 짧으면 이동 비용이 처리 비용보다 커질 수 있으므로 queue 길이와 객체 크기를 기준으로 steal 조건을 둡니다. 노드별 메모리 압력과 장애 시 재배치도 함께 평가하겠습니다.

노드별 pool은 원격 접근을 줄이는 대신 객체를 다른 노드로 넘길 때 remote free와 queue 경합을 만들 수 있습니다. 읽기 전용 설정은 노드별 복제가 적합할 수 있지만 갱신이 잦으면 버전·동기화 비용이 커집니다. local-first steal은 유휴 코어를 줄이되, 작업이 짧으면 이동 비용이 처리 비용보다 커질 수 있어 객체 크기와 queue age를 기준으로 제한하겠습니다.