feat(pipeline): keycloak-session-store 25편·virtualization 59편을 S3→S5→S6 으로 돌린다

기록 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>
2026-09-17 11:01:55 +09:00
parent d473609e0a
commit 2109f726fe
574 changed files with 159654 additions and 1551 deletions
@@ -164,7 +164,7 @@ cat /sys/kernel/mm/transparent_hugepage/enabled

 ## 이 글이 확정하지 않는 것

-이 호스트에서 잰 값은 하나도 없다. THP 정책도 `HugePages_Total` 도 읽지 않았고 가상 머신의 메모리 backing 설정도 확인하지 않았다. 원문 제2부는 개념 서술이고 실제 서버에 딸린 값은 OQ(Open Question) 번호가 붙은 확인 목록 열넷으로 미뤄져 있다.
+이 호스트에서 huge page 를 잰 값은 하나도 없다. THP 정책도 `HugePages_Total` 도 읽지 않았고 가상 머신의 메모리 backing 설정도 확인하지 않았다. 원문 제2부는 개념 서술이고 실제 서버에 딸린 값은 OQ(Open Question) 번호가 붙은 확인 목록 열넷으로 미뤄져 있다.

 호스트 쪽 값은 OQ-4 가 받는다. THP 정책과 함께 `AnonHugePages`, `HugePages_Total`, `HugePages_Free`, `Hugepagesize` 를 읽어 이 서버가 어느 방식을 쓰고 있는지 확정하는 확인이다.

@@ -174,6 +174,6 @@ cat /sys/kernel/mm/transparent_hugepage/enabled
 virsh dumpxml <VM_NAME>
 ```

-두 확인이 끝나기 전에는 이 글의 세 질문 가운데 어느 것도 이 서버에 대해 답이 없다. 그리고 두 확인이 끝나도 셋째 질문은 남는다. EPT 매핑에서 큰 매핑을 쓰는가를 이 호스트에서 재라고 적은 항목은 그 열넷에 없다. 원문이 커널·QEMU·libvirt 버전을 적지 않아 이 글도 특정 버전에 고정하지 않았고, THP 정책의 기본값이 배포판마다 다르다는 점도 원문이 확인하라고만 적었다.
+두 확인이 끝나기 전에는 이 글의 세 질문 가운데 어느 것도 이 서버에 대해 답이 없다. 그리고 두 확인이 끝나도 셋째 질문은 남는다. EPT 매핑에서 큰 매핑을 쓰는가를 이 호스트에서 재라고 적은 항목은 그 열넷에 없다. 원문 제2부가 THP 와 HugeTLB 를 서술하면서 커널·QEMU·libvirt 버전을 적지 않아 이 글도 특정 버전에 고정하지 않았다. 이 실험대의 커널 `7.2.2-arch1-1` 과 QEMU 11.1.1, libvirt 12.7.0 은 §197 이 적어 두었다. 그 위에서 huge page 값을 읽은 기록은 없다. THP 정책의 기본값이 배포판마다 다르다는 점도 원문이 확인하라고만 적었다.

 <!-- body:end -->
@@ -62,7 +62,11 @@ VM3 configured = 16 GiB
 Total configured = 48 GiB
 ```

-이 숫자는 개념을 보이려고 든 예시이고 이 테스트 서버에서 잰 값이 아니다. 설정한 용량과, 그 가상 머신이 실제로 쓰고 있는 메모리(working set)나 호스트에서 그 몫으로 붙잡고 있는 메모리(resident memory)가 같지 않을 수 있기 때문에 이런 구성이 가능할 수 있다. 같은 예시에서 세 가상 머신이 실제로 쓰는 양을 각각 약 5G, 4G, 3G 로 잡으면 합이 약 12G 라 32 GiB 안에 들어간다. 세 대의 수요가 동시에 증가하면 그때부터 문제가 발생한다. 이 호스트의 값은 근거 문서 어디에도 없다. 물리 RAM 도 스왑 설정도 가상 머신들에 설정한 메모리의 합도 적혀 있지 않아서, 아래에 적는 경로가 이 환경에서 지금 돌고 있는지는 이 글이 정하지 못한다.
+이 숫자는 개념을 보이려고 든 예시이고 이 테스트 서버에서 잰 값이 아니다. 설정한 용량과, 그 가상 머신이 실제로 쓰고 있는 메모리(working set)나 호스트에서 그 몫으로 붙잡고 있는 메모리(resident memory)가 같지 않을 수 있기 때문에 이런 구성이 가능할 수 있다. 같은 예시에서 세 가상 머신이 실제로 쓰는 양을 각각 약 5G, 4G, 3G 로 잡으면 합이 약 12G 라 32 GiB 안에 들어간다. 세 대의 수요가 동시에 증가하면 그때부터 문제가 발생한다.
+
+이 실험대는 그 구성이 아니다. 호스트 물리 RAM 은 §178 이 `free -m` 으로 실측한 11,648MiB 다. 게스트 세 대에 배정한 메모리는 §187 이 `kc-lab-1` 5120MB, `kc-lab-2` 4096MB, `kc-lab-edge` 1024MB 로 적었고 합이 10,240MB 다. 배정 합이 호스트 RAM 보다 작다. 배정률은 10240/11648 = 87.9% 이고, 배정하지 않고 남은 것이 1,408MiB 다. 그래서 이 배치는 메모리 초과 할당이 아니다. 호스트의 스왑 설정은 아직 근거 문서에 없다.
+
+그 배정이 처음부터 이 숫자였던 것은 아니다. §187 은 게스트를 만들 때 메모리가 3584MB 였고 실험을 늘리며 5120/4096 으로 재배분했다고 적었다. 왜 그때 늘릴 수 있었는지는 §332 에 있다 — 「호스트에서 8GB→12GB로 물리 증설한 뒤 이 방법으로 재배분했다.」 그 방법은 `virsh setmaxmem` 으로 상한을 올리고 `virsh setmem` 으로 현재 할당을 맞추는 두 줄인데, 현재 할당을 상한보다 크게 줄 수 없어 순서가 정해져 있다. 게스트를 다시 만들거나 디스크를 건드리지 않아도 되는 대신 `setmaxmem --live` 는 대개 거부되므로, 상한을 바꾸려면 게스트를 껐다 켠다.

 CPU 가 모자랄 때와 RAM 이 모자랄 때 Linux 가 하는 일이 다르다. CPU 가 모자라면 스케줄러가 실행 시간을 나누고 실행 가능한 작업은 자기 차례를 기다리는데, 시간은 잘라서 뒤로 미룰 수 있기 때문이다. RAM 이 모자랄 때는 미룰 것이 없어서 지금 존재해야 하는 페이지를 어디에 둘 것인가만 남는다. 그래서 메모리 압박에서는 회수와 스왑, ballooning, OOM 같은 메커니즘이 추가로 개입한다. 메모리 초과 할당은 CPU 초과 할당과 동일한 성격의 자원 공유가 아니다.

@@ -109,10 +113,10 @@ cgroup 메모리 상한이 걸린 환경에서는 호스트 전체 RAM 에 여

 ## 이 문서가 확정하지 않는 것

-이 글이 확정하는 것은 구조가 어떻게 동작하는가까지다. 이 테스트 서버에서 잰 값은 하나도 없다.
+이 글이 확정하는 것은 구조가 어떻게 동작하는가까지다. 이 테스트 서버에서 잰 값 가운데 여기 쓴 것은 호스트 물리 RAM 과 게스트 배정, §198 의 할당·실사용뿐이고, 압박 경로 자체를 이 서버에서 재현한 적은 없다.

-이 호스트의 물리 RAM 도, 스왑 설정도, 가상 머신들에 설정한 메모리의 합도 근거 문서에 적혀 있지 않다. 그래서 이 환경이 초과 할당 상태인지조차 아직 사실이 아니다. 설정한 메모리와 게스트가 실제로 쓰는 메모리, 호스트에서 그 몫으로 붙잡고 있는 메모리를 가상 머신마다 적으면 그 답이 나온다.
+호스트 물리 RAM 11,648MiB 와 게스트 배정 합 10,240MB 는 앞 절에 실측으로 적었고, 배정 합이 더 작아 이 배치는 초과 할당이 아니다. 남은 것은 호스트의 스왑 설정과, 가상 머신마다의 실제 사용량 그리고 호스트에서 그 몫으로 붙잡고 있는 메모리다. §198 이 `virsh dommemstat` 으로 k3s 두 대를 재서 `kc-lab-1` 은 할당 5120MB 에 실사용 353MB, `kc-lab-2` 는 할당 3120MB 에 실사용 301MB 였다고 적었다. `kc-lab-2` 의 할당이 배정한 4096MB 보다 작은데, 같은 절은 그것을 virtio-balloon 이 회수해 간 것으로 보인다고 적고 단정하지 않았다. 그 측정은 k3s 만 떠 있고 Keycloak 은 올리기 전이라 나머지가 올라간 뒤의 값은 미측정이다. `kc-lab-edge` 는 그 측정에 들어 있지 않다.

-스왑이 지금 오가고 있는지도 재지 않았다. `Swap Used` 값 하나로는 진행 중인 활동인지 과거에 내려간 뒤 남아 있는 cold page 인지 갈리지 않으니 게스트와 호스트를 같은 시각에 관측해야 한다. 호스트 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는지는 압박이 없는 구간과 있는 구간을 나눠 재야 알 수 있고, 그 구간에서 스토리지 지연과 CPU 도 같이 기록해야 원인을 메모리 쪽으로 좁힐 수 있다. 세 확인은 각각 열린 질문으로 두었고 관계에 걸어 두었다.
+스왑이 지금 오가고 있는지도 재지 않았다. §178 과 §197 에 있는 호스트 `free -m` 출력은 `head -2` 로 잘려 `Mem:` 줄까지만 남아 스왑 줄이 없다. `Swap Used` 값 하나로는 진행 중인 활동인지 과거에 내려간 뒤 남아 있는 cold page 인지 갈리지 않으니 게스트와 호스트를 같은 시각에 관측해야 한다. 호스트 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는지는 압박이 없는 구간과 있는 구간을 나눠 재야 알 수 있다. 그 구간에서 스토리지 지연과 CPU 도 같이 기록해야 원인을 메모리 쪽으로 좁힐 수 있다. 세 확인은 각각 열린 질문으로 두었고 관계에 걸어 두었다.

 <!-- body:end -->
@@ -67,7 +67,7 @@ vCPU 를 특정 CPU 집합에 묶는 설정을 pinning 이라고 한다. 어떤

 ![QEMU vCPU Thread, VM1 Memory Backing, Node 0 CPU, Node 0 RAM, Node 1 RAM 다섯 참여자 사이의 순서도. 1번에서 vCPU thread 가 Node 0 CPU 에 pinning 되고 2번에서 VM1 의 memory backing 이 Node 1 에 놓이면 3번의 접근이 점선으로 Node 1 RAM 까지 간다. 4번에서 memory 를 Node 0 에 묶은 구성에서는 5번의 같은 접근이 Node 0 RAM 에서 끝난다.](../../../final/assets/diagrams/numa-vcpu-and-memory-placement/numa-vcpu-and-memory-placement.svg)

-이 호스트가 노드 몇 개인지는 근거 문서에 없다. 하나로 나오면 지금 말한 어긋남은 이 환경에 성립하지 않는다.
+이 호스트가 노드 몇 개인지는 근거 문서에 없다. §197 이 논리 코어를 8 로 적었지만 NUMA 노드 수는 읽지 않았다. 그 절은 `lscpu | grep -E "^Model name|^CPU\(s\):|^Thread|^Core"` 로 네 줄만 걸러 받았고, 거기 남은 `Core(s) per socket` 4 와 `Thread(s) per core` 2 로 논리 코어 8 이 나온다. `Socket(s)` 줄과 `NUMA node(s)` 줄은 그 네 패턴에 걸리지 않아 실측에 없다. 그 출력을 다시 읽어도 노드 수가 나오지 않으므로 아래 절의 `lscpu` 를 거르지 않고 한 번 더 친다. 노드가 하나로 나오면 지금 말한 어긋남은 이 환경에 성립하지 않는다.

 ## 큰 가상 머신에서는 게스트에게 토폴로지를 보여 준다

@@ -75,7 +75,7 @@ vCPU 를 특정 CPU 집합에 묶는 설정을 pinning 이라고 한다. 어떤

 노출한 뒤에는 게스트가 인식하는 토폴로지와 실제 호스트 배치가 합리적으로 대응되도록 구성한다. 게스트 NUMA 0 이 호스트 NUMA 0 에, 게스트 NUMA 1 이 호스트 NUMA 1 에 대응하지 않으면, 게스트가 로컬이라고 판단해 고른 메모리가 호스트에서는 원격이 된다.

