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.1 KiB
7.1 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 | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 62319064-17ef-4b2f-bf8b-e363cd0e36a6 | QUESTION | pinning-before-and-after | CPU pinning 전후로 Keycloak 지연과 vCPU 스케줄링 변동이 달라지는가 | cpu-virtualization | CPU 가상화 | virtualization | 초안 | OPEN | https://hyeonworks.com/studio/documents/62319064-17ef-4b2f-bf8b-e363cd0e36a6/edit | no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다 |
|
CPU pinning 전후로 Keycloak 지연과 vCPU 스케줄링 변동이 달라지는가
이 호스트에서는 pinning 을 걸지 않은 상태의 Keycloak 지연도, 건 상태의 지연도 아직 재지 않았다. CPU pinning 은 vCPU 스레드가 실행될 호스트 논리 CPU 를 특정 집합으로 제한하는 설정이다. 논리 코어 8 과 게스트별 vCPU 2 는 §197 · §218 에 나왔지만, 묶은 뒤 지연과 CPU 별 사용률이 어떻게 달라지는지는 재 봐야 갈린다.
관계
- KVM 에서 vCPU 가 물리 CPU 에서 실행되기까지 pinning 도 CPU 격리도 하지 않았을 때 vCPU 스레드를 누가 어디에 배치하는지를 이 개념이 설명한다.
- pinning 없이 vCPU 스레드는 호스트 논리 CPU 사이를 옮겨 다니는가 그쪽이 이동 자체를 관측하고, 이 질문은 그 이동을 없앴을 때 Keycloak 지연이 달라지는지를 받는다.
사실
- CPU pinning 은 특정 vCPU 스레드를 특정 호스트 논리 CPU 에 제한하는 설정이다.
- 적절히 쓰면 스케줄링 변동을 줄일 수 있고, 잘못 설정하면 특정 CPU 에 작업이 집중될 수 있다.
- 그래서 pinning 을 걸었는지만 보지 않고 CPU 별 사용률과 친화도를 함께 확인한다.
- 개념 문서가 잘못 건 예로 그린 것은 vCPU 스레드 둘과 호스트 프로세스 하나가 같은 논리 CPU 에 묶이고 나머지 논리 CPU 는 상대적으로 유휴한 그림이다. 치우침을 만드는 쪽에 호스트 프로세스가 함께 들어 있다.
- 스레드가 최근 실행된 논리 CPU 는 ps -eLo pid,tid,psr,pcpu,comm | grep qemu 의 PSR 로 볼 수 있다.
- PSR 값 하나가 vCPU 가 물리 CPU 에 영구 고정되어 있다는 뜻은 되지 않는다. pinning 을 걸지 않았다면 스케줄링에 따라 달라질 수 있다.
- 이 호스트의 논리 코어는 8 이고(§197), kc-lab-1 과 kc-lab-2 에 준 vCPU 는 각각 2 다(§218). 실험대가 잡은 vCPU 는 2 + 2 + 1 = 5 다(§197).
- pinning 이 지금 작업에서 실제 이점을 주는지는 실험으로 확인하기로 했고, 아직 그 실험을 돌리지 않았다.
가정
- 지금 두 가상 머신에 pinning 도 별도의 친화도 설정도 걸려 있지 않다고 보고 「전」 실행을 잡는다. 걸려 있는지는 개념 문서에 적혀 있지 않아 실행할 때 함께 확인한다.
- pinning 없이 돌리면 같은 tid 의 PSR 이 시간에 따라 바뀐다고 본다. 이 호스트에서 그 이동을 아직 관측하지 않았다.
- 두 실행에 같은 Keycloak 부하를 같은 방식으로 걸 수 있다고 전제한다.
- 두 실행 사이에 vCPU 수와 가상 머신 배치를 바꾸지 않는다고 두고 짠다. 그래야 차이를 pinning 쪽으로 읽을 수 있다.
미지수
- pinning 뒤 Keycloak 지연이 달라지는지, 달라진다면 어느 방향인지.
- 같은 tid 의 PSR 변동이 실제로 줄어드는지.
- 변동이 줄어드는 대신 특정 논리 CPU 로 작업이 몰리는지.
- 어떤 논리 CPU 집합에 묶을지. 논리 코어 8 과 게스트별 vCPU 2 는 §197 · §218 에 나왔지만, 그 여덟 가운데 어느 코어에 묶을지는 CPU 별 사용률을 보고 정해야 한다.
- 호스트 쪽 Nginx 와 다른 호스트 프로세스가 그 집합을 함께 쓰는지. §179 는 그 Nginx 를 엣지 게스트로 옮겼다고 적었으므로, 묶을 집합을 고르기 전에 호스트에 무엇이 남아 있는지부터 이번 실행에서 적는다.
제약
- pinning 여부만으로 판정하지 않는다. 지연과 PSR 변동, CPU 별 사용률 셋을 같은 실행에서 받아 적는다.
- 「전」과 「후」 두 실행의 부하가 같아야 지연 차이를 pinning 쪽으로 읽을 수 있다.
- 이 호스트에서 지연도 PSR 변동도 CPU 별 사용률도 잰 값이 없어 견줄 값을 이번 실행이 함께 만든다.
- 이 실행 전에 pinning 을 쓸지 말지를 먼저 정하지 않는다. 잰 값이 없는 상태로 정하면 그 선택이 감수하는 비용을 적을 수 없다.
- 묶는 대상은 vCPU 스레드다. 게스트 안의 Keycloak 파드 배치는 이 질문이 다루지 않는다.
선택지
1. 같은 부하로 전후 두 실행을 재고 세 항목을 나란히 놓는다
pinning 없이 Keycloak 부하를 걸어 지연과 PSR 변동과 CPU 별 사용률을 남기고, vCPU 스레드를 논리 CPU 에 묶은 뒤 같은 부하로 같은 세 항목을 다시 남긴다. 지연이 좋아졌는지와 그 대가로 특정 CPU 에 몰렸는지를 한 실행 쌍에서 같이 볼 수 있다.
가상 머신 설정을 바꿔 다시 부하를 거는 만큼 시간이 든다. 두 실행 사이에 다른 조건이 바뀌면 그 실행 쌍은 버린다.
2. 부하 없이 PSR 변동만 견준다
유휴 구간에서 PSR 을 여러 번 찍어 pinning 전후를 견주는 방법이다. 부하를 만들지 않아도 되고 실행이 짧다.
이 방법으로는 질문의 절반만 답한다. pinning 이 스케줄링 변동을 줄이는지는 보이지만 Keycloak 지연이 달라지는지는 보이지 않고, 부하가 없으면 특정 CPU 에 작업이 몰리는지도 드러나지 않는다.
3. 지연만 견주고 CPU 별 사용률은 뒤로 미룬다 — 제외
전후 지연만 재면 실행 하나가 짧아진다. 다만 잘못 건 pinning 도 짧은 구간에서는 지연이 좋아진 것으로 보일 수 있다. 그 경우를 가려내려고 CPU 별 사용률과 친화도를 함께 보기로 했으므로 이 방법은 쓰지 않는다.
다음 검증
- pinning 을 걸지 않은 상태에서 Keycloak 부하를 걸고, 지연과 ps -eLo pid,tid,psr,pcpu,comm | grep qemu 의 PSR 변동, CPU 별 사용률을 남긴다.
- 같은 실행에서 그 가상 머신에 친화도 설정이 이미 걸려 있는지도 함께 적는다.
- vCPU 스레드를 논리 CPU 에 묶고 같은 부하를 다시 걸어 같은 세 항목을 남긴다.
- 두 실행을 나란히 놓고 지연 차이와 CPU 별 사용률의 치우침을 함께 읽는다.
닫는 조건 : pinning 뒤 지연이 좋아지고 CPU 별 사용률이 특정 CPU 로 몰리지 않으면, pinning 을 쓸지 말지를 Decision 으로 넘긴다. 그 Decision 이 감수할 비용은 잘못 건 pinning 이 특정 CPU 에 작업을 집중시킨다는 것이다. 두 실행에서 지연 차이가 없으면 이 작업에서는 pinning 이 이점을 주지 않는다고 적고 닫는다.