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>
7.3 KiB
7.3 KiB
id, kind, slug, title, topic, topicName, project, status, questionStatus, studio, sourceRevision, source
| id | kind | slug | title | topic | topicName | project | status | questionStatus | studio | sourceRevision | source | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| d103bb81-45df-402f-86e5-e41d66ed7f8d | QUESTION | exit-distribution-for-keycloak-workload | Keycloak 작업의 VM Exit 분포는 idle · CPU-bound · I/O-bound 와 어떻게 다른가 | cpu-virtualization | CPU 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/d103bb81-45df-402f-86e5-e41d66ed7f8d/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
Keycloak 작업의 VM Exit 분포는 idle · CPU-bound · I/O-bound 와 어떻게 다른가
이 호스트에서 Exit 을 받아 본 기록이 없고 관측 도구가 열리는지부터 확인하지 않았다. VM Exit 은 게스트를 실행하던 CPU 가 제어권을 KVM 쪽으로 넘기는 정상 동작이라, 있다는 것만으로 문제가 되지 않는다. Keycloak 구간에서 Exit 이 얼마나 잦은지는 나머지 네 구간의 분포와 견줘야 갈린다.
관계
- KVM 에서 vCPU 가 물리 CPU 에서 실행되기까지 무엇이 VM Exit 을 부르고 그 처리가 커널에서 끝나는지 QEMU 사용자 공간까지 가는지를 이 개념이 설명한다.
- 실제 작업에서 주로 발생하는 VM Exit 은 무엇인가 그쪽은 작업 다섯의 분포를 서로 견주는 물음이고, 이 질문은 Keycloak 구간의 분포가 같은 구간의 지연과 같이 움직이는지를 묻는다. 다섯 구간을 한 번 받으면 두 질문의 자료가 함께 나오지만 닫는 기준이 달라 기록은 따로 둔다. 도구가 이 환경에서 열리는지 보는 첫 단계도 둘이 같이 쓴다.
사실
- VM Exit 은 정상적인 가상화 동작이어서 Exit 이 존재한다는 것만으로 문제가 되지 않는다.
- 하이퍼바이저가 개입해야 하는 Exit 이 특정 작업에서 지나치게 빈번하고 처리 비용이 커지면 성능에 영향을 줄 수 있다.
- 확인할 때 함께 보는 것은 넷이다. Exit 이유 작업 종류 Exit 처리 위치가 KVM 인지 QEMU 사용자 공간인지 애플리케이션 지연과 Exit 증가가 함께 나타나는지
- Exit 이 많다는 관측 하나로 장애라고 판단하지 않는다.
- 환경이 지원하면 perf kvm 으로 KVM 관련 실행 통계를 확인할 수 있고, 예로 든 명령은 sudo perf kvm stat live 다.
- 지원되는 명령과 표시되는 Exit 이유는 커널과 perf 버전, CPU 아키텍처와 설정에 따라 다를 수 있어 perf kvm --help 를 함께 확인한다. 필요하면 KVM tracepoint 를 이용한 별도 추적도 검토한다.
- §197 은 2026-09-10 에 이 호스트에서 커널 7.2.2-arch1-1 과 QEMU emulator version 11.1.1 을 받아 적었다. CPU 는 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz 이고 lscpu 의 Virtualization 은 VT-x 다. perf 버전은 적혀 있지 않다.
- 비교 후보로 적어 둔 구간은 idle, CPU-bound 작업, I/O 가 많은 작업, Keycloak 정상 요청, Keycloak 부하 테스트 다섯이다. 이 목록은 개념 문서가 앞선 물음 자리에 적어 둔 것이고, 이 질문의 제목이 든 것은 그 가운데 앞쪽 셋이다. 받아야 하는 구간은 제목이 든 것보다 둘 많다.
가정
- 이 호스트에서 perf kvm 이나 KVM tracepoint 가운데 하나는 열린다고 보고 측정 순서를 짠다. 둘 다 열리지 않는 결과도 이 질문의 정상적인 답이다.
- 다섯 구간을 같은 도구로 같은 길이만큼 잴 수 있다고 전제한다.
- Keycloak 부하 구간의 지연은 실험이 이미 재고 있는 값에서 가져올 수 있다고 본다.
- I/O 가 많은 구간을 이 환경에서 따로 만들 수 있다고 보고 짰다. 만드는 방법은 개념 문서에 적혀 있지 않다.
미지수
- 이 호스트에서 perf kvm 의 어떤 하위 명령이 열리는지, 열리지 않으면 tracepoint 쪽이 열리는지.
- Keycloak 구간의 Exit 이유 분포가 나머지 네 구간과 얼마나 다른지.
- 그 차이가 같은 구간의 Keycloak 지연과 같이 움직이는지.
- Exit 처리 위치가 KVM 인지 QEMU 사용자 공간인지를 이 환경의 출력으로 가를 수 있는지.
- 관측이 열린다면 얼마나 오래 받아야 구간 사이의 차이가 잡히는지.
제약
- 표시되는 Exit 이유는 커널과 perf 버전, CPU 아키텍처와 설정에 따라 달라지므로 다른 환경에서 나온 분포와 이 호스트의 분포를 바로 견주지 않는다.
- Exit 횟수만 세지 않는다. Exit 이유와 작업 종류, 처리 위치, 같은 구간의 지연을 함께 받아 적는다.
- 도구가 열려야 측정이 시작된다. 열리지 않으면 이 질문은 값 없이 닫힌다.
- sudo 가 필요한 명령인데, §204 는 이 호스트의 sudo 가 비밀번호를 요구해 비대화식으로는 읽지 못했다고 적었다. 그래서 콘솔에 붙어 직접 치는 실행으로 잡는다.
- 이 호스트에서 Exit 을 실제로 받아 본 기록이 없다.
선택지
1. perf kvm stat live 로 다섯 구간을 차례로 받는다
perf kvm --help 로 열리는 하위 명령을 먼저 확인하고, 열리면 다섯 구간을 각각 돌리며 Exit 이유 분포를 받는다. 같은 도구로 다섯을 받으므로 구간 사이의 차이를 그대로 견줄 수 있다.
구간마다 부하를 따로 만들어야 하고, 분포가 관측 길이에 따라 흔들리면 같은 구간을 여러 번 받아야 한다.
2. KVM tracepoint 를 직접 켜서 받는다
perf kvm 이 이 커널과 perf 버전에서 열리지 않을 때 검토하는 방법이다. tracepoint 를 직접 켜면 Exit 이유를 더 세밀하게 받을 수 있다.
받은 결과를 다섯 구간에 걸쳐 같은 형태로 정리하는 일이 첫 번째 방법보다 손이 많이 가서, perf kvm 이 열리지 않는 것을 확인한 뒤에 간다.
3. Keycloak 구간만 받아 절대값으로 판단한다 — 제외
Keycloak 구간의 Exit 수가 크면 Exit 처리 비용이 있다고 읽는 방법이다. Exit 이 많다는 관측 하나로 장애라고 판단하지 않기로 했고, 무엇과 견줘야 「많다」인지도 이 호스트에는 아직 기준이 없다. 그래서 다른 구간 없이 Keycloak 구간만 받지 않는다.
다음 검증
- perf kvm --help 로 이 환경이 지원하는 하위 명령을 확인한다.
- 열리면 sudo perf kvm stat live 로 idle, CPU-bound, I/O 가 많은 구간, Keycloak 정상 요청, Keycloak 부하 다섯의 Exit 이유 분포를 받는다.
- 같은 다섯 구간의 Keycloak 지연을 실험이 이미 재는 값에서 가져와 분포 옆에 적는다.
- perf kvm 이 열리지 않으면 KVM tracepoint 를 쓰는 쪽을 검토하고, 검토 결과와 그 판단 근거도 함께 기록한다.
닫는 조건 : Keycloak 구간의 Exit 분포가 다른 구간과 다르고 그 차이가 지연과 같이 움직이면 그 측정이 Case 가 되고 닫는다. 분포가 다르지 않거나 지연과 따로 움직이면, 이 작업에서 Exit 처리 비용은 조사 대상이 아니라고 적고 진단표의 「과도한 VM Exit」 행을 뒤로 미루는 근거로 남긴 뒤 닫는다.