6.7 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 스케줄링 변동이 달라지는가
vCPU 스레드가 실행될 호스트 논리 CPU 를 특정 집합으로 제한하는 설정을 CPU pinning 이라고 한다. 적절히 걸면 스케줄링 변동이 줄지만 잘못 걸면 특정 CPU 에만 작업이 몰린다. 이 호스트에서는 pinning 을 걸지 않은 상태의 Keycloak 지연도, 건 상태의 지연도 아직 재지 않았으므로 pinning 이 지금 작업에 이점을 주는지는 말할 수 없다.
관계
- 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 을 걸지 않았다면 스케줄링에 따라 달라질 수 있다.
- pinning 이 지금 작업에서 실제 이점을 주는지는 실험으로 확인하기로 했고, 아직 그 실험을 돌리지 않았다.
가정
- 지금 두 가상 머신에 pinning 도 별도의 친화도 설정도 걸려 있지 않다고 보고 「전」 실행을 잡는다. 걸려 있는지는 개념 문서에 적혀 있지 않아 실행할 때 함께 확인한다.
- pinning 없이 돌리면 같은 tid 의 PSR 이 시간에 따라 바뀐다고 본다. 이 호스트에서 그 이동을 아직 관측하지 않았다.
- 두 실행에 같은 Keycloak 부하를 같은 방식으로 걸 수 있다고 전제한다.
- 두 실행 사이에 vCPU 수와 가상 머신 배치를 바꾸지 않는다고 두고 짠다. 그래야 차이를 pinning 쪽으로 읽을 수 있다.
미지수
- pinning 뒤 Keycloak 지연이 달라지는지, 달라진다면 어느 방향인지.
- 같은 tid 의 PSR 변동이 실제로 줄어드는지.
- 변동이 줄어드는 대신 특정 논리 CPU 로 작업이 몰리는지.
- 어떤 논리 CPU 집합에 묶을지. 이 호스트의 논리 CPU 수와 각 가상 머신의 vCPU 수를 아직 적지 않았다.
- 호스트 쪽 Nginx 와 다른 호스트 프로세스가 그 집합을 함께 쓰는지.
제약
- pinning 여부만으로 판정하지 않는다. 지연과 PSR 변동, CPU 별 사용률 셋을 같은 실행에서 받아 적는다.
- 「전」과 「후」 두 실행의 부하가 같아야 지연 차이를 pinning 쪽으로 읽을 수 있다.
- 이 호스트에서 잰 값이 하나도 없어 견줄 값을 이번 실행이 함께 만든다.
- 이 실행 전에 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 이 이점을 주지 않는다고 적고 닫는다.