diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/design/013-memory-budget.md | 22 | ||||
| -rw-r--r-- | docs/research/104-where-memory-goes.md | 42 |
2 files changed, 57 insertions, 7 deletions
diff --git a/docs/design/013-memory-budget.md b/docs/design/013-memory-budget.md index fe8736a..97bd8a6 100644 --- a/docs/design/013-memory-budget.md +++ b/docs/design/013-memory-budget.md @@ -1,10 +1,10 @@ # 013 — 앱 전체 메모리 예산 -작성일: 2026-09-30. 상태: 1단계 구현. +작성일: 2026-09-30. 상태: 세 단계 모두 했다(3단계는 측정). [외부 리뷰 004](../outside-feedback/feedback-004.md)의 둘째 권고에서 시작한다. 측정은 [104](../research/104-where-memory-goes.md)에 있다. -지금의 `--budget`은 요청 payload의 접수만 묶는다. 앱의 목록, outbox, 붙들린 스냅숏, 전송의 사본은 아무것도 묶지 않는다. 작은 -기기에서 오래 도는 노드라면 무엇이 얼마나 쓰는지 정해져 있어야 하고, 넘칠 때 무엇을 하는지도 정해져 있어야 한다. +이 설계 전에는 `--budget`이 요청 payload의 접수만 묶었다. 앱의 목록, outbox, 붙들린 스냅숏, 전송의 사본은 아무것도 묶지 +않았다. 작은 기기에서 오래 도는 노드라면 무엇이 얼마나 쓰는지 정해져 있어야 하고, 넘칠 때 무엇을 하는지도 정해져 있어야 한다. ## 결정 @@ -56,15 +56,19 @@ | 무엇 | 상한 | 이유 | |---|---|---| | 붙들린 스냅숏 | 붙든 판마다 상태 한 벌. 붙드는 쪽(연결 스레드, 표면, 체크포인트)이 H이면 최악 (1 + H) × 예산 | 104에서 고쳤다. 전에는 한이 없었다 | -| 전송의 사본 | 링크 ring과 HTTP 큐가 outbox를 한 번 더 든다(한 건에 0.8배, 1.4배) | 2단계에서 창으로 묶는다 | +| 전송의 사본 | 보내는 곳(`--send`)마다 창 하나: 받는 쪽이 가진 것 너머로 `--window` 바이트(4 MiB)와 65,536건 | 2단계. 전에는 outbox를 한 번 더 들었다(한 건에 0.8배, 1.4배) | | 요청 payload | `--budget` | 지금의 접수 예산 | -| 체크포인트 | 이미지를 쓰는 동안 스냅숏 하나 | 붙들린 스냅숏의 한 경우 | +| 체크포인트 | 이미지를 쓰는 동안 스냅숏 하나. 그동안 고친 잎과 바꾼 텍스트만 더 든다 | 붙들린 스냅숏의 한 경우. SD 카드에서 22.4 MB 목록을 8초쯤 쓰는 동안 +3.0–4.4 MiB였다(104) | ## 단계 1. 상태 바이트를 세고, `--memory`로 예산을 두고, 넘칠 때 사건을 거절한다. 전달의 거절은 들은 번호로 세지 않는다. 2. 전송의 창: 링크와 HTTP 전달이 outbox 전체가 아니라 창만큼만 받는다. 전달되면 다음을 받는다. -3. 체크포인트가 쓰는 동안의 메모리를 잰다. + - 소유자가 보내는 곳마다 outbox에서의 자리를 기억해, 새로 넣을 것만 본다. outbox에서 나간 보내기의 수(`sends_gone`)만큼 + 자리를 뒤로 물리므로, 앞의 것이 지워져도 건너뛰는 것이 없다. 저장 뒤와 전달 뒤에 창을 채운다. + - 창이 차도 하나는 넣는다. 창보다 큰 보내기 하나도 간다. +3. 체크포인트가 쓰는 동안의 메모리를 잰다. 잰 값은 104에 있다. 쓰는 동안 고친 것만큼 는다. 예산이 세는 상태의 2배(상태 + 한 벌과 스냅숏 한 벌)를 넘지 않고, 잰 최고는 상태 바이트의 약 2배(상주)였다. ## 검사 @@ -84,7 +88,13 @@ 기다리던 주문이 모두 한 번씩 들어온다. 가득 찬 2초 동안 거절은 7번이다(기다림이 없으면 27,809번). - check.py `server_answers_memory`: 답이 보내기보다 큰 영수증을 남긴다. 영수증이 예산을 채우면 답이 기다리고 주문이 503 `memory`를 받는다. 비우면 기다리던 답이 모두 한 번씩 적용되고, API는 주문마다 한 번씩만 불렸다. +- check.py `server_windows`: 출력 둘(링크 하나, HTTP 하나)의 받는 쪽이 모두 꺼진 채 300건을 보낸다. 창(2,000 B)이 찬다. + 받는 쪽이 뜨면 둘 다 300건을 한 번씩 받는다. 전달 뒤에 창을 채우지 않으면 117건에서 멈춘다. - 021의 run.py `budget`: 상태 4 MB가 4초 남짓에 차고, 상주 메모리가 9.6–9.8 MiB에 멈춘다(예산 없이 30초에 45.9 MiB). +- 021의 run.py `link-down`, `wire-down`(창 4 MiB): 창이 찬 뒤로는 보낸 것 한 건에 상주 219 B, 218 B로 outbox만큼만 는다(30초 + 전체로 전에는 399 B, 534 B). +- 021의 run.py `unheld --items 200000 --stores`(SD 카드): 체크포인트 두 번이 각각 +3.0 MiB, +4.4 MiB를 남겼다. 최고 상주 + 42.6 MiB는 상태 22.4 MB의 약 2배다. ## 중단 기준 diff --git a/docs/research/104-where-memory-goes.md b/docs/research/104-where-memory-goes.md index 03749c7..0828e44 100644 --- a/docs/research/104-where-memory-goes.md +++ b/docs/research/104-where-memory-goes.md @@ -21,9 +21,13 @@ - 보내지 못한 한 건마다 outbox에 221 B가 든다(100 B 글의 주문). - 링크(`pure://`)로 보내면 링크가 따로 사본을 들어 399 B, HTTP로 보내면 534 B다. - 그래서 예산은 "상태의 상한"과 "넘칠 때 거절"로 정해야 한다. 전송의 사본은 줄일 수 있는 상수배다([013](../design/013-memory-budget.md)). + - **전송의 사본은 창만큼이다.** 013의 2단계 뒤, 링크와 HTTP 전달은 받는 쪽이 가진 것 너머로 4 MiB까지만 든다. 창이 찬 + 뒤로는 받는 쪽이 꺼져 있어도 보낸 한 건에 상주 약 220 B, outbox만큼만 는다. - **예산을 주면 멈춘다.** 013의 1단계(`--memory`) 뒤, 받는 쪽 없이 보내는 노드에 상태 4 MB를 주었다. 4초 남짓에 차고, 그 뒤로 보내는 요청은 503 `memory`를 받으며 상주 메모리가 9.6–9.8 MiB에 머문다. 예산이 없으면 30초 동안 45.9 MiB까지 는다. -- 아직 모르는 것: 체크포인트가 쓰는 동안의 메모리는 따로 재지 않았다. + - **체크포인트는 쓰는 동안 고친 만큼 든다.** SD 카드에서 22.4 MB 목록의 이미지를 쓰는 8초쯤 동안 +3.0–4.4 MiB였다. + 최고 상주는 상태 바이트의 약 2배다. +- 아직 모르는 것: 몇 시간, 며칠 도는 노드에서 할당기가 쥐고 돌려주지 않는 메모리(조각남)가 어디까지 가는지는 재지 않았다. ## 방법 @@ -96,3 +100,39 @@ - 세는 비용: 가장 작은 사건(수 하나를 더함, 저장소 없음)이 상태 1개인 앱에서 125 → 136 ns(+8 %), 32개인 앱에서 321 → 349 ns(+9 %)다. 처음에는 사건마다 모든 상태를 두 번 걸어 125 → 146 ns(+17 %), 328 → 454 ns(+38 %)였다. 목록과 텍스트만 비트로 골라 걷게 했다(`883d64c`). 예산이 없으면 비용이 없다. HTTP로 받는 쓰기는 한 건에 수십 µs라 처리량에 보이지 않는다. + +### 창을 둔 뒤 + +013의 2단계(보내는 곳마다 창)를 넣은 뒤, 받는 쪽이 꺼진 두 경우를 다시 쟀다 +(`research/experiments/021-memory/2026-09-30-window-linux-aarch64.jsonl`, 창 4 MiB). + +| 경우 | 보낸 수 | 상주 메모리 | 한 건마다(30초 전체) | 창이 찬 뒤(8–30초) | +|---|---:|---|---:|---:| +| link-down, 창 전 | 198,874 | 8.5 → 84.1 MiB | 399 B | | +| link-down | 202,933 | 8.5 → 57.6 MiB | 254 B | 219 B | +| wire-down, 창 전 | 198,269 | 3.0 → 104.0 MiB | 534 B | | +| wire-down | 202,831 | 3.0 → 54.5 MiB | 266 B | 218 B | + +- 창은 링크에서 6–8초 사이, HTTP에서 4–6초 사이에 찼다(보낸 수 4만–5만). 그 뒤로 는 것은 outbox 한 건(221 B, 위의 outbox + 경우)과 같다. +- 전송이 쥐는 것은 이제 보내는 곳마다 상수다. 예산과 함께면 노드의 상태 쪽 메모리는 예산의 약 1.7배와 창들의 합으로 묶인다. + +### 체크포인트가 쓰는 동안 + +- 체크포인트는 목록 하나의 스냅숏을 쥐고 이미지를 쓴다(소유자 밖의 스레드). 그동안 앱이 고친 잎과 바꾼 텍스트는 스냅숏이 + 쥐고 있어 풀리지 않는다. 그래서 더 드는 것은 "쓰는 동안 고친 것"이고, 많아야 목록 한 벌이다. +- unheld 경우(무작위 항목의 글을 고침)를 항목 수와 저장 장치를 바꿔 쟀다 + (`research/experiments/021-memory/2026-09-30-checkpoint-linux-aarch64.jsonl`). 최고 상주는 0.5초마다 읽은 VmRSS와 끝의 + VmHWM 가운데 큰 것이다(VmHWM은 42.5 MiB라 했지만 172초에 읽은 VmRSS가 42.6 MiB였다). + +| 저장소 | 항목 | 고친 수 | 체크포인트 | 상주(시작 → 끝) | 최고 | 상태 바이트 | +|---|---:|---:|---:|---|---|---:| +| tmpfs | 50,000 | 205,531(30초) | 4 | 11.0 → 11.5 MiB | 11.5 MiB | 5,600,000 | +| SD 카드 | 50,000 | 36,522(30초) | 1 | 11.3 → 11.6 MiB | 11.6 MiB | 5,600,000 | +| SD 카드 | 200,000 | 331,881(240초) | 2 | 35.1 → 42.5 MiB | 42.6 MiB | 22,400,000 | + +- tmpfs와 작은 목록(5.6 MB, 카드의 빠른 쓰기 구간 안)에서는 체크포인트가 보이지 않는다. 금방 끝나 고친 것이 적다. +- SD 카드의 22.4 MB 목록에서는 두 번 모두 보인다. 6–10초에 +3.0 MiB, 164–172초에 +4.4 MiB다. 초당 1,400건을 고치는 동안 + 8초쯤 이어졌다. 고친 잎(짧은 수와 포인터)과 바뀐 글(각 100 B)이 쥐어졌고, 목록 한 벌(상주 약 37 MB)에는 한참 못 미친다. +- 쓴 뒤에 그 메모리는 풀리지만 프로세스는 돌려주지 않고 다음에 쓴다(할당기가 쥔다). 그래서 상주가 새 높이에 머문다. +- 최고 42.6 MiB는 상태 22.4 MB의 약 2배(1.99)다. 013의 상한(상태 한 벌과 스냅숏 한 벌)과 중단 기준(3배) 안이다. |