-이 프로젝트의 가상 머신이 그런 크기인지는 근거 문서에 적혀 있지 않다. vCPU 수도 설정한 RAM 도 나오지 않아서, 이 절이 이 환경에 걸리는 이야기인지는 그 값을 적은 뒤에 정해진다.
+이 실험대의 가상 머신은 그 크기가 아니다. §187 이 적은 게스트 세 대는 vCPU 가 한 개나 두 개이고 배정한 메모리가 1024MB 에서 5120MB 사이다. §197 은 그 vCPU 합을 `2 + 2 + 1 = 5` 로 적었다.

 ## 이 장비의 토폴로지부터 읽는다

@@ -114,7 +114,7 @@ virsh vcpuinfo <VM_NAME>

 ## 이 문서가 확정하지 않는 것

-이 글이 확정하는 것은 배치가 어긋나면 무엇이 원격 접근이 되는가까지다. 이 테스트 서버에서 잰 값은 하나도 없다.
+이 글이 확정하는 것은 배치가 어긋나면 무엇이 원격 접근이 되는가까지다. 이 테스트 서버에서 NUMA 를 잰 값은 하나도 없다.

 이 호스트가 노드 하나인지 여럿인지가 정해지지 않았다. 노드 하나로 나오면 앞 절의 어긋남이 이 환경에 성립하지 않으므로 NUMA 를 현재 실험에서 뒤로 미룬다. 여럿으로 나와야 QEMU 프로세스의 노드별 메모리 분포와 vCPU 배치를 나란히 적는 확인이 의미를 갖는다. 토폴로지 확인은 CPU 가상화 쪽 질문이 받고 있다.

