DongHyeonkaandClaude Opus 5
2109f726fe
기록 84편을 계약 에이전트로 다시 썼다. 기존 71편(kss 25 · virt 46)과, 계약에만 있고 안 쓰여 있던 새 글감 13편이다. 원장 84개를 열어 단계마다 스킬 영수증과 관문 종료 코드를 적었고 verify-pipeline-run.py 가 error 0 으로 닫는다. SSOT 결함 둘을 고쳤다. - kss 의 `약 58일` 이 반입 중 `약 59일` 로 바뀌어 있었다. 원 증거 파일이 「남은 일수: 88일 … 실제 갱신까지 약 58일」로 산수를 직접 적는다. D-4a 쪽 `약 59일` 은 강제 갱신 뒤(`VALID: 89 days`)라 맞는 값이라 그대로 뒀다. - virt §198 의 `11.6GB` 는 §178 의 원 측정 `Mem: 11648`(MiB)과 어긋나는데 원 가이드의 표기 그대로라 고치지 않고 쓰이는 자리에 대조를 적었다. 기록의 수치 오류 셋을 고쳤다 — CASE 요약의 「게스트 셋에 8240MB」(5120+3120 은 둘이다), k3s 편이 같은 것을 여섯·일곱·여덟로 세던 것, no-docker 편의 「셋을 더 든다」(§281 의 표는 네 행이고 디스크 행이 빠져 있었다). 계약을 셋 고쳤다. - kss 의 sourceRepository 리비전이 cdac9b8 이었는데 그 커밋에는 docs/guides/** 28개가 아예 없다. 9465582b 로 바꾸고, 반입한 바이트가 어느 커밋과도 같지 않다는 것을 측정값과 함께 적었다 — 반입은 커밋이 아니라 그 시점의 작업 트리에서 떠 온 것이다(kss 297/306 · virt 12/14 가 작업 트리와 같고, 200 커밋을 거슬러 전수 대조했을 때 가장 가까운 커밋도 28개가 어긋났다). - virt 계약이 「2026-09-11 재배분」이라고 적는데 SSOT 는 재배분 날짜를 적지 않고 재배분 뒤 값은 이미 2026-09-10 측정에 찍혀 있다. - kss 후보 대장이 지나친 절 아홉에 처분을 적었다(warn 9 → 0). 새 글감은 0건이고 넷은 앵커가 h3 슬러그의 접두가 아니라 중간 토막이라 검사기가 못 본 것이었다. style_profile.mjs 의 결함 둘을 고쳤다 — frontmatter 가 문장으로 세어져 (실측 398자짜리 「문장」 하나) 평균 길이를 기준 안으로 밀어 올리고 있었고, engPerSent 의 분자는 목록을 포함한 글에서, 분모는 목록을 걷어낸 글에서 세고 있었다(Question 기록에서 11.94 → 3.86). verify-pipeline.py 전 항목 PASS · error 0 · unittest 334건 OK. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
90 lines
6.7 KiB
Markdown
90 lines
6.7 KiB
Markdown
---
|
|
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 <QEMU_PID>`, vCPU 배치는 `virsh vcpupin <VM_NAME>` 과 `virsh vcpuinfo <VM_NAME>` 이다.
|
|
- §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 <VM_NAME>` 으로 vCPU 배치를, `numastat -p <QEMU_PID>` 로 그 QEMU 프로세스의 메모리 분포를 이어서 적는다 (§78).
|
|
|
|
닫는 조건 : 단일 NUMA 노드로 나오면 §27 이 적은 대로 지금 실험에서 우선순위를 낮추고 닫는다. 다중 NUMA 노드로 나오면 vCPU 와 메모리 배치를 별도 Case 후보로 올리고 §24.11 과 함께 §73~§78 쪽으로 넘긴다.
|