100 lines
8.2 KiB
Markdown
100 lines
8.2 KiB
Markdown
---
|
|
id: d3e8501f-e1b5-4f8f-aa9a-89f9c89a308e
|
|
kind: QUESTION
|
|
slug: swap-activity-in-guest-and-host
|
|
title: 지금 게스트와 호스트에서 swap 이 실제로 오가고 있는가
|
|
topic: memory-virtualization
|
|
topicName: 메모리 가상화
|
|
project: virtualization
|
|
status: 초안
|
|
questionStatus: OPEN
|
|
studio: "https://hyeonworks.com/studio/documents/d3e8501f-e1b5-4f8f-aa9a-89f9c89a308e/edit"
|
|
sourceRevision: no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다
|
|
source:
|
|
- final/document.md#83-실제-환경에서-확인할-open-question-oq-6
|
|
- final/document.md#63-swap-used만-보고-장애를-판단하면-안-된다
|
|
- final/document.md#61-guest-swap과-host-swap
|
|
---
|
|
|
|
# 지금 게스트와 호스트에서 swap 이 실제로 오가고 있는가
|
|
|
|
Swap Used 가 2 GiB 로 나와도 그것이 지금 메모리 압박이 심하다는 뜻은 아니다. 그 값이 과거에 swap-out 된 cold page 때문에 커져 있을 수도 있어서, §63 은 값이 얼마인가 대신 지금 swap-in/out 이 지속되는가를 물으라고 적었다. 이 물음은 그 질문을 이 호스트와 두 게스트에서 같은 시각에 던진다. 게스트 swap 과 호스트 swap 은 서로 다른 경로이므로 한쪽만 보고 다른 쪽을 짐작하지 않는다.
|
|
|
|
## 관계
|
|
|
|
- **Host 메모리 압박이 Guest 와 스토리지까지 내려가는 경로**
|
|
게스트 swap 과 호스트 swap 이 왜 다른 경로인지를 그 개념이 설명한다.
|
|
- **VM 에서 page fault 는 세 계층에서 따로 일어난다**
|
|
호스트 쪽 swap-in 은 호스트 page fault 로 시작하고, 그 계층이 게스트 page fault 와 다르다.
|
|
- **호스트 메모리 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는가**
|
|
압박을 유도하는 실험은 여기서 잰 평상시 상태를 기준값으로 쓴다.
|
|
- **호스트 major fault 와 스토리지 지연은 같은 시간축에서 함께 움직이는가**
|
|
§63 이 함께 보라고 든 넷 가운데 major fault 와 storage latency 를 그 물음이 받는다.
|
|
- **메모리 증상 하나로 계층을 단정하지 않는다**
|
|
Swap Used 값 하나로 판정하지 않는다는 것이 그 기준의 사례다.
|
|
|
|
## 사실
|
|
|
|
- §63 은 Swap Used = 2 GiB 라는 값만으로 지금 메모리 압박이 심하다고 단정할 수 없다고 적었다. 과거에 swap-out 된 cold page 가 남아 있을 수도 있기 때문이다.
|
|
- §63 은 더 중요한 질문으로 넷을 들었다.
|
|
현재 swap-in/out 이 지속되는가
|
|
reclaim pressure 가 증가하는가
|
|
major fault 가 증가하는가
|
|
storage latency 가 같이 증가하는가
|
|
- §63 은 게스트와 호스트를 동시에 확인해야 한다고 적고 확인 명령으로 free -h 와 vmstat 1 을 들었다.
|
|
- §83 OQ-6 도 게스트와 호스트 양쪽에 같은 두 명령을 적고, swap-used 값 하나보다 지금의 swap-in/out 활동과 메모리 압박을 함께 보라고 했다.
|
|
- §61 은 게스트 swap 을 게스트 애플리케이션에서 시작해 게스트 메모리 압박, 게스트 커널, 게스트 swap, /dev/vda, virtio-blk, QEMU 를 거쳐 호스트 스토리지로 내려가는 경로로 그렸다.
|
|
- §61 은 호스트 swap 을 게스트 RAM 이 QEMU 의 메모리 backing 을 거쳐 호스트 메모리 압박을 받고 호스트 커널이 호스트 swap 으로 내리는 경로로 그렸다. 같은 절이 두 경로를 같지 않다고 적고, 게스트가 메모리 여유가 있어 보이는데 호스트에서 swap 이나 reclaim 이 심할 수도 있다고 덧붙였다.
|
|
- 개념 문서는 vmstat 출력에서 어느 열을 swap-in 과 swap-out 으로 읽는지 적지 않았다.
|
|
- 이 호스트와 두 게스트에서 free -h 나 vmstat 를 찍은 기록이 개념 문서에 없다.
|
|
|
|
## 가정
|
|
|
|
- 호스트와 두 게스트에 동시에 접속해 같은 구간을 관측할 수 있다고 본다.
|
|
- 관측하는 동안 실험용 부하를 따로 걸지 않고 평상시 상태를 재는 것으로 둔다. 그 상태가 이 호스트의 대표적인 상태인지는 한 번의 관측으로 알 수 없다.
|
|
- 게스트와 호스트의 시계가 맞아 두 기록을 같은 시간축에 놓을 수 있다고 전제한다.
|
|
- 두 가상 머신 모두 swap 영역을 갖고 있다고 보고 게스트 쪽을 읽는다. 설정에 swap 이 없으면 게스트 쪽 관측은 그 사실로 끝난다.
|
|
|
|
## 미지수
|
|
|
|
- 관측 구간에서 swap-in 과 swap-out 이 실제로 오가는지, 오간다면 게스트 쪽인지 호스트 쪽인지 둘 다인지.
|
|
- Swap Used 가 0 이 아니라면 그 값이 과거에 내려간 cold page 때문인지 지금 진행 중인 swap 활동 때문인지.
|
|
- §63 이 든 나머지 셋 가운데 reclaim pressure 와 major fault 를 이 환경에서 어떤 값으로 읽는지. 그 둘을 읽는 명령은 개념 문서에 없다.
|
|
- 관측을 얼마나 오래 해야 지속 여부를 말할 수 있는지. 개념 문서는 vmstat 1 만 적고 관측 길이를 적지 않았다.
|
|
|
|
## 제약
|
|
|
|
- 게스트 값으로 호스트 상태를 말하거나 그 반대로 말하지 않는다. §61 이 두 경로를 갈라 놓았다.
|
|
같은 문서의 결론도 게스트 하나의 free -h 만 보고 메모리 상태를 판단하지 않고 Guest, QEMU, Host, NUMA, Storage 로 이어지는 영향을 같은 시간축에서 관측해야 한다고 적었다.
|
|
- Swap Used 값 하나를 결론으로 적지 않는다. §63 이 그 판단을 막았다.
|
|
- 부하를 걸어 압박을 만드는 일은 이 물음에 들어 있지 않다. 그 실험은 「호스트 메모리 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는가」가 받는다.
|
|
§84 의 권장 실험 순서가 이미 그렇게 갈라 놓았다. 게스트와 호스트 vmstat 동시 관측이 여섯째이고 memory pressure 실험은 열째, swap 과 storage latency 를 견주는 일은 열한째다. 이 물음은 여섯째까지다.
|
|
- 게스트는 가상 머신마다 따로 찍는다. 한 대의 값을 다른 한 대에 옮기지 않는다.
|
|
|
|
## 선택지
|
|
|
|
### 1. 게스트와 호스트에서 같은 구간을 동시에 관측한다
|
|
|
|
세 곳에서 free -h 를 한 번 찍어 기준을 남기고, vmstat 1 을 같은 시각에 시작해 같은 길이로 돌린다. §61 이 갈라 놓은 두 경로가 같은 시간축의 값으로 남아 한쪽만 움직이는 경우와 둘 다 움직이는 경우를 구분할 수 있다.
|
|
|
|
세 곳에 동시에 붙어야 하고 관측 길이를 먼저 정해야 한다.
|
|
|
|
### 2. 호스트만 먼저 관측한다
|
|
|
|
호스트에서 swap 이 전혀 오가지 않으면 §61 의 두 경로 중 호스트 쪽은 지금 문제가 아니라고 그 관측 하나로 정한다. 접속이 한 곳이라 반복해서 찍기 쉽다.
|
|
|
|
게스트 쪽 swap 은 호스트 값에 드러나지 않는다. 게스트 커널이 /dev/vda 로 내리는 경로라 호스트에서는 스토리지 I/O 로만 보인다. 그래서 게스트를 다시 찍어야 한다.
|
|
|
|
### 3. Swap Used 값만 세 곳에서 받아 적는다 — 제외
|
|
|
|
free -h 한 번씩으로 끝내는 방법이다. §63 이 그 값만으로 판단하지 말라고 적은 것이 이 물음의 출발점이므로 이 방법으로는 닫히지 않는다.
|
|
|
|
## 다음 검증
|
|
|
|
1. 호스트와 각 게스트에서 free -h 를 한 번씩 찍어 그 시점의 Swap Used 를 기준으로 남긴다.
|
|
2. 세 곳에서 vmstat 1 을 같은 시각에 시작해 미리 정한 길이만큼 돌리고, 출력에서 swap-in 과 swap-out 으로 읽은 열의 이름을 함께 적는다.
|
|
3. 같은 구간에서 §63 이 든 나머지 셋 가운데 읽을 수 있는 것 — reclaim pressure · major fault · storage latency — 을 어떤 명령으로 읽었는지와 함께 남긴다.
|
|
4. 세 기록을 같은 시간축에 놓고 어느 쪽에서 무엇이 움직였는지 적는다.
|
|
|
|
닫는 조건 : 관측 구간 내내 게스트와 호스트 모두 swap-in 과 swap-out 이 0 이면 지금은 swap 이 오가지 않는다고 적고 닫는다. Swap Used 가 0 이 아니어도 그렇게 적는다. 한쪽에서 swap 이 오가면 §61 의 두 경로 중 어느 쪽인지를 적고, 그 구간의 스토리지 지연과 게스트 지연을 함께 적어 「호스트 메모리 압박이 게스트 애플리케이션 지연을 실제로 밀어 올리는가」로 넘긴다.
|