@@ -203,11 +203,11 @@ Host Kernel
      └─ Host OOM
 ```

-원문의 분류에는 Dynamic Memory 와 NUMA(Non-Uniform Memory Access) 가지가 더 있고, 위에 옮긴 셋이 fault 가 걸리는 가지다. 게스트 쪽 fault 가 늘었으면 게스트의 reclaim 과 swap 을 같이 보고, 호스트 쪽 major fault 가 늘었으면 호스트의 reclaim 과 swap 을 같이 본다. 어느 쪽 지표를 먼저 여느냐가 이 구분에서 정해진다. 다만 이 호스트에서는 어느 쪽도 아직 열지 않았다. 게스트 쪽 fault 지표도 호스트 쪽 major fault 도 읽은 적이 없어서, 이 분류는 아직 어느 지표부터 열지 정하는 데만 쓰인다.
+원문의 분류에는 Dynamic Memory 와 NUMA(Non-Uniform Memory Access) 가지가 더 있고, 위에 옮긴 셋이 fault 가 걸리는 가지다. 게스트 쪽 fault 가 늘었으면 게스트의 reclaim 과 swap 을 같이 보고, 호스트 쪽 major fault 가 늘었으면 호스트의 reclaim 과 swap 을 같이 본다. 어느 쪽 지표를 먼저 여느냐가 이 구분에서 정해진다. 다만 이 호스트에서는 게스트 쪽 fault 지표도 호스트 쪽 major fault 도 아직 열지 않았다. 그래서 이 분류는 지금 어느 지표부터 열지 정하는 데만 쓰인다.

 ## 이 글이 확정하지 않는 것

-이 호스트에서 잰 값은 하나도 없다. 게스트 쪽 fault 지표도 호스트 쪽 major fault 도 읽지 않았고, 앞의 다섯 원인 가운데 무엇이 이 환경에서 실제로 일어나는지도 세지 않았다. 원문 제2부는 개념 서술이고 실제 서버에 딸린 값은 OQ(Open Question) 번호가 붙은 확인 목록 열넷으로 미뤄져 있다.
+이 호스트에서 fault 를 잰 값은 하나도 없다. 게스트 쪽 fault 지표도 호스트 쪽 major fault 도 읽지 않았고, 앞의 다섯 원인 가운데 무엇이 이 환경에서 실제로 일어나는지도 세지 않았다. 원문 제2부는 개념 서술이고 실제 서버에 딸린 값은 OQ(Open Question) 번호가 붙은 확인 목록 열넷으로 미뤄져 있다.

 게스트 쪽은 OQ-13 이 받는다. page-fault 관련 지표를 관측한 뒤 그 증가가 무엇에서 왔는지를 네 갈래로 갈라 보는 확인이고, 증가 자체를 오류로 읽지 않는 것이 조건이다.

@@ -232,6 +232,6 @@ Guest application latency

 가운데 계층은 그 목록이 받지 않는다. 위 분류에는 EPT 관련 사건과 TLB 압박이 한 가지로 들어 있는데, 그것을 이 호스트에서 재라고 적은 항목은 열넷 가운데 없다. 이 글이 갈라 놓은 세 계층에서 확인 계획이 붙은 것은 게스트 쪽과 호스트 쪽 둘이다.

-원문이 커널 버전을 적지 않아 이 글도 특정 버전에 고정하지 않았다. 여기 적은 것은 그 문서가 서술한 처리 구조이고, 이 서버에서 어떤 값이 나오는지는 위 두 확인을 돌려야 안다.
+원문 제2부가 fault 처리를 서술하면서 커널 버전을 적지 않아 이 글도 특정 버전에 고정하지 않았다. 이 실험대의 커널은 §197 이 `7.2.2-arch1-1` 로 적었다. 그 위에서 fault 지표를 읽은 기록은 없다. 여기 적은 것은 그 문서가 서술한 처리 구조이고, 이 서버에서 어떤 값이 나오는지는 위 두 확인을 돌려야 안다.

 <!-- body:end -->
@@ -55,13 +55,13 @@ source:

 이 장치는 게스트 RAM 자체를 제공하지 않는다. 이미 존재하는 게스트 RAM 을 호스트와 게스트가 협력해 회수하고 반환하는 데 쓰는 가상 장치다.

-이 프로젝트의 가상 머신에 이 장치가 붙어 있는지는 근거 문서에 없다. 아래 두 절이 적는 것은 장치가 있을 때 어느 방향으로 움직이는가다.
+이 프로젝트의 가상 머신에 이 장치가 붙어 있는지는 libvirt 설정을 읽어야 정해지고 그 기록이 아직 없다. 아래 두 절이 적는 것은 장치가 있을 때 어느 방향으로 움직이는가다.

 ## Inflate — 게스트 안의 balloon 이 커진다

 호스트가 게스트 메모리를 회수하려고 하면 balloon target 을 조정해 balloon 을 부풀린다. 이 동작을 inflate 라고 한다. 그 요청이 `virtio-balloon` 을 지나 게스트 안의 balloon 드라이버에 닿으면 드라이버가 게스트 페이지를 확보한다. 게스트 안의 balloon 이 커지기 때문에 게스트가 쓸 수 있는 RAM 이 그만큼 줄고, 호스트 쪽에서는 회수할 수 있는 메모리가 는다.

-드라이버가 하는 일은 확보한 페이지를 일반적인 게스트 작업이 쓰지 못하도록 붙잡아 두고 그 사실을 호스트 쪽에 알리는 것까지다. 그 뒤 호스트가 그 메모리를 실제로 언제 어떻게 놓아주는지는 QEMU/KVM 버전과 backing 종류 및 설정에 따라 달라질 수 있다. 근거 문서는 그 동작을 하나로 단정하지 않았고 이 환경에서도 확인하지 않았다. 그 문서는 이 호스트의 QEMU/KVM 버전을 한 번도 적지 않았다. 버전과 설정이 갈라 놓는 동작이라 버전을 적기 전에는 이 환경이 어느 쪽인지 말할 수 없다.
+드라이버가 하는 일은 확보한 페이지를 일반적인 게스트 작업이 쓰지 못하도록 붙잡아 두고 그 사실을 호스트 쪽에 알리는 것까지다. 그 뒤 호스트가 그 메모리를 실제로 언제 어떻게 놓아주는지는 QEMU/KVM 버전과 backing 종류 및 설정에 따라 달라질 수 있다. 근거 문서는 그 동작을 하나로 단정하지 않았고 이 환경에서도 확인하지 않았다. 이 실험대의 버전은 §197 이 적어 두었다 — QEMU 11.1.1 과 libvirt 12.7.0, 커널 `7.2.2-arch1-1` 이다. 버전은 정해졌지만 그 위에서 호스트가 언제 놓아주는지를 잰 기록도, backing 설정을 읽은 기록도 없다.

 ![virtio-balloon Driver 와 virtqueue, QEMU virtio-balloon Device, Host Memory Management 네 참여자 사이를 여섯 개의 메시지가 오가는 순서도. 1번부터 3번까지는 Host 쪽에서 정한 balloon target 조정이 QEMU device 와 virtqueue 를 지나 VM Boundary 를 넘어 Guest kernel 의 driver 에 닿는 방향이고, 4번부터 6번까지는 driver 가 확보한 Guest page 가 같은 경계를 반대로 건너 Host 의 회수 가능 backing 이 되는 방향이다.](../../../final/assets/diagrams/virtio-balloon-inflate-deflate/virtio-balloon-inflate-deflate.svg)

@@ -86,6 +86,21 @@ ballooning 은 게스트에 이미 설정된 메모리 용량 안에서 호스

 현대 가상화에는 `virtio-mem` 같은 다른 동적 메모리 관리 방식도 있어서, 가상 머신의 동적 메모리 관리를 ballooning 하나로 일반화하지 않는다. 근거 문서에 있는 것은 그런 방식이 존재한다는 사실까지다.

+## 이 실험대에서 할당이 줄어 있던 값 하나
+
+앞에서 적었듯 balloon 장치가 붙어 있는지를 설정으로 확인한 기록은 아직 없다. 대신 값이 하나 나와 있다 — §198 이 k3s 게스트 두 대에 `virsh dommemstat` 을 돌려 받은 출력이다.
+
+```text label="§198 의 실측 — k3s 만 떠 있고 Keycloak 은 올리기 전"
+kc-lab-1   할당 5120MB  실사용 353MB
+kc-lab-2   할당 3120MB  실사용 301MB
+```
+
+`kc-lab-2` 는 `virt-install --memory 4096` 으로 만들었는데 현재 할당이 3120MB 로 나왔다. §198 은 이것을 virtio-balloon 이 회수해 간 것으로 보인다고 적고 거기서 멈췄다. 같은 절은 `dommemstat` 의 `actual` 이 현재 할당이지 선언한 상한이 아니라고 덧붙였다. 상한은 `virsh dominfo` 의 `Max memory` 에 있는데, 이 실험대는 그 두 값을 나란히 찍어 보지 않았다.
+
+§198 은 이 값이 언제의 값인지도 함께 적었다 — 「다만 이것은 지금 k3s 만 떠 있어서다」이고, Keycloak 2 파드와 PostgreSQL, Redis, Prometheus 가 올라간 뒤의 값은 미측정이다. 게스트 세 대 가운데 `kc-lab-edge` 는 이 측정에 들어 있지 않다.
+
+이 숫자로 알 수 있는 것은 `kc-lab-2` 의 현재 할당이 선언값보다 작다는 것까지다. 그 차이가 balloon 회수 때문인지와 이 가상 머신들에 장치가 실제로 붙어 있는지는 설정과 게스트 쪽 드라이버 상태를 읽어야 갈린다.
+
 ## 근거 문서가 번호를 붙여 둔 문장

 근거 문서는 이 장치에서 고정한 문장에 번호를 붙여 두었다. 실험 기록에서 어느 문장을 확인했는지 가리킬 때 이 번호를 쓴다.
@@ -97,10 +112,10 @@ ballooning 은 게스트에 이미 설정된 메모리 용량 안에서 호스

 ## 이 문서가 확정하지 않는 것

-이 글이 확정하는 것은 balloon 이 어떤 구조로 어느 방향으로 동작하는가까지다. 이 테스트 서버에서 잰 값은 하나도 없다.
+이 글이 확정하는 것은 balloon 이 어떤 구조로 어느 방향으로 동작하는가까지다. 이 테스트 서버에서 잰 값 가운데 여기 쓴 것은 §198 의 할당과 실사용뿐이고, balloon 을 움직여 본 적은 없다.

-이 프로젝트의 가상 머신에 `virtio-balloon` 이 붙어 있는지조차 근거 문서에 적혀 있지 않다. libvirt 설정에 balloon 관련 요소가 있는지, 있다면 게스트 안에서 그 드라이버가 어떤 이름으로 올라와 있는지를 먼저 확인해야 한다. 장치가 없으면 balloon target 실험은 성립하지 않는다.
+이 프로젝트의 가상 머신에 `virtio-balloon` 이 붙어 있는지를 설정으로 확인한 기록이 없다. 앞 절의 §198 실측은 inflate 방향과 들어맞지만 근거 문서도 그것을 단정하지 않았다. libvirt 설정에 balloon 관련 요소가 있는지, 있다면 게스트 안에서 그 드라이버가 어떤 이름으로 올라와 있는지를 먼저 확인해야 한다. 장치가 없으면 balloon target 실험은 성립하지 않는다.

-값을 한 단계 바꿨을 때 게스트가 쓸 수 있는 메모리가 얼마나 움직이는지, 그 반영이 즉시인지 늦는지, 어느 값부터 게스트 안에서 회수와 스왑이 시작되는지도 재지 않았다. 호스트가 그 메모리를 언제 놓아주는지가 이 QEMU 버전과 이 backing 설정에서 어떻게 되는지도 마찬가지다. 두 확인은 각각 열린 질문으로 두었고 관계에 걸어 두었다.
+값을 한 단계 바꿨을 때 게스트가 쓸 수 있는 메모리가 얼마나 움직이는지, 그 반영이 즉시인지 늦는지, 어느 값부터 게스트 안에서 회수와 스왑이 시작되는지도 재지 않았다. 호스트가 그 메모리를 언제 놓아주는지가 QEMU 11.1.1 과 이 backing 설정에서 어떻게 되는지도 마찬가지다. 두 확인은 각각 열린 질문으로 두었고 관계에 걸어 두었다.

 <!-- body:end -->
@@ -19,9 +19,7 @@ source:

 # balloon target 을 바꾸면 게스트가 쓸 수 있는 메모리는 어떻게 따라 움직이는가

-virtio-balloon 은 게스트에 RAM 을 새로 붙여 주는 장치가 아니라, 이미 있는 게스트 RAM 의 backing 을 호스트와 게스트가 협력해 회수하고 되돌려주는 가상 장치다. 호스트는 balloon target 을 조정해 그 balloon 을 부풀리거나 줄인다. 개념 문서는 방향까지 적어 두었는데, inflate 하면 게스트가 쓸 수 있는 RAM 이 줄고 deflate 하면 늘어난다.
-
-개념 문서가 방향만 적고 크기는 적지 않아서, 이 물음이 받는 것은 방향이 아니라 크기와 시점이다. 이 호스트에서 목표값을 한 단계 움직였을 때 게스트가 쓸 수 있는 메모리가 얼마나 줄어드는지를 아직 값으로 받아 본 적이 없다. 그 변화가 언제 보이는지, 어느 지점부터 게스트가 reclaim 과 스왑을 시작하는지도 마찬가지다.
+이 호스트에서 balloon target 을 한 단계 움직였을 때 게스트가 쓸 수 있는 메모리가 얼마나 줄어드는지 아직 값으로 받아 보지 못했다. virtio-balloon 은 게스트 RAM 의 backing 을 회수하고 되돌려주는 장치다. 개념 문서에는 inflate 하면 줄고 deflate 하면 늘어난다는 방향만 적혀 있다.

 ## 관계

@@ -69,7 +67,7 @@ virtio-balloon 은 게스트에 RAM 을 새로 붙여 주는 장치가 아니라
 - 단계마다 Host · VM · Workload 조건을 함께 적는다. 조건을 남기지 않은 결과는 다른 환경에서 다시 쓰기 어렵다.
 - 게스트 OOM 까지 밀어 볼지는 이 실험에서 정하지 않는다.
 - 개념 문서가 목표값을 바꾸는 명령을 적어 주지 않았으므로 실행한 명령과 그 출력을 증거로 함께 남긴다.
- 호스트가 실제로 회수한 backing memory 는 이 실험에서 재지 않는다. 개념 문서가 그 동작을 QEMU 와 KVM 버전, backing 종류, 설정에 따라 달라질 수 있다고만 적고 단정을 피했고, §83 OQ-9 가 준 관측 순서도 호스트 설정을 바꾼 뒤 게스트 쪽 값과 게스트의 reclaim 과 스왑 변화를 보는 데까지다.
+- 호스트가 실제로 회수한 backing memory 는 이 실험에서 재지 않는다. 개념 문서가 그 동작을 QEMU 와 KVM 버전, backing 종류, 설정에 따라 달라질 수 있다고만 적고 단정을 피했기 때문이다. §83 OQ-9 가 준 관측 순서도 호스트 설정을 바꾼 뒤 게스트 쪽 값과 게스트의 reclaim 과 스왑 변화를 보는 데까지다.

 ## 선택지

@@ -18,11 +18,7 @@ source:

 # 게스트 page fault 증가는 workload 변화를 따라가는가

-게스트 안에서 page fault 가 늘었다는 관측 하나로는 무슨 일이 일어났는지 갈리지 않는다. 개념 문서가 든 대표적인 원인은 다섯인데, 그 가운데 demand paging 과 copy-on-write 는 정상 동작이다. 나머지 중 swap-in 은 게스트 RAM 이 모자란다는 신호이고, invalid access 만 프로그램 오류로 이어진다.
-
-이 물음은 이 호스트의 게스트에서 부하를 올렸을 때 fault 지표가 함께 오르는지를 구간을 나눠 받는다. 올랐다면 그 증가가 다섯 원인 가운데 어느 쪽으로 설명되는지까지 본다.
-
-다섯 원인을 하나씩 묻지 않고 한 물음으로 묶었다. 원인마다 물음을 세우면 개념 문서에서 한 줄이던 것이 다섯 편이 되고, §83 OQ-13 이 갈라 보라고 한 네 갈래는 같은 구간의 같은 지표에서 나온다.
+이 호스트의 게스트에서 부하를 올렸을 때 page fault 지표가 함께 오르는지 아직 찍어 보지 않았다. 올랐다면 개념 문서가 든 다섯 원인 가운데 어느 쪽으로 설명되는지까지 본다. 다섯 가운데 demand paging 과 copy-on-write 는 정상 동작이라, 지표가 늘었다는 관측 하나로는 오류인지 아닌지 갈리지 않는다.

 ## 관계

@@ -68,6 +64,7 @@ source:

 ## 제약

+- 다섯 원인을 하나씩 따로 묻지 않고 한 물음으로 묶어 받는다. 나눠 세우면 개념 문서에서 한 줄이던 것이 다섯 편이 되고, §83 OQ-13 이 갈라 보라고 한 네 갈래는 같은 구간의 같은 지표에서 나온다.
 - 같은 구간의 스왑 활동을 함께 적지 않으면 demand paging 과 swap-in 이 갈리지 않는다.
 - fault 지표 하나로 원인을 확정하지 않는다. 개념 문서가 네 갈래를 갈라 보라고 적은 이유가 이것이다.
 - 부하를 만드는 방법을 두 실행에서 같게 둔다. 방법이 바뀌면 fault 증가가 부하 때문인지 방법 때문인지 갈리지 않는다.
@@ -77,7 +74,7 @@ source:

 ### 1. idle 구간과 부하 구간을 나눠 시간에 따른 변화를 받는다

-두 구간에서 vmstat 1 로 시간에 따른 값을 받고, 같은 구간의 스왑 활동과 애플리케이션의 working set 을 함께 남긴다. 부하가 올라간 시각과 fault 가 오른 시각이 겹치는지가 그대로 보이고, 스왑 활동이 없는데 fault 만 올랐으면 demand paging 쪽으로 좁혀진다.
+두 구간에서 vmstat 1 로 시간에 따른 값을 받고, 같은 구간의 스왑 활동과 애플리케이션의 working set 을 함께 남긴다. 부하가 올라간 시각과 fault 가 오른 시각이 겹치는지가 그대로 보인다. 스왑 활동이 없는데 fault 만 올랐으면 demand paging 쪽으로 좁혀진다.

 minor 와 major 를 프로세스 단위로 가르는 것까지는 이 방법으로 나오지 않는다.

@@ -18,9 +18,7 @@ source:

 # 호스트 major fault 와 스토리지 지연은 같은 시간축에서 함께 움직이는가

-개념 문서는 호스트의 메모리 압박에서 시작해 애플리케이션 지연으로 끝나는 사슬을 그려 두었다. 호스트 메모리 압박이 reclaim 과 스왑을 부르고, 그 스왑 I/O 가 스토리지 I/O 를 늘리고, 늘어난 I/O 가 한 물리 장치에서 경합하면 데이터베이스 지연을 거쳐 애플리케이션 지연까지 간다는 순서다.
-
-사슬의 각 마디는 개념으로 이어져 있지만, 이 호스트에서 네 마디가 같은 구간에 함께 움직이는지는 아직 받아 본 적이 없다. 이 물음은 압박 실험을 한 번 돌릴 때 네 계열을 같은 타임스탬프로 받아 그 사슬이 여기서 이어지는지 끊기는지를 가른다.
+이 호스트에서 major fault 와 스왑 활동, 스토리지 지연, 게스트 애플리케이션 지연 네 계열을 같은 시간축에 놓고 본 적이 아직 없다. 개념 문서가 그려 둔 사슬은 호스트 메모리 압박에서 시작한다. 압박이 reclaim 과 스왑을 부르고, 그 스왑 I/O 가 스토리지 경합을 거쳐 데이터베이스 지연과 애플리케이션 지연까지 간다.

 ## 관계

@@ -19,9 +19,7 @@ source:

 # 호스트 메모리 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는가

-게스트는 자기가 RAM 에 접근한다고 생각하는데, 그 backing page 가 호스트 RAM 에 없으면 호스트에서는 page fault 와 swap-in I/O 를 기다린 뒤에야 게스트 실행이 이어진다. 개념 문서는 그 경로가 스토리지 경합을 거쳐 애플리케이션 지연까지 이어질 수 있다고 그려 두었을 뿐 이 호스트에서 재지 않았다.
-
-이 물음은 baseline 을 잡고 호스트에 메모리 압박을 유도한 뒤 게스트 지연을 다시 재서, 그 경로가 실제로 이어지는지 확인한다.
+개념 문서가 그린 경로대로 호스트 메모리 압박이 스토리지 경합을 거쳐 게스트 애플리케이션 지연까지 이어지는지 이 호스트에서 재지 않았다. 게스트는 자기가 RAM 에 접근한다고 본다. 그런데 backing page 가 호스트 RAM 에 없으면 호스트에서 page fault 와 swap-in I/O 를 기다린 뒤에야 게스트 실행이 이어진다.

 ## 관계

@@ -81,13 +79,13 @@ source:
 - 압박을 유도한 상태로 운영 실험을 겹쳐 돌리지 않는다. 같은 스토리지를 쓰는 다른 실험이 있으면 시간을 나눈다.
 - 지연이 올랐다는 관측만으로 원인을 호스트 메모리로 확정하지 않는다. 같은 구간의 CPU 와 스토리지 지표를 함께 놓고 §86 의 분류로 계층을 가른다.
 - 압박의 허용 범위를 정하는 일은 이 물음 밖이다. 여기서는 경로가 이어지는지만 본다.
- 이 실험을 순서에서 앞당기지 않는다. §84 의 권장 실험 순서에서 압박 실험은 열두 단계 가운데 열 번째이고, 앞의 다섯 단계가 호스트와 가상 머신 조건을 채워 두므로 먼저 돌리면 세 구간에 남길 조건을 그때 다시 모아야 한다.
+- 이 실험을 순서에서 앞당기지 않는다. §84 의 권장 실험 순서에서 압박 실험은 열두 단계 가운데 열 번째다. 앞의 다섯 단계가 호스트와 가상 머신 조건을 채워 두므로, 먼저 돌리면 세 구간에 남길 조건을 그때 다시 모아야 한다.

 ## 선택지

 ### 1. 세 구간을 한 번에 돌리고 네 종류 지표를 같이 남긴다

-baseline, 압박, 압박 해제 세 구간에서 게스트 지연 · 호스트 vmstat · 스토리지 지연 · CPU 를 같은 시각에 기록한다. §83 OQ-7 이 적은 순서 그대로이고, 세 구간이 한 표에 들어가면 지연 변화가 어느 지표와 함께 움직였는지 그 표에서 읽힌다.
+baseline, 압박, 압박 해제 세 구간에서 게스트 지연 · 호스트 vmstat · 스토리지 지연 · CPU 를 같은 시각에 기록한다. §83 OQ-7 이 적은 순서 그대로다. 세 구간이 한 표에 들어가면 지연 변화가 어느 지표와 함께 움직였는지 그 표에서 읽힌다.

 압박을 유도하는 방법을 먼저 정해야 하고, 게스트에 같은 부하를 세 번 거는 준비가 필요하다.

@@ -18,11 +18,7 @@ source:

 # 이 호스트의 THP 정책과 huge page 상태는 무엇인가

-THP(Transparent Huge Pages, 투명한 대형 페이지)는 커널이 조건이 맞는 메모리 영역에 Huge Page 를 알아서 활용하려는 기능이다. 그 활용 범위를 정하는 정책 값이 커널과 배포판, 호스트 설정에 따라 다르다 보니, 개념 문서는 값을 적지 않고 실제 시스템에서 읽으라고만 했다.
-
-이 물음은 그 값을 읽는 데서 끝난다. 정책이 always 인지 madvise 인지 never 인지, 그리고 huge page 항목 넷의 값이 호스트와 두 게스트에 대해 적히면 닫힌다.
-
-§83 이 적은 열린 물음 열넷 가운데 확인 명령이 함께 적힌 것은 아홉이고 OQ-4 가 그 아홉에 든다. 명령이 없는 다섯은 전부 구간을 나눠 견주는 실험이고, 이 물음은 명령 두 줄의 출력으로 닫힌다.
+이 호스트의 THP 정책이 always 인지 madvise 인지 never 인지, huge page 항목 넷의 값이 얼마인지 아직 읽지 않았다. THP(Transparent Huge Pages, 투명한 대형 페이지)는 커널이 조건이 맞는 영역에 Huge Page 를 활용하려는 기능이다. 정책 값은 커널과 배포판에 따라 다르다.

 ## 관계

@@ -52,6 +48,7 @@ THP(Transparent Huge Pages, 투명한 대형 페이지)는 커널이 조건이
  HugePages_Total
  HugePages_Free
  Hugepagesize
+- §83 이 적은 열린 물음 열넷 가운데 확인 명령이 함께 적힌 것은 아홉이고, OQ-4 가 거기 든다. 명령이 없는 나머지 다섯은 전부 구간을 나눠 견주는 실험이다.
 - 이 호스트에서 그 다섯을 읽은 기록이 개념 문서에 없다. 게스트 쪽 값도 없다.

 ## 가정
@@ -99,4 +96,4 @@ THP(Transparent Huge Pages, 투명한 대형 페이지)는 커널이 조건이
 3. 같은 두 명령을 가상 머신마다 따로 찍고 호스트 값과 나란히 적는다.
 4. 실행한 명령과 출력, 찍은 시각을 함께 증거로 남긴다.

-닫는 조건 : 다섯 항목의 값이 호스트와 각 게스트에 대해 적히면 닫는다. HugePages_Total 이 0 이 아니면 그 풀을 가상 머신이 쓰고 있는지는 「가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가」가 받는다. 정책이 always 로 나오고 지연에 민감한 워크로드를 돌리고 있으면 §54 가 든 compaction 영향을 측정할지는 Decision 으로 넘긴다. 이 물음 자체는 정책 값을 확정하는 데서 끝난다.
+닫는 조건 : 다섯 항목의 값이 호스트와 게스트마다 적히면 닫는다. HugePages_Total 이 0 이 아니면 그 풀을 가상 머신이 쓰고 있는지는 「가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가」가 받는다. 정책이 always 로 나오고 지연에 민감한 워크로드를 돌리고 있으면 §54 가 든 compaction 영향을 측정할지는 Decision 으로 넘긴다. 이 물음 자체는 정책 값을 확정하는 데서 끝난다.
@@ -18,11 +18,7 @@ source:

 # NUMA remote access 가 이 작업의 지연을 실제로 바꾸는가

-NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 어느 CPU 가 어느 RAM 에 접근하느냐에 따라 비용이 달라질 수 있는 구조다. 배치가 어긋나 있다는 것과 그 어긋남 때문에 느려진다는 것은 다른 확인이다.
-
-개념 문서는 remote access 가 local access 와 같은 비용이라고 가정할 수 없다고까지 적었는데, 얼마나 다른지는 적지 않았다. 단순 토폴로지만 보고 성능 문제라고 단정하지 말라는 단서도 같은 항목에 달렸다. 이 물음은 이 호스트에서 같은 워크로드를 local 배치와 remote 위주 배치로 각각 돌려 두 값을 견주는 데까지 간다.
-
-§83 의 열린 물음 열넷 가운데 둘은 이 주제로 올리지 않고 CPU 가상화 쪽 물음에 합쳤다. 노드 수와 vCPU 배치는 한 번 읽으면 닫히고 그 물음이 이미 같은 것을 묻고 있어서다. 이 물음은 합치지 않았는데, 토폴로지를 아는 것과 지연이 달라지는 것이 한 번의 측정으로 함께 닫히지 않기 때문이다.
+이 호스트에서 local 배치와 remote 위주 배치로 같은 워크로드를 돌려 두 값을 견준 기록이 없다. NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 어느 CPU 가 어느 RAM 에 접근하느냐에 따라 비용이 달라질 수 있는 구조다. 배치가 어긋나 있다는 것과 그 어긋남 때문에 느려진다는 것은 다른 확인이다.

 ## 관계

@@ -38,10 +34,11 @@ NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 어느 CPU 가
 ## 사실

 - remote access 는 local access 와 동일한 비용이라고 가정할 수 없으며, 추가 지연과 대역폭 비용이 있을 수 있다.
- 큰 가상 머신에서는 게스트에게 NUMA 토폴로지 자체를 노출할 수 있고, 가능하면 게스트가 인식하는 토폴로지와 실제 호스트 배치가 합리적으로 맞물리도록 구성할 수 있다. 개념 문서가 든 예는 노드마다 vCPU 여덟과 RAM 32 GiB 를 둔 가상 머신이고, 이 프로젝트의 가상 머신이 그 크기인지는 적혀 있지 않다.
+- 큰 가상 머신에서는 게스트에게 NUMA 토폴로지 자체를 노출할 수 있고, 가능하면 게스트가 인식하는 토폴로지와 실제 호스트 배치가 합리적으로 맞물리도록 구성할 수 있다. 개념 문서가 든 예는 노드마다 vCPU 여덟과 RAM 32 GiB 를 둔 가상 머신이다. 이 프로젝트의 가상 머신이 그 크기인지는 적혀 있지 않다.
 - 개념 문서가 적은 실험 순서는 local 배치로 baseline 을 잡고 지연과 처리량과 메모리 지표를 받은 뒤, remote 위주 배치로 바꿔 동일 워크로드를 다시 돌려 견주는 것이다.
 - 같은 항목이 NUMA node 가 2개 이상인 경우에만 우선순위를 높이라고 적었다.
 - 단순 토폴로지만 보고 성능 문제라고 단정하지 않는다는 단서도 같은 항목에 있다.
+- §83 의 열린 물음 열넷 가운데 둘은 이 주제로 올리지 않고 CPU 가상화 쪽 물음에 합쳤다. 노드 수와 vCPU 배치는 한 번 읽으면 닫히는 데다, 그 물음이 이미 같은 것을 묻고 있어서다. 이 물음은 합치지 않았는데, 토폴로지를 아는 것과 지연이 달라지는 것이 한 번의 측정으로 함께 닫히지 않기 때문이다.
 - 개념 문서는 이 비교에 쓸 워크로드도, 지연과 처리량을 재는 명령도 적지 않았다. 실험 순서만 적혀 있다.
 - 이 호스트에서 두 배치를 각각 구성해 본 기록이 없다.

@@ -71,7 +68,7 @@ NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 어느 CPU 가

 ### 1. 같은 워크로드를 두 배치에서 돌려 값을 견준다

-local 배치에서 지연과 처리량과 메모리 지표를 받고, remote 위주로 바꿔 같은 워크로드를 같은 조건으로 다시 돌린다. 개념 문서가 적은 순서 그대로이고, 차이가 나든 나지 않든 그 값이 다음 판단의 근거가 된다.
+local 배치에서 지연과 처리량과 메모리 지표를 받고, remote 위주로 바꿔 같은 워크로드를 같은 조건으로 다시 돌린다. 개념 문서가 적은 순서를 그대로 따르는 방법이라, 차이가 나든 나지 않든 그 값이 다음 판단의 근거가 된다.

 배치를 바꾸는 방법을 먼저 정해야 하고, 두 실행 사이에 다른 조건을 고정하는 데 손이 간다.

@@ -19,9 +19,7 @@ source:

 # QEMU 메모리는 vCPU 가 도는 NUMA node 와 같은 node 에 있는가

-NUMA(Non-Uniform Memory Access)는 어느 CPU 가 어느 RAM 에 닿느냐에 따라 접근 비용이 달라지는 구조를 말한다. 게스트의 vCPU 는 호스트에서 QEMU 의 vCPU 스레드이고, 그 스레드를 어느 논리 CPU 에 올릴지는 호스트 스케줄러가 정한다. 그 가상 머신의 메모리를 실제로 떠받치는 호스트 쪽 페이지가 어느 노드에 있는지는 그것과 따로 정해진다. 둘이 다른 노드로 갈리면 게스트 안에서는 평범한 memory load 로 보이는 동작이 실제 하드웨어에서는 노드 사이 interconnect 를 건넌다.
-
-이 물음이 받는 것은 그 어긋남이 성능을 바꾸는지가 아니다. 이 호스트의 가상 머신마다 vCPU 배치와 메모리 배치가 지금 어디에 놓여 있는지를 값으로 적는 데까지다.
+이 호스트의 가상 머신마다 vCPU 가 도는 노드와 메모리가 놓인 노드가 같은지 다른지 적은 값이 없다. NUMA(Non-Uniform Memory Access)는 어느 CPU 가 어느 RAM 에 닿느냐에 따라 접근 비용이 달라지는 구조를 말한다. 이 물음은 지금 배치를 값으로 적는 데까지다. 그 어긋남이 지연을 바꾸는지는 다른 물음이 받는다.

 ## 관계

@@ -37,7 +35,7 @@ NUMA(Non-Uniform Memory Access)는 어느 CPU 가 어느 RAM 에 닿느냐에
 ## 사실

 - 게스트 vCPU 는 호스트에서 QEMU 의 vCPU 스레드이고, 그 스레드는 호스트 Linux 스케줄러를 거쳐 호스트 논리 CPU 에서 실행된다.
- 어떤 가상 머신의 vCPU 스레드가 Node 0 의 CPU 에서 도는데 그 가상 머신의 호스트 쪽 physical backing page 가 Node 1 에 있으면 remote access 가 생길 수 있다. 게스트 안에서는 그것도 단순한 memory load 로 보인다.
+- 어떤 가상 머신의 vCPU 스레드가 Node 0 의 CPU 에서 도는데 그 가상 머신의 호스트 쪽 physical backing page 가 Node 1 에 있으면 remote access 가 생길 수 있다. 게스트 안에서는 그것도 단순한 memory load 로 보이지만 실제 하드웨어에서는 NUMA interconnect 를 건널 수 있다.
 - vCPU 를 특정 노드의 CPU 에 pinning 해도 메모리가 다른 노드에 주로 배치되어 있으면 pinning 이후에도 remote memory access 가 많아질 수 있다. 그래서 vCPU 배치와 메모리 배치를 함께 본다.
 - 개념 문서가 이상적인 예로 든 구성은 한 가상 머신의 vCPU 넷이 Node 0 의 CPU 에 붙고 그 가상 머신의 메모리 backing 도 Node 0 RAM 인 경우다.
 - 개념 문서는 이 확인에 쓸 명령을 적어 두었다.
@@ -79,14 +77,14 @@ QEMU 프로세스마다 numastat -p 를 돌리고, 같은 시각에 virsh vcpuin

 ### 2. 부하를 준 상태에서 한 번 더 받는다

-idle 상태의 배치만 보면 메모리가 아직 실제로 할당되지 않은 구간을 볼 수 있다. 게스트에서 workload 를 돌린 뒤 같은 두 값을 다시 받으면 실제로 쓰이는 메모리가 어느 노드에 잡히는지까지 나온다.
+idle 상태의 배치만 보면 메모리가 아직 실제로 할당되지 않은 구간을 볼 수 있다. 게스트에서 워크로드를 돌린 뒤 같은 두 값을 다시 받으면 실제로 쓰이는 메모리가 어느 노드에 잡히는지까지 나온다.

-실행이 두 번으로 늘고 어느 workload 를 쓸지 먼저 정해야 하는데, 그 선택이 결과를 바꾸기 때문에 workload 조건을 함께 적는다.
+실행이 두 번으로 늘고 어느 워크로드를 쓸지 먼저 정해야 하는데, 그 선택이 결과를 바꾸기 때문에 Workload 조건을 함께 적는다.

 ### 3. 게스트 안에서 numactl 로 확인한다 — 제외

 게스트에서도 NUMA 를 볼 수 있으니 게스트 안에서 확인하자는 방법이다.
-게스트가 보는 토폴로지는 가상 머신에 노출된 것이고 이 물음이 찾는 것은 호스트 쪽 physical backing 이 어느 노드에 있느냐이므로, 게스트 쪽 값으로는 그 배치를 알 수 없다.
+게스트가 보는 토폴로지는 가상 머신에 노출된 것이다. 이 물음이 찾는 것은 호스트 쪽 physical backing 이 어느 노드에 있느냐이므로, 게스트 쪽 값으로는 그 배치를 알 수 없다.
 개념 문서는 큰 가상 머신에서 게스트에게 NUMA 토폴로지 자체를 노출하고 게스트 노드와 호스트 배치가 대응되도록 구성할 수 있다고 적어 두었다. 이 프로젝트의 가상 머신이 그런 구성인지는 그 문서에 없어서, 게스트 값이 호스트 배치를 어디까지 반영하는지도 재기 전에는 모른다.

 ## 다음 검증
@@ -94,7 +92,7 @@ idle 상태의 배치만 보면 메모리가 아직 실제로 할당되지 않
 1. 호스트가 다중 NUMA 노드라는 확인을 CPU 가상화 쪽 물음에서 먼저 받는다.
 2. 가상 머신마다 QEMU 프로세스를 찾아 numastat -p <QEMU_PID> 로 노드별 메모리 분포를 찍는다.
 3. 같은 시각에 virsh vcpuinfo <VM_NAME> 와 virsh vcpupin <VM_NAME> 로 vCPU 배치를 적는다.
-4. 두 값을 가상 머신마다 한 표로 나란히 놓고, 노드가 같은지 갈리는지 적는다.
+4. 두 값을 가상 머신마다 한 표로 나란히 놓고, 노드가 같은지 다른지 적는다.
 5. Host · VM · Workload 조건을 같은 기록에 남긴다.

 닫는 조건 : 노드별 메모리 분포와 vCPU 배치가 가상 머신마다 한 표로 적히면 닫는다. 둘이 같은 노드로 모여 있으면 개념 문서가 경고한 어긋남이 이 환경에는 없다고 적고 닫는다. 어긋나 있으면 그 표가 Case 가 되고, 그 어긋남이 지연까지 바꾸는지는 「NUMA remote access 가 이 작업의 지연을 실제로 바꾸는가」가 받는다. memory binding 을 걸지 말지는 그 뒤 Decision 으로 넘긴다. 단일 NUMA 노드로 나오면 이 물음은 이 환경에 적용되지 않는다고 적고 닫는다.
@@ -19,16 +19,14 @@ source:

 # QEMU 프로세스가 실제로 붙잡고 있는 호스트 메모리는 얼마이고 어떻게 나뉘어 있는가

-게스트 RAM 은 QEMU(Quick Emulator, 가상 머신을 실행하는 호스트 userspace 프로그램) 프로세스의 주소 공간 안에 마련된다고 §40 이 적었다. 그래서 「이 가상 머신이 호스트 메모리를 얼마나 쓰고 있는가」는 그 프로세스가 지금 얼마나 큰지를 읽는 물음이 된다.
-
-이 물음은 실행 중인 가상 머신마다 QEMU 프로세스가 호스트에 얼마나 resident 한지, 그 값이 설정한 메모리(configured memory)와 얼마나 벌어져 있는지, 그리고 그 backing 이 anonymous 인지 huge page 인지를 적는다. 이 호스트에서 그 값을 읽은 기록은 없다.
+이 호스트에서 QEMU 프로세스가 붙잡고 있는 메모리를 읽은 기록이 없다. 게스트 RAM 은 QEMU(Quick Emulator, 가상 머신을 실행하는 호스트 userspace 프로그램) 프로세스의 주소 공간 안에 마련된다고 §40 이 적었다. 그래서 이 가상 머신이 호스트 메모리를 얼마나 쓰고 있는가는 그 프로세스가 얼마나 큰지를 읽는 물음이 된다.

 ## 관계

 - **Guest 메모리 주소가 물리 RAM 에 닿기까지 — GVA · GPA · HPA**
  QEMU 가 마련한 호스트 주소 공간이 게스트 물리 주소와 어떻게 이어지는지를 그 기록이 설명한다.
 - **이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가**
-  같은 접속에서 값을 받는다. 그쪽이 적는 설정 값을 옆에 놓아야 여기서 벌어짐을 적을 수 있다.
+  같은 접속에서 값을 받는다. 그쪽이 적는 설정 값을 옆에 놓아야 여기서 얼마나 벌어져 있는지 적을 수 있다.
 - **가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가**
  여기서 huge page 항목이 보이면 그 물음으로 넘긴다.
 - **메모리 실험 결과에는 Host · VM · Workload 조건을 함께 남긴다**
@@ -42,7 +40,7 @@ source:

 §41 은 QEMU 가 마련한 호스트 userspace 메모리 영역이 게스트 GPA 의 어느 범위를 떠받치는지를 KVM 에 등록한다고 적고, 대표 ioctl 로 KVM_SET_USER_MEMORY_REGION 을 들었다. 역할은 셋으로 갈린다. QEMU 는 게스트 RAM 을 위한 호스트 userspace backing 을 내주고, KVM 은 게스트의 메모리 영역과 가상화 매핑을 관리하며, 실행 중의 주소 변환은 CPU 가 한다.

-§42 는 설정한 메모리와 게스트가 현재 실제 사용하는 메모리, 호스트에서 현재 resident 한 물리 메모리 셋이 같지 않을 수 있다고 적었다. 그 차이를 만드는 것으로 호스트의 demand paging, backing 종류, HugeTLB, memory locking, preallocation, overcommit 정책을 들었다.
+§42 는 설정한 메모리(configured memory)와 게스트가 현재 실제 사용하는 메모리, 호스트에서 현재 resident 한 물리 메모리 셋이 같지 않을 수 있다고 적었다. 그 차이를 만드는 것으로 호스트의 demand paging, backing 종류, HugeTLB, memory locking, preallocation, overcommit 정책을 들었다.

 §83 의 OQ-3 은 확인 명령으로 ps -ef | grep qemu 와 ps -o pid,rss,vsz,cmd -p <QEMU_PID> 를 적었다. 필요하면 cat /proc/<QEMU_PID>/status 와 cat /proc/<QEMU_PID>/smaps_rollup 을 보고, 설정한 메모리와 RSS/anonymous/huge-page 상태를 비교하라고 했다.

@@ -74,7 +72,7 @@ smaps_rollup 을 읽을 권한이 있다고 전제한다. 다른 사용자의

 이 호스트에서 QEMU 프로세스의 크기를 읽은 값이 없다. §40 의 8 GiB 와 §42 의 16 GiB 는 설명을 위한 예시이므로 이 환경의 값으로 옮겨 쓰지 않는다.

-설정한 메모리를 옆에 놓지 않으면 벌어짐을 적을 수 없다. 그 값은 「이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가」가 받는다.
+설정한 메모리를 옆에 놓지 않으면 얼마나 벌어져 있는지 적을 수 없다. 그 값은 「이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가」가 받는다.

 §42 가 게스트 사용량과 호스트 resident 를 다른 값으로 갈라 놓았기 때문에, resident 크기 하나로는 게스트가 그 메모리를 지금 쓰고 있는지 알 수 없다.

@@ -105,7 +103,7 @@ backing 이 anonymous 인지 huge page 인지는 나오지 않는다. 그 항목
 1. ps -ef | grep qemu 로 실행 중인 QEMU 프로세스의 PID 를 찾고 가상 머신 이름과 짝짓는다 (§83 OQ-3).
 2. 프로세스마다 ps -o pid,rss,vsz,cmd -p <QEMU_PID> 를 찍는다.
 3. cat /proc/<QEMU_PID>/status 와 cat /proc/<QEMU_PID>/smaps_rollup 을 남겨 anonymous 와 huge page 항목을 읽는다.
-4. 같은 접속에서 설정한 메모리와 지금 쓰는 메모리를 묻는 물음의 값을 옆에 놓고 벌어짐을 적는다.
+4. 같은 접속에서 설정한 메모리와 지금 쓰는 메모리를 묻는 물음의 값을 옆에 놓고 얼마나 벌어져 있는지 적는다.
 5. 남기는 조건은 메모리 실험 조건 기준을 따른다.

 닫는 조건 : 가상 머신마다 설정 값 · RSS · VSZ 와 anonymous/huge-page 구성이 한 표에 적히면 닫는다. RSS 가 설정 값에 크게 못 미치면 §42 가 말한 차이를 이 호스트에서 확인한 것이 되므로, 주소 변환 개념 기록의 확인 사례로 넣는다. huge page backing 이 보이면 HugeTLB backing 을 묻는 물음으로 넘긴다.
@@ -18,7 +18,7 @@ source:

 # 지금 게스트와 호스트에서 swap 이 실제로 오가고 있는가

-Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다는 뜻은 아니다. 그 값이 과거에 swap-out 된 cold page 때문에 커져 있을 수도 있어서, §63 은 값이 얼마인가 대신 지금 swap-in/out 이 지속되는가를 물으라고 적었다. 이 물음은 그 질문을 이 호스트와 두 게스트에서 같은 시각에 던진다. 게스트 swap 과 호스트 swap 은 서로 다른 경로이므로 한쪽만 보고 다른 쪽을 짐작하지 않는다.
+Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다는 뜻은 아니다. 그 값이 과거에 swap-out 된 cold page 때문에 커져 있을 수도 있어서, §63 은 값이 얼마인가 대신 지금 swap-in/out 이 지속되는가를 물으라고 적었다. 이 물음은 그 질문을 이 호스트와 게스트 세 대에서 같은 시각에 던진다. 게스트 swap 과 호스트 swap 은 서로 다른 경로이므로 한쪽만 보고 다른 쪽을 짐작하지 않는다.

 ## 관계

@@ -46,14 +46,16 @@ Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다
 - §61 은 게스트 swap 을 게스트 애플리케이션에서 시작해 게스트 메모리 압박, 게스트 커널, 게스트 swap, /dev/vda, virtio-blk, QEMU 를 거쳐 호스트 스토리지로 내려가는 경로로 그렸다.
 - §61 은 호스트 swap 을 게스트 RAM 이 QEMU 의 메모리 backing 을 거쳐 호스트 메모리 압박을 받고 호스트 커널이 호스트 swap 으로 내리는 경로로 그렸다. 같은 절이 두 경로를 같지 않다고 적고, 게스트가 메모리 여유가 있어 보이는데 호스트에서 swap 이나 reclaim 이 심할 수도 있다고 덧붙였다.
 - 개념 문서는 vmstat 출력에서 어느 열을 swap-in 과 swap-out 으로 읽는지 적지 않았다.
- 이 호스트와 두 게스트에서 free -h 나 vmstat 를 찍은 기록이 개념 문서에 없다.
+- 호스트에서 free 를 찍은 기록은 §178 과 §197 에 있다. 2026-09-10 에 test-server 에서 free -m 을 head -2 로 잘라 받은 출력이라 Mem 줄까지만 남아 있고 Swap 줄이 없다.
+- 게스트 세 대에서 free 나 vmstat 를 찍은 기록도, 호스트에서 vmstat 를 돌린 기록도 개념 문서에 없다.
+- §187 이 적은 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대다.

 ## 가정

- 호스트와 두 게스트에 동시에 접속해 같은 구간을 관측할 수 있다고 본다.
+- 호스트와 게스트 세 대에 동시에 접속해 같은 구간을 관측할 수 있다고 본다.
 - 관측하는 동안 실험용 부하를 따로 걸지 않고 평상시 상태를 재는 것으로 둔다. 그 상태가 이 호스트의 대표적인 상태인지는 한 번의 관측으로 알 수 없다.
 - 게스트와 호스트의 시계가 맞아 두 기록을 같은 시간축에 놓을 수 있다고 전제한다.
- 두 가상 머신 모두 swap 영역을 갖고 있다고 보고 게스트 쪽을 읽는다. 설정에 swap 이 없으면 게스트 쪽 관측은 그 사실로 끝난다.
+- 게스트 세 대 모두 swap 영역을 갖고 있다고 보고 게스트 쪽을 읽는다. 설정에 swap 이 없으면 게스트 쪽 관측은 그 사실로 끝난다.

 ## 미지수

@@ -61,6 +63,7 @@ Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다
 - Swap Used 가 0 이 아니라면 그 값이 과거에 내려간 cold page 때문인지 지금 진행 중인 swap 활동 때문인지.
 - §63 이 든 나머지 셋 가운데 reclaim pressure 와 major fault 를 이 환경에서 어떤 값으로 읽는지. 그 둘을 읽는 명령은 개념 문서에 없다.
 - 관측을 얼마나 오래 해야 지속 여부를 말할 수 있는지. 개념 문서는 vmstat 1 만 적고 관측 길이를 적지 않았다.
+- 호스트에 swap 영역이 설정돼 있는지. §178 과 §197 의 free 출력이 Mem 줄까지만 잘려 있어 Swap 줄을 보지 못했다.

 ## 제약

@@ -75,9 +78,9 @@ Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다

 ### 1. 게스트와 호스트에서 같은 구간을 동시에 관측한다

-세 곳에서 free -h 를 한 번 찍어 기준을 남기고, vmstat 1 을 같은 시각에 시작해 같은 길이로 돌린다. §61 이 갈라 놓은 두 경로가 같은 시간축의 값으로 남아 한쪽만 움직이는 경우와 둘 다 움직이는 경우를 구분할 수 있다.
+호스트와 게스트 세 대, 네 곳에서 free -h 를 한 번 찍어 기준을 남기고 vmstat 1 을 같은 시각에 시작해 같은 길이로 돌린다. §61 이 갈라 놓은 두 경로가 같은 시간축의 값으로 남아 한쪽만 움직이는 경우와 둘 다 움직이는 경우를 구분할 수 있다.

-세 곳에 동시에 붙어야 하고 관측 길이를 먼저 정해야 한다.
+네 곳에 동시에 붙어야 하고 관측 길이를 먼저 정해야 한다.

 ### 2. 호스트만 먼저 관측한다

@@ -91,9 +94,9 @@ free -h 한 번씩으로 끝내는 방법이다. §63 이 그 값만으로 판

 ## 다음 검증

-1. 호스트와 각 게스트에서 free -h 를 한 번씩 찍어 그 시점의 Swap Used 를 기준으로 남긴다.
-2. 세 곳에서 vmstat 1 을 같은 시각에 시작해 미리 정한 길이만큼 돌리고, 출력에서 swap-in 과 swap-out 으로 읽은 열의 이름을 함께 적는다.
+1. 호스트와 각 게스트에서 free -h 를 한 번씩 찍어 그 시점의 Swap Used 를 기준으로 남긴다. 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대다.
+2. 네 곳에서 vmstat 1 을 같은 시각에 시작해 미리 정한 길이만큼 돌리고, 출력에서 swap-in 과 swap-out 으로 읽은 열의 이름을 함께 적는다.
 3. 같은 구간에서 §63 이 든 나머지 셋 가운데 읽을 수 있는 것 — reclaim pressure · major fault · storage latency — 을 어떤 명령으로 읽었는지와 함께 남긴다.
-4. 세 기록을 같은 시간축에 놓고 어느 쪽에서 무엇이 움직였는지 적는다.
+4. 네 기록을 같은 시간축에 놓고 어느 쪽에서 무엇이 움직였는지 적는다.

 닫는 조건 : 관측 구간 내내 게스트와 호스트 모두 swap-in 과 swap-out 이 0 이면 지금은 swap 이 오가지 않는다고 적고 닫는다. Swap Used 가 0 이 아니어도 그렇게 적는다. 한쪽에서 swap 이 오가면 §61 의 두 경로 중 어느 쪽인지를 적고, 그 구간의 스토리지 지연과 게스트 지연을 함께 적어 「호스트 메모리 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는가」로 넘긴다.
@@ -18,7 +18,7 @@ source:

 # 이 가상 머신들에 virtio-balloon 이 붙어 있는가

-virtio-balloon 은 게스트 커널 쪽 드라이버와 QEMU 쪽 장치가 virtqueue 로 맞물려 동작한다. 장치가 없거나 게스트 쪽 드라이버가 올라와 있지 않으면 balloon target 을 바꾸는 실험 자체가 성립하지 않으므로, 동적 메모리 회수를 다루기 전에 이 확인이 먼저다. 개념 문서는 확인 명령까지만 적고 이 호스트의 설정은 읽지 않았다.
+libvirt 설정에서 balloon 장치를 읽은 기록이 아직 없다. 다만 §198 의 virsh dommemstat 실측에서 kc-lab-2 의 현재 할당이 선언한 4096MB 가 아니라 3120MB 로 나왔다. 근거 문서는 그것을 virtio-balloon 이 회수해 간 것으로 보인다고 적었다. 장치가 없거나 게스트 쪽 드라이버가 올라와 있지 않으면 balloon target 을 바꾸는 실험이 성립하지 않으므로, 설정과 게스트 쪽 상태를 읽는 이 확인이 먼저다.

 ## 관계

@@ -40,11 +40,18 @@ virtio-balloon 은 게스트 커널 쪽 드라이버와 QEMU 쪽 장치가 virtq
 - §83 OQ-8 은 환경에 따라 드라이버 이름과 표시 방식이 달라질 수 있으므로 실제 장비에서 검증하라는 단서를 달았다.
  그래서 개념 문서에는 게스트 쪽에서 무엇을 찾아야 하는지가 이름으로 적혀 있지 않다.
 - §83 OQ-2 는 가상 머신 메모리 확인 명령으로 virsh dominfo <VM_NAME> · virsh dumpxml <VM_NAME> · virsh dommemstat <VM_NAME> 셋을 들었다.
+- §198 은 VM 에 준 메모리가 상한이지 점유가 아니라고 적으면서 virtio-balloon 이 안 쓰는 만큼 호스트에 돌려준다고 덧붙였다.
+- §198 이 virsh dommemstat 으로 k3s 게스트 두 대를 재서 아래 값을 받았다. k3s 만 떠 있고 Keycloak 은 올리기 전 상태다.
+  kc-lab-1 : 할당 5120MB · 실사용 353MB
+  kc-lab-2 : 할당 3120MB · 실사용 301MB
+- kc-lab-2 는 virt-install --memory 4096 으로 만들었는데 현재 할당이 3120MB 로 나왔다. §198 은 그것을 virtio-balloon 이 회수해 간 것으로 보인다고 적고 단정하지 않았다.
+- §198 은 dommemstat 의 actual 이 현재 할당이고 선언한 상한은 virsh dominfo 의 Max memory 에 있다고 적으면서, 이 실험대에서 그 두 값을 나란히 찍어 보지 않았다고 미측정으로 남겼다.
+- §187 이 적은 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대이고, §198 의 측정에 kc-lab-edge 는 들어 있지 않다.
 - 이 호스트의 가상 머신 설정에서 balloon 관련 요소를 읽은 기록이 개념 문서에 없다.

 ## 가정

- 두 가상 머신 모두 libvirt 로 정의되어 있어 virsh dumpxml 로 설정을 통째로 읽을 수 있다고 본다.
+- 게스트 세 대 모두 libvirt 로 정의되어 있어 virsh dumpxml 로 설정을 통째로 읽을 수 있다고 본다.
 - 설정에 balloon 장치가 있으면 게스트 쪽에도 대응하는 드라이버가 보인다고 전제한다. 그 전제가 이 게스트 배포판에서 맞는지는 확인하지 않았다.
 - 게스트에 접속해 장치 목록이나 커널 모듈 상태를 읽을 수 있다고 본다.

@@ -54,10 +61,13 @@ virtio-balloon 은 게스트 커널 쪽 드라이버와 QEMU 쪽 장치가 virtq
 - 있다면 게스트 안에서 그 드라이버가 실제로 올라와 있는지.
 - 이 환경에서 그 드라이버나 장치가 어떤 이름으로 보이는지. 개념 문서가 환경마다 다를 수 있다고만 적고 이름을 남기지 않았다.
 - 게스트 쪽 상태를 어떤 명령으로 읽는지. 개념 문서가 게스트 확인 명령을 적지 않아 실행하는 쪽이 정한다.
+- kc-lab-2 의 현재 할당이 선언값보다 작은 것이 balloon 회수 때문인지 다른 경로로 정해진 값인지. §332 는 virsh setmem 이 현재 할당을 바꾸는 명령이라고 적었다. §187 은 게스트 메모리를 3584MB 에서 5120MB 와 4096MB 로 재배분했다고 적었다.
+- kc-lab-edge 의 값. §198 이 그 게스트를 재지 않았다.

 ## 제약

 - 이 물음에서 balloon target 을 움직이지 않는다. 구성 여부를 적는 것이 전부다.
+- §198 의 값은 설정 확인을 대신하지 않는다. 근거 문서가 회수해 간 것으로 보인다고 적은 것을 이 물음이 관측으로 올리지 않는다.
 - 설정에 장치가 있다는 것만으로 동작한다고 적지 않는다. §83 OQ-8 이 게스트 쪽 상태도 확인하라고 적었다.
 - 설정과 드라이버가 둘 다 보여도 호스트가 backing 을 실제로 언제 회수하는지는 이 확인으로 알 수 없다. §67 이 정확한 Host-side release 동작은 QEMU/KVM 버전, backing 종류 및 설정에 따라 달라질 수 있다고 적고 그 동작을 단정하지 않았다. 개념 문서가 단정하지 않은 것을 이 물음이 대신 단정하지 않는다.
 - 게스트 쪽에서 쓴 명령과 그 출력을 그대로 남긴다. 이름이 환경마다 다르므로 다음 사람이 같은 것을 찾으려면 무엇을 봤는지가 필요하다.
@@ -70,18 +80,19 @@ virtio-balloon 은 게스트 커널 쪽 드라이버와 QEMU 쪽 장치가 virtq

 가상 머신마다 virsh dumpxml 을 찍어 balloon 관련 요소를 인용하고, 이어서 각 게스트에서 드라이버나 장치 상태를 읽어 실제로 보이는 이름과 함께 적는다. §83 OQ-8 이 요구한 두 확인이 한 번에 끝난다.

-게스트 두 대에 접속해야 하고, 게스트 쪽 확인 명령을 실행하는 쪽이 정해야 한다.
+게스트 세 대에 접속해야 하고, 게스트 쪽 확인 명령을 실행하는 쪽이 정해야 한다.

 ### 2. 호스트 설정만 읽고 넘어간다

-virsh dumpxml 두 번으로 끝난다. 설정에 balloon 장치가 없으면 게스트 쪽을 볼 이유가 없어 이 물음이 거기서 닫힌다.
+게스트마다 virsh dumpxml 을 한 번씩 치는 것으로 끝난다. 설정에 balloon 장치가 없으면 게스트 쪽을 볼 이유가 없어 이 물음이 거기서 닫힌다.

 장치가 있는 것으로 나오면 게스트 쪽 드라이버가 올라와 있는지를 확인하러 다시 가야 한다.

 ## 다음 검증

-1. 가상 머신마다 virsh dumpxml <VM_NAME> 을 남기고 balloon 관련 요소를 그대로 인용한다.
+1. 가상 머신마다 virsh dumpxml <VM_NAME> 을 남기고 balloon 관련 요소를 그대로 인용한다. 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대다.
 2. 각 게스트에서 balloon 관련 드라이버나 장치 상태를 확인하고, 실행한 명령과 실제로 보인 이름을 함께 적는다.
-3. 같은 실행에서 virsh dommemstat <VM_NAME> 출력도 받아 남긴다. 「이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가」가 같은 출력을 읽는다.
+3. 같은 실행에서 virsh dommemstat <VM_NAME> 과 virsh dominfo <VM_NAME> 을 나란히 찍어 현재 할당과 Max memory 를 함께 남긴다. §198 이 dommemstat 만 찍어 그 둘을 나란히 보지 않았다.
+4. 세 게스트의 값을 같은 표에 적는다. 「이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가」가 같은 출력을 읽는다.

 닫는 조건 : 설정과 게스트 쪽 상태가 둘 다 적히면 닫는다. 붙어 있지 않으면 이 환경에서는 ballooning 이 동작하지 않는다고 적고 「balloon target 을 바꾸면 게스트가 쓸 수 있는 메모리는 어떻게 따라 움직이는가」는 열지 않은 채로 둔다. 장치가 없으면 그 실험이 성립하지 않는다. 붙어 있으면 그 물음으로 넘긴다.
@@ -18,9 +18,7 @@ source:

 # 이 호스트의 가상 머신들은 설정한 메모리와 지금 잡고 있는 메모리가 얼마나 다른가

-§42 는 가상 머신에 설정한 메모리와 게스트가 지금 실제로 쓰는 메모리, 그리고 호스트에서 지금 resident 한 물리 메모리를 서로 다른 세 값으로 갈라 놓았다. 이 물음은 그 세 값이 이 호스트에서 각각 얼마인지를 가상 머신마다 적는다.
-
-세 값이 벌어져 있는지에 따라 다음에 무엇을 잴지가 갈린다. 설정한 총량이 호스트 RAM 을 넘으면 §57 이 서술한 overcommit 구성에 이 환경이 들어가고, 넘지 않으면 그 절의 시나리오는 여기 걸리지 않는다. 이 호스트의 물리 RAM 도 각 가상 머신에 설정한 메모리도 개념 문서에 적혀 있지 않다.
+호스트 RAM 11,648MiB 와 게스트 배정 합 10,240MB 가 실측으로 나왔고 배정 합이 더 작다. 게스트가 지금 실제로 쓰는 메모리와 호스트에서 resident 한 물리 메모리는 아직 안 쟀다. 이 물음은 그 두 값을 가상 머신마다 적어 설정 값과 얼마나 벌어지는지를 본다.

 ## 관계

@@ -45,11 +43,21 @@ Host 에서 현재 resident 한 Physical Memory

 세 값을 갈라 놓는 요인으로 §42 가 든 것은 호스트의 demand paging, backing 종류, HugeTLB, memory locking, preallocation, overcommit 정책이다. 그래서 가상 머신 RAM 16 GiB 를 호스트 RAM 에서 고정된 연속 16 GiB 로 단순화하면 안 된다고 같은 절이 적었다.

-§57 은 게스트에 설정한 메모리 총량이 호스트 물리 RAM 보다 큰 구성이 가능할 수 있는 이유를, 설정 용량과 현재 실제 working set 또는 resident 메모리가 같지 않을 수 있다는 데서 찾았다. 다만 모든 가상 머신의 실제 수요가 동시에 증가하면 문제가 발생한다고 이어 적었다.
+설정 용량과 현재 실제 working set 또는 resident 메모리가 같지 않을 수 있기 때문에, 게스트에 설정한 메모리 총량이 호스트 물리 RAM 보다 큰 구성도 가능할 수 있다고 §57 이 적었다. 다만 모든 가상 머신의 실제 수요가 동시에 증가하면 문제가 발생한다고 이어 적었다.

 §83 의 OQ-2 는 확인 명령을 호스트 쪽과 게스트 쪽으로 나눠 적었다. 호스트에서는 virsh dominfo <VM_NAME> 과 virsh dumpxml <VM_NAME>, virsh dommemstat <VM_NAME> 을 쓰고, 게스트에서는 free -h 와 cat /proc/meminfo 를 쓴 뒤 호스트의 QEMU 프로세스 상태와 비교한다.

-이 호스트의 물리 RAM 과 각 가상 머신에 설정한 메모리를 적은 값은 개념 문서 어디에도 없다. §57 의 32 GiB 와 16 GiB, §42 의 16 GiB 는 설명을 위한 예시다.
+이 호스트의 물리 RAM 은 §178 이 실측으로 적었다. 2026-09-10 에 test-server 에서 free -m 으로 받은 출력의 Mem 줄 total 이 11648 이고, free -m 은 MiB 단위라 11,648MiB 다.
+
+게스트 세 대에 배정한 메모리는 §187 이 적었다.
+
+kc-lab-edge : 1024MB
+kc-lab-1 : 5120MB
+kc-lab-2 : 4096MB
+
+배정 합은 10,240MB 다. 호스트 RAM 11,648MiB 보다 작아서 배정률은 10240/11648 = 87.9% 이고, 배정하지 않고 남은 것이 1,408MiB 다. 그래서 「Guest configured memory 총량이 Host physical RAM보다 크다」는 §57 의 조건에 이 배치는 해당하지 않는다.
+
+§57 의 32 GiB 와 16 GiB, §42 의 16 GiB 는 설명을 위한 예시라 이 환경의 값이 아니다.

 §85 가 실험마다 함께 남기라고 적은 VM 조건에 Configured RAM 과 Current RAM 이 들어 있다. 이 물음이 내는 값은 여기서 한 번 쓰고 마는 것이 아니라 뒤따르는 메모리 실험의 조건 칸으로 그대로 들어간다.

@@ -65,21 +73,19 @@ Host 에서 현재 resident 한 Physical Memory

 ## 미지수

-이 호스트의 물리 RAM 은 얼마인가.
+지금 각 게스트가 실제로 쓰고 있는 메모리는 얼마인가.

-각 가상 머신에 설정한 메모리는 얼마이고, 그 합이 호스트 RAM 을 넘는가.
+호스트에서 그 가상 머신 몫으로 resident 한 메모리는 얼마인가.

-넘든 넘지 않든, 지금 각 게스트가 실제로 쓰고 있는 메모리는 얼마이고 호스트에서 그 가상 머신 몫으로 resident 한 메모리는 얼마인가.
-
-세 값이 설정 값과 얼마나 벌어져 있는가.
+그 두 값이 배정한 값과 얼마나 벌어져 있는가.

 ## 제약

-이 호스트에서 잰 값이 없다. §42 와 §57 이 든 숫자는 개념을 보이려고 든 예시이므로 이 환경의 값으로 옮겨 쓰지 않는다.
+게스트 사용량과 호스트 resident 는 이 호스트에서 잰 값이 없다. §42 와 §57 이 든 숫자는 개념을 보이려고 든 예시이므로 이 환경의 값으로 옮겨 쓰지 않는다.

 §84 의 권장 실험 순서는 가상 머신 설정 값 확인과 게스트 free/meminfo 확인을 둘째와 셋째로 나눠 적었다. 여기서는 그 둘을 한 물음으로 묶는다. 이 물음이 답할 것이 세 값의 차이라서 호스트 쪽과 게스트 쪽을 다른 시각에 찍으면 그 차이가 어느 시점의 것인지 말할 수 없다.

-세 값을 서로 다른 시각에 찍으면 비교가 성립하지 않는다. 게스트 사용량은 workload 가 달라지면 같이 움직인다.
+세 값을 서로 다른 시각에 찍으면 비교가 성립하지 않는다. 게스트 사용량은 워크로드가 달라지면 같이 움직인다.

 이 물음은 설정한 값과 실제 사용량의 차이를 적는 데까지다. 그 차이가 있을 때 무엇이 일어나는지는 swap 과 호스트 메모리 압박을 다루는 물음들이 받는다.

@@ -89,15 +95,15 @@ QEMU 프로세스 쪽 값은 여기서 닫지 않는다. virsh 가 보고하는

 ### 1. 실행 중인 가상 머신 전부를 한 번에 찍는다

-virsh list 로 실행 중인 가상 머신을 세고, 각각에 대해 호스트 세 명령과 게스트 두 명령을 같은 시각에 돌린다. 설정 총량과 호스트 RAM 을 그 자료 하나로 견줄 수 있어서 overcommit 여부가 이 실행에서 정해진다.
+virsh list 로 실행 중인 가상 머신을 세고, 가상 머신마다 호스트 세 명령과 게스트 두 명령을 같은 시각에 돌린다. 게스트 사용량과 호스트 resident 를 가상 머신마다 같은 시각의 값으로 받는다.

 가상 머신이 여럿이면 명령 수가 늘어 같은 시각을 지키기 어려워진다. 그럴 때는 호스트 쪽을 먼저 한 번에 돌리고 게스트 쪽을 이어서 돌린 뒤 두 시각을 함께 적는다.

 ### 2. 가상 머신 하나로 표 모양을 먼저 정하고 나머지로 넓힌다

-한 대에 대해 다섯 명령을 돌려 세 값을 어디서 읽는지 확정한 다음 나머지에 같은 순서를 적용한다. 값을 잘못 읽어 표를 다시 만드는 일을 줄인다.
+한 대에서 다섯 명령을 돌려 세 값을 어디서 읽는지 확정한 다음 나머지에 같은 순서를 적용한다. 값을 잘못 읽어 표를 다시 만드는 일을 줄인다.

-두 번 붙어야 하고, 첫 실행과 두 번째 실행 사이에 게스트 사용량이 달라진다. overcommit 판정에 필요한 설정 값은 그 사이에 바뀌지 않으므로 판정 자체는 갈리지 않는다.
+두 번 붙어야 하고, 첫 실행과 두 번째 실행 사이에 게스트 사용량이 달라진다. 이 물음에 남은 것이 사용량과 resident 두 값뿐이라 그 차이가 답에 그대로 들어간다.

 ### 3. QEMU 프로세스 값까지 이번에 함께 읽는다 — 제외

@@ -110,7 +116,7 @@ QEMU 쪽은 별도의 물음이 이미 받고 있고 그쪽은 anonymous 인지
 1. virsh list 로 실행 중인 가상 머신 이름을 적는다.
 2. 가상 머신마다 호스트에서 virsh dominfo <VM_NAME> 으로 configured/current memory 를, virsh dumpxml <VM_NAME> 으로 memory backing 설정을, virsh dommemstat <VM_NAME> 으로 balloon 계열 값을 남긴다 (§83 OQ-2).
 3. 같은 시각에 각 게스트에서 free -h 와 cat /proc/meminfo 를 찍는다.
-4. 호스트의 free -h 도 함께 남겨 물리 RAM 과 현재 여유를 적는다.
+4. 호스트의 free -h 도 같은 시각에 남겨 그 시점의 여유를 적는다.
 5. 남기는 조건은 메모리 실험 조건 기준을 따른다. QEMU 프로세스의 resident 값은 QEMU 쪽 물음이 받는다.

-닫는 조건 : 설정 값 · 게스트 사용량 · 호스트 resident 세 값을 가상 머신마다 한 표로 적으면 닫는다. 설정 총량이 호스트 RAM 을 넘으면 이 환경이 overcommit 상태라는 사실을 확정한 것이 되고, 그 상태에서 무엇이 일어나는지는 swap 을 묻는 물음과 호스트 메모리 압박을 묻는 물음이 받는다. 넘지 않으면 §57 의 시나리오가 이 환경에 적용되지 않는다.
+닫는 조건 : 설정 값 · 게스트 사용량 · 호스트 resident 세 값을 가상 머신마다 한 표로 적으면 닫는다. 설정 총량이 호스트 RAM 을 넘는지는 §178 과 §187 이 이미 답했고 넘지 않아서 §57 의 시나리오는 이 환경에 적용되지 않는다. 호스트 메모리가 압박을 받을 때 무엇이 일어나는지는 swap 을 묻는 물음과 호스트 메모리 압박을 묻는 물음이 받는다.
@@ -18,7 +18,7 @@ source:

 # 가상 머신 RAM 이 HugeTLB 로 명시적으로 backing 되어 있는가

-HugeTLB 는 관리자가 미리 잡아 둔 Huge Page pool 을 가상 머신이나 애플리케이션이 명시적으로 지정해 쓰는 방식이다. 이 호스트의 두 가상 머신이 그 방식으로 RAM 을 받고 있는지는 libvirt 설정 한 곳만 봐서는 끝나지 않는다. §83 OQ-5 가 설정을 읽은 뒤 호스트 /proc/meminfo, QEMU smaps 계열과 교차 검증하라고 적었기 때문이다. 세 자료가 서로 맞는지까지 확인해야 이 환경이 어느 쪽으로 backing 되어 있는지가 정해진다.
+HugeTLB 는 관리자가 미리 잡아 둔 Huge Page pool 을 가상 머신이나 애플리케이션이 명시적으로 지정해 쓰는 방식이다. 이 호스트의 게스트 세 대가 그 방식으로 RAM 을 받고 있는지는 아직 읽지 않았다. §83 OQ-5 가 libvirt 설정을 읽은 뒤 호스트 /proc/meminfo, QEMU smaps 계열과 교차 검증하라고 적어서 설정 한 곳만 봐서는 끝나지 않는다.

 ## 관계

@@ -45,13 +45,15 @@ HugeTLB 는 관리자가 미리 잡아 둔 Huge Page pool 을 가상 머신이
 - §83 OQ-5 는 확인 명령으로 virsh dumpxml <VM_NAME> 을 들고, libvirt memory backing 관련 설정을 확인한 뒤 호스트 /proc/meminfo, QEMU smaps 계열과 교차 검증하라고 적었다.
 - §83 OQ-3 이 QEMU 프로세스 쪽 명령으로 cat /proc/<QEMU_PID>/smaps_rollup 을 들었다.
  smaps 계열에서 huge page 사용량을 어느 항목 이름으로 읽는지는 개념 문서가 적지 않았다.
- 세 자료 가운데 호스트 쪽은 항목 이름이 적혀 있다. §56 이 호스트 확인 명령을 적으면서 AnonHugePages 와 HugePages_Total 은 같은 의미가 아니라고 못 박았고, §83 OQ-4 도 THP policy · AnonHugePages · HugePages_Total · HugePages_Free · Hugepagesize 를 확인 항목으로 들었다. 이름이 없는 것은 QEMU smaps 쪽 하나다.
- 이 호스트의 libvirt 설정을 읽은 기록이 개념 문서에 없다.
+- 세 자료 가운데 호스트 쪽은 항목 이름이 적혀 있다. §56 은 호스트 확인 명령을 적으면서 AnonHugePages 와 HugePages_Total 이 같은 의미가 아니라고 못 박았다. §83 OQ-4 도 THP policy · AnonHugePages · HugePages_Total · HugePages_Free · Hugepagesize 를 확인 항목으로 들었다. 이름이 없는 것은 QEMU smaps 쪽 하나다.
+- §187 이 적은 게스트는 kc-lab-edge · kc-lab-1 · kc-lab-2 세 대이고 배정한 메모리는 차례로 1024MB · 5120MB · 4096MB 다.
+- §197 이 이 실험대의 libvirt 12.7.0 과 QEMU 11.1.1, 커널 7.2.2-arch1-1 을 적었다.
+- 이 호스트의 libvirt 설정을 읽은 기록이 개념 문서에 없다. 호스트 /proc/meminfo 의 huge page 값을 찍은 기록도 없다. huge page 와 THP, HugeTLB 는 SSOT 제2부에서만 서술되고, 실험대를 세우고 값을 잰 제5~9부에는 그 이름이 한 번도 나오지 않는다. 그래서 이 물음이 다시 읽을 기존 출력이 없고 세 자료를 새로 찍어야 한다.

 ## 가정

- 두 가상 머신 모두 libvirt 로 정의되어 있어 virsh dumpxml 로 설정을 통째로 읽을 수 있다고 본다.
- 설정에 memory backing 관련 요소가 없으면 명시적 HugeTLB backing 을 쓰지 않는 것으로 읽는다. 그 해석이 이 libvirt 버전에서 맞는지는 확인하지 않았다.
+- 게스트 세 대 모두 libvirt 로 정의되어 있어 virsh dumpxml 로 설정을 통째로 읽을 수 있다고 본다.
+- 설정에 memory backing 관련 요소가 없으면 명시적 HugeTLB backing 을 쓰지 않는 것으로 읽는다. 그 해석이 §197 이 적은 libvirt 12.7.0 에서 맞는지는 확인하지 않았다.
 - 세 자료를 같은 시각에 찍으면 같은 순간의 상태를 가리킨다고 전제한다.
 - QEMU 프로세스 번호를 가상 머신마다 가려낼 수 있다고 본다.

@@ -74,7 +76,7 @@ HugeTLB 는 관리자가 미리 잡아 둔 Huge Page pool 을 가상 머신이

 ### 1. libvirt 설정부터 읽고 backing 항목이 없으면 거기서 끝낸다

-virsh dumpxml 을 두 번 찍는 것으로 시작한다. 두 설정 모두 memory backing 관련 요소가 없으면 명시적 HugeTLB backing 이 아니라는 답이 거의 정해지고, 호스트 HugePages_Total 이 0 인지만 확인하면 닫힌다.
+게스트마다 virsh dumpxml 을 한 번씩 찍는 것으로 시작한다. 세 설정 모두 memory backing 관련 요소가 없으면 명시적 HugeTLB backing 이 아니라는 답이 거의 정해지고, 호스트 HugePages_Total 이 0 인지만 확인하면 닫힌다.

 설정에 항목이 있으면 결국 세 자료를 다 받아야 하므로 호스트와 QEMU 쪽을 다시 찍으러 간다.

@@ -82,7 +84,7 @@ virsh dumpxml 을 두 번 찍는 것으로 시작한다. 두 설정 모두 memor

 설정과 호스트 /proc/meminfo, QEMU smaps_rollup 을 같은 시각에 받아 나란히 둔다. OQ-5 가 요구한 교차 검증이 한 번의 실행으로 끝나고, 설정과 실제 값이 어긋나는 경우에도 그 어긋남이 같은 시각의 자료로 남는다.

-QEMU 프로세스 번호를 먼저 가려내야 하고, 두 가상 머신이 같은 시각에 켜져 있어야 한다.
+QEMU 프로세스 번호를 먼저 가려내야 하고, 게스트 세 대가 같은 시각에 켜져 있어야 한다.

 ### 3. 호스트 HugePages_Total 하나로 가른다 — 제외

@@ -20,9 +20,7 @@ source:

 # 메모리 증상 하나로 계층을 단정하지 않는다

-§86 은 메모리 지연이나 OOM(Out Of Memory, 커널이 필요한 메모리를 확보하지 못해 프로세스를 종료할 수 있는 상태)이 보일 때 한 번에 「메모리 부족」이라고 결론내리지 말라고 적었다. 대신 증상을 먼저 다섯 갈래로 가르는 분류를 두었다. Guest Virtual Memory · Virtualization Translation · Host Memory · Dynamic Memory · NUMA 다섯이다. 마지막의 NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 어느 CPU 가 어느 RAM 에 접근하느냐에 따라 비용이 달라질 수 있는 구조다.
-
-같은 요구가 개념 문서 안에서 세 번 더 나온다. Swap Used 값 하나로 판단하지 않고(§63), NUMA 최적화를 토폴로지를 재기 전에 정하지 않으며(§78), 게스트 하나의 free -h 만 보고 메모리 상태를 판단하지 않는다(§88). 이 기준은 그 넷을 한 판독 절차로 묶는다. 뒤의 셋을 따로 규칙으로 세우지 않은 것은 보는 대상만 다를 뿐 §86 과 같은 말을 하기 때문이다. 규칙이 세 벌이면 판독하는 사람이 어느 것을 따르는지가 갈린다.
+메모리 지연이나 OOM 이 보이면 「메모리 부족」으로 닫지 말고 §86 의 다섯 갈래로 먼저 가른다. Guest Virtual Memory · Virtualization Translation · Host Memory · Dynamic Memory · NUMA 다섯이다. §63 · §78 · §88 이 따로 요구한 판독도 이 한 절차로 묶었다.

 ## 관계

@@ -43,10 +41,12 @@ source:

 ## 목적

-이 기준은 증상 하나를 원인으로 바로 옮기는 판독을 막는다. §86 이 든 예가 메모리 지연과 OOM 인데, 둘 다 다섯 계층 어디서든 나올 수 있다.
+이 기준은 증상 하나를 원인으로 바로 옮기는 판독을 막는다. §86 이 든 예가 메모리 지연과 OOM(Out Of Memory, 커널이 필요한 메모리를 확보하지 못해 프로세스를 종료할 수 있는 상태)인데, 둘 다 다섯 계층 어디서든 나올 수 있다.

 다섯 갈래를 개념 한 편 안에 넣지 않고 따로 세운 것은 갈래마다 받는 개념이 다르기 때문이다. 어느 한 개념 안에 두면 그 글이 나머지 넷을 가리키지 못한다.

+§63 과 §78, §88 을 따로 기준으로 세우지 않은 것은 보는 대상만 다를 뿐 §86 과 같은 말을 하기 때문이다. 규칙이 세 벌이면 판독하는 사람이 어느 것을 따르는지가 갈린다. Swap Used 값 하나로 판단하지 않는 것(§63), 토폴로지를 재기 전에 NUMA 최적화를 정하지 않는 것(§78), 게스트 하나의 free -h 로 닫지 않는 것(§88)은 각각 2 번과 5 번, 6 번 규칙이다.
+
 좁히는 것과 확정하는 것을 갈라 둔 이유도 여기 있다. 이 기준은 어느 갈래인지까지만 좁히고, 원인 확정은 §85 의 조건을 함께 남긴 측정이 한다.

 ## 규칙
@@ -61,6 +61,8 @@ Host Memory : Host reclaim · Host swap · Host major fault · Host OOM
 Dynamic Memory : Balloon target · Guest pressure · Hotplug/virtio-mem 여부
 NUMA : vCPU placement · memory placement · remote access

+마지막 갈래의 NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 어느 CPU 가 어느 RAM 에 접근하느냐에 따라 비용이 달라질 수 있는 구조다.
+
 ### 2. Swap Used 값 하나로 메모리 압박을 단정하지 않는다

 §63 은 Swap Used = 2 GiB 라는 값만으로 지금 메모리 압박이 심하다고 단정할 수 없다고 적었다. 과거에 swap-out 된 cold page 가 남아 있을 수도 있기 때문이다.
@@ -96,6 +98,8 @@ cgroup memory limit 이 걸린 환경은 예외로 둔다. 호스트 전체 RAM

 §88 은 실제 테스트 서버에서 게스트 하나의 free -h 만 보고 메모리 상태를 판단하지 않는다고 적었다. Guest → QEMU → Host → NUMA → Storage 영향을 같은 시간축에서 관측해야 한다고 했다.

+이 실험대에는 아직 그 시간축의 한쪽만 있다. Prometheus 가 긁는 node-exporter 는 게스트 안에서 돌아 게스트 커널이 내놓는 값을 읽고, 호스트 쪽 지표는 긁지 않는다(§192 · §193). 거기서 나오는 메모리와 스왑 값은 전부 게스트가 본 것이라, 여기서 이 규칙을 지키려면 호스트에서 재는 값을 따로 들고 와야 한다.
+
 ## 적용 조건

 메모리 증상을 원인으로 옮기려는 판독 전부에 걸린다. 지연 증가, 스왑 관측, OOM, fault 증가가 여기 들어간다.
@@ -106,6 +110,8 @@ cgroup memory limit 이 걸린 환경은 예외로 둔다. 호스트 전체 RAM

 cgroup memory limit 이 걸린 환경에서는 호스트 전체 RAM 에 여유가 있어도 그 경계에서 OOM 이 나기 때문에, Host Memory 갈래를 곧바로 지우면 안 된다(§72).

+이 실험대의 Keycloak 은 K3s 파드로 돈다. 파드가 죽었을 때 describe 의 Exit Code 가 137 이면 OOM 이나 강제 종료이고 그때 보는 것은 파드의 메모리 한도라고 §191 이 적었는데, 그 한도가 얼마로 걸려 있는지는 매니페스트가 source/ 에 없어 대조할 방법이 지금은 없다(§194).
+
 NUMA node 가 하나인 호스트에서는 NUMA 갈래의 우선순위를 낮춰도 된다고 §78 이 적었다. 그것도 토폴로지를 잰 뒤의 이야기다.

 이 기준은 갈래를 좁힐 뿐 원인을 확정하지 않는다. 확정은 §85 의 조건을 남긴 측정이 한다.
@@ -19,8 +19,6 @@ source:

 메모리 측정은 값만 남기면 다음 사람이 그 값을 어디에 쓸 수 있는지 알 수 없다. §85 는 실험마다 함께 적을 조건을 Host 여덟 · VM 일곱 · Workload 다섯으로 못박았다. 이유도 한 줄로 적었는데, 조건을 남기지 않으면 「Memory pressure에서 느려졌다」는 결과를 다른 환경에 재사용하기 어렵다는 것이다.

-이 기준은 그 세 묶음을 메모리 측정 기록의 필수 항목으로 둔다. 어느 단계에서 그 값을 얻는지는 §84 의 권장 실험 순서에서 가져왔다. 이 주제의 열린 물음 열둘이 전부 같은 규칙에 걸려서, 조건 목록을 물음마다 되풀이하는 대신 여기 한 편에 두고 각 물음이 가리킨다.
-
 ## 관계

 - **메모리 증상 하나로 계층을 단정하지 않는다**
@@ -58,6 +56,8 @@ vCPU, Configured RAM, Current RAM, Memory backing 설정, Balloon device, Guest

 §42 는 configured memory 와 게스트가 지금 실제로 쓰는 메모리, 호스트에서 지금 resident 인 물리 메모리 셋이 같지 않을 수 있다고 적었다. RAM 을 한 값으로 줄여 적으면 나중에 그 숫자가 셋 가운데 무엇이었는지 알 수 없다.

+Configured RAM 도 한 번 정하고 끝나는 값이 아니다. 이 실험대의 게스트 메모리는 처음 만들 때 3584MB 였고 실험을 늘리며 5120/4096 으로 재배분했는데(§187), 언제 재배분했는지는 그 절이 적지 않았다.
+
 ### 3. Workload 조건 다섯 항목을 적는다

 Application, Heap/Memory 설정, Request concurrency, DB workload, 측정 시간 다섯이다.
@@ -80,7 +80,7 @@ Application, Heap/Memory 설정, Request concurrency, DB workload, 측정 시간

 ## 적용 조건

-메모리 관련 측정을 남기는 실험 전부에 걸린다. §83 의 OQ-1 부터 OQ-14 까지가 여기 들어가고, 이 주제의 열린 물음 열둘도 같은 규칙을 따른다.
+메모리 관련 측정을 남기는 실험 전부에 걸린다. §83 의 OQ-1 부터 OQ-14 까지가 여기 들어가고, 이 주제의 열린 물음 열둘도 같은 규칙을 따른다. 세 묶음은 그 물음마다 되풀이하지 않고 여기 한 편에 두었고, 각 물음이 이 기준을 가리킨다.

 남길 조건은 세 묶음이다.

@@ -94,7 +94,7 @@ Workload : Application · Heap/Memory 설정 · Request concurrency · DB worklo

 baseline 과 부하 구간을 비교하는 실험에서는 세 묶음을 두 시점에 각각 남긴다. 한 번만 남기면 비교한 두 시점 가운데 한쪽의 조건이 빈다.

-이 프로젝트는 조건 목록을 실제 장비 값으로 채운 적이 없다. §85 가 준 것은 항목 이름이고 값은 아직 없다.
+이 프로젝트는 조건 목록을 측정 하나에 붙여 채운 적이 없다. 값이 아예 없지는 않다 — §178 이 호스트를 i5-1135G7(논리 코어 8) · RAM 11,648MiB · QEMU 11.1.1 · libvirt 12.7.0 으로 적었고 §187 이 게스트 세 대의 vCPU 와 메모리를 적었다. 채우려고 잰 것이 아니라 실험대를 세우며 적힌 값이고, NUMA topology 와 Swap 설정, Kernel version, THP policy, Physical storage 는 아직 없다.

 ## 예시