diff options
| -rw-r--r-- | docs/research/076-one-sync-commit.md | 19 |
1 files changed, 16 insertions, 3 deletions
diff --git a/docs/research/076-one-sync-commit.md b/docs/research/076-one-sync-commit.md index 8176a82..9f010e7 100644 --- a/docs/research/076-one-sync-commit.md +++ b/docs/research/076-one-sync-commit.md @@ -139,6 +139,19 @@ SQLite WAL은 프레임마다 누적 체크섬을 두어 커밋당 동기화 한 ## 다음 결정 -1. 꼬리를 늘리는 비용을 커밋 경로에서 빼기(백그라운드 준비나 세그먼트 재사용). 지금은 한 커밋이 치른다. -2. 여러 프로세스가 같은 저장소를 쓸 때의 확인 동기화를 줄이는 방법(동기화 완료를 공유 메모리로 알리기). -3. 동기화를 다음 묶음의 실행과 겹치기. 커밋 결과를 기다리는 동안 다음 묶음의 이벤트를 준비한다. +뒤따른 측정(2026-09-26, 묶음 한도를 256키로 올린 뒤 연결 64개 쓰기)으로 세 후보를 다시 봤다. + +1. **꼬리 0 채우기.** 이 부하에서는 커밋 하나가 약 46 KB를 쓰고(문서 26개의 leaf와 카탈로그), 0 채우기도 같은 양을 + 썼다(3초에 데이터 8.3 MB, 0 8.6 MB). 서버 시간의 88%가 `fdatasync`였다(p50 5.5 ms, p90 24.5 ms). 꼬리를 끈 + 판과 번갈아 쟀지만 처리량 차이는 SD 카드의 흔들림(같은 설정이 1,832–3,107/s) 안에 있었다. 연결 8개의 p50은 꼬리가 + 있을 때 짧았다(6.4–7.4 ms 대 11.8–12.8 ms). 그래서 꼬리는 유지한다. 백그라운드 준비나 공간 재사용은 저장 장치를 + 바꿔(SSD·NVMe) 저널 커밋과 0 쓰기의 비용 비율을 다시 잰 뒤에 정한다. +2. **동기화와 다음 묶음 겹치기.** 묶음 하나의 CPU 일은 약 50–100 µs이고 동기화는 2.5–14 ms다. 겹쳐도 얻는 것은 + 몇 퍼센트다. 또 다음 커밋의 헤드는 앞 커밋이 내구성을 얻기 전에 쓸 수 없다(두 슬롯 복구의 전제). 보류한다. +3. **다른 프로세스의 확인 동기화.** 짧은 명령(`aup run --store`)의 첫 커밋이 동기화를 두 번 한다. 쓰기 잠금 파일에 + "마지막으로 내구성을 얻은 헤드"를 적어 두는 방법이 있다. 다만 재부팅 뒤에는 믿을 수 없으므로 부팅 식별자를 + 함께 적어야 한다. 서버 한 개가 저장소를 소유하는 지금의 배치에서는 드물어 보류한다. + +더 큰 방향은 쓰기 증폭이다. 16 B를 고쳐도 그 leaf 전체(최대 4 KiB)와 카탈로그 경로를 다시 쓴다. 작은 편집을 +로그에 델타로 적고 leaf 재작성을 나중에 모아 하는 방식(WAL과 체크포인트, 또는 델타 사슬)이면 커밋 바이트가 +수십 분의 일로 준다. 대신 다른 프로세스의 읽기가 델타를 적용해야 한다. 저장소 설계를 바꾸는 일이라 따로 연구한다. |