--- id: 688c6c02-c1bd-4cd2-a615-2396db145386 kind: QUESTION slug: host-numa-topology title: 이 호스트의 NUMA 토폴로지는 가상 머신 성능을 고려해야 할 구조인가 topic: cpu-virtualization topicName: CPU 가상화 project: virtualization status: 초안 questionStatus: OPEN studio: "https://hyeonworks.com/studio/documents/688c6c02-c1bd-4cd2-a615-2396db145386/edit" sourceRevision: no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 source: - final/document.md#27-문제-영역에서-파생되는-추가-open-question-oq-12 - final/document.md#24-cpu-가상화-계층에서-발생할-수-있는-문제-24-11 --- # 이 호스트의 NUMA 토폴로지는 가상 머신 성능을 고려해야 할 구조인가 이 호스트의 NUMA 노드 수를 확인한 기록이 없다. §197 이 받은 `lscpu` 출력에 NUMA 줄이 없어서다. NUMA(Non-Uniform Memory Access)는 어느 CPU 가 어느 메모리에 접근하느냐에 따라 접근 비용이 달라지는 구조다. 단일 노드면 지금 실험에서 우선순위를 낮추고, 다중 노드면 vCPU 와 메모리 배치를 따로 다룬다. ## 관계 - **KVM 에서 vCPU 가 물리 CPU 에서 실행되기까지** vCPU 스레드가 어느 논리 CPU 에서 실행될지를 호스트 스케줄러가 정한다는 것이 이 물음의 전제다. ## 사실 - 멀티소켓 또는 NUMA 구조의 호스트에서는 CPU 가 실행되는 NUMA 노드와 가상 머신 메모리가 놓인 NUMA 노드가 어디냐에 따라 성능이 달라질 수 있다. - vCPU 가 노드 0 의 CPU 에서 실행되는데 필요한 메모리가 주로 노드 1 에 배치되어 있으면 다른 노드의 메모리를 읽는 접근(remote memory access)이 생길 수 있다. - NUMA 는 CPU 가상화와 메모리 가상화의 경계에 걸쳐 있다. 그래서 지금 개념 문서는 문제가 있다는 것과 CPU 친화도와 어떻게 얽히는지까지만 기록했고, 상세한 메모리 배치와 NUMA 튜닝은 메모리 가상화를 다루는 개념 문서로 넘겼다. - 이 물음의 종료 기준은 개념 문서가 직접 적어 두었다. 단일 NUMA 노드 : 지금 실험에서 우선순위를 낮춘다 다중 NUMA 노드 : vCPU 와 메모리 배치를 별도 Case 후보로 올린다 개념 문서가 남긴 열린 물음 열둘 가운데 닫는 갈래를 스스로 적어 둔 것은 이 하나다. - §24.11 은 이 확인에 쓸 명령을 적지 않았다. 다른 확인 항목과 달리 NUMA 쪽에는 예로 든 명령이 없다. - 메모리 가상화 쪽 §78 이 그 명령을 든다. 노드 수는 `lscpu` 의 NUMA 줄로 보라고 적고 `numactl --hardware` 를 추가로 든다. QEMU 프로세스별 메모리 분포는 `numastat -p `, vCPU 배치는 `virsh vcpupin ` 과 `virsh vcpuinfo ` 이다. - §197 이 2026-09-10 에 이 호스트에서 받은 `lscpu` 출력은 `Model name` 이 `11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz`, `CPU(s)` 가 8, `Core(s) per socket` 이 4, `Thread(s) per core` 가 2 다. 네 줄만 `grep` 으로 걸러 받아서 NUMA 줄은 거기 없다. - §24.11 이 문제를 두는 조건은 멀티소켓 또는 NUMA 구조인데, 그 네 줄에는 `Socket(s)` 도 NUMA 줄도 없다. - 이 호스트의 NUMA 노드 수를 확인한 기록이 없다. ## 가정 - 호스트에 붙어 노드 수를 읽을 수 있다고 본다. - 단일 노드로 나오면 vCPU 가 실행되는 노드와 메모리가 놓인 노드가 갈리지 않으므로 다른 노드의 메모리를 읽을 일이 지금 실험에서 성능 차이를 만들지 않는다고 본다. 그 추론을 이 호스트에서 확인하지는 않았다. - 두 가상 머신의 메모리 배치가 실행 중에 바뀌지 않는다고 전제한다. §198 은 virtio-balloon 이 안 쓰는 만큼 호스트에 돌려준다고 적었으므로 할당된 양은 실행 중에 바뀐다. 노드 배치까지 따라 바뀌는지는 적혀 있지 않다. ## 미지수 - 이 호스트가 단일 NUMA 노드인지 다중 NUMA 노드인지. - 다중이라면 두 가상 머신의 vCPU 와 메모리가 각각 어느 노드에 배치되어 있는지. - §78 이 든 명령 가운데 `numactl` 과 `numastat` 이 이 호스트에 깔려 있는지. - 다중으로 나왔을 때 배치를 바꾸는 일이 지금 가상 머신 구성에서 가능한지. ## 제약 - 이 질문이 다중 노드로 닫혀도 여기서 NUMA 튜닝을 정하지 않는다. 상세한 메모리 배치는 §73~§78 과 그것을 받을 메모리 가상화 개념 기록이 다룬다. - §24.11 쪽에는 예로 든 명령이 없고 §78 쪽 명령은 메모리 가상화 절에 있다. 그래서 실행한 명령과 그 출력을 함께 증거로 남긴다. - 이 호스트의 노드 수를 잰 값이 없어 다른 장비의 노드 구성을 근거로 삼지 않는다. ## 선택지 ### 1. 노드 수만 먼저 읽고 거기서 갈린다 호스트의 NUMA 노드 수 하나로 우선순위 판정이 끝나기 때문에 확인이 짧고, 단일로 나오면 더 볼 것이 없다. 다중으로 나오면 vCPU 와 메모리 배치를 읽으려고 한 번 더 붙어야 한다. ### 2. 노드 수와 두 가상 머신의 배치를 한 번에 읽는다 호스트에 붙은 김에 노드 수와 각 가상 머신의 vCPU · 메모리 배치를 같이 받아 적는다. 다중으로 나왔을 때 바로 다음 단계로 넘어갈 수 있다. 단일로 나오면 함께 받은 배치는 쓰지 않게 되는데, 대신 실행이 한 번으로 끝난다. ### 3. 메모리 가상화 쪽에서 함께 본다 — 제외 상세한 메모리 배치를 §73~§78 이 다루므로 확인도 그쪽에서 하자는 방법이다. 지금 필요한 판단은 이 항목을 실험 목록의 어디에 둘지 하나이고, 그것은 노드 수만으로 갈린다. §78 은 먼저 topology 를 측정하고 NUMA 최적화가 필요한지 판단한다고 적었다. 그 순서대로면 노드 수는 여기서 재고 배치 조정을 그쪽이 받는다. ## 다음 검증 1. `lscpu` 를 NUMA 줄까지 받아 노드 수를 적고 `numactl --hardware` 로 한 번 더 본다 (§78). 2. 실행한 명령과 그 출력을 함께 증거로 남긴다. §24.11 쪽에 예로 든 명령이 없어서 무엇을 썼는지 적어 두지 않으면 다음 사람이 같은 값을 다시 읽지 못한다. 3. 다중 노드로 나오면 `virsh vcpupin ` 으로 vCPU 배치를, `numastat -p ` 로 그 QEMU 프로세스의 메모리 분포를 이어서 적는다 (§78). 닫는 조건 : 단일 NUMA 노드로 나오면 §27 이 적은 대로 지금 실험에서 우선순위를 낮추고 닫는다. 다중 NUMA 노드로 나오면 vCPU 와 메모리 배치를 별도 Case 후보로 올리고 §24.11 과 함께 §73~§78 쪽으로 넘긴다.