fork 직후 메모리는 작게 늘었는데 부모가 쓰기를 시작하자 RSS가 급증합니다. copy-on-write는 무엇을 미루나요?

fork의 copy-on-write는 부모와 자식이 초기 페이지를 공유하고 어느 쪽이 변경할 때 필요한 페이지를 복사하는 방식입니다. 복사 비용을 없애는 것이 아니라 실제 쓰기 시점으로 미루는 것입니다.

동작 원리와 전제

읽기만 하면 많은 페이지를 공유할 수 있지만 작은 객체 변경도 페이지 단위 복사를 유발할 수 있습니다. 부모와 자식의 RSS 합을 실제 물리 메모리와 단순 동일시하면 공유 페이지를 중복 계산할 수 있어 PSS·공유 지표를 함께 봅니다.

선택과 실패 처리

대량 쓰기 중 snapshot 프로세스를 오래 유지하면 복사 페이지가 늘어 메모리 피크가 생깁니다. fork 자체의 페이지 테이블·지연 비용도 있습니다. 멀티스레드 프로세스의 락·라이브러리 상태를 자식에서 안전하게 쓰는 문제는 COW와 별개입니다.

구체적인 사례와 검증

부모가 snapshot 자식을 만든 뒤 큰 해시 테이블을 갱신하면 소수 필드 변경도 여러 페이지를 더럽혀 복사가 늘 수 있습니다. 자식이 느린 디스크 때문에 오래 살아 있으면 그 기간 동안 메모리 피크가 더 커집니다. 따라서 snapshot 크기만 아니라 최대 쓰기율과 지속 시간을 함께 계산합니다. 공유 페이지를 각 프로세스 RSS에 중복 포함할 수 있어 단순 RSS 합과 실제 물리 사용을 구분합니다. COW가 적용된다고 부모의 열린 연결·락·스레드 상태까지 자식에서 안전한 것은 아니므로 fork 후 실행 경로의 라이브러리 계약을 별도로 확인해야 합니다.

읽기 중심·최대 쓰기율·자식 지연·메모리 제한을 시험합니다. 평균 사용량이 아니라 fork 기간의 피크와 OOM 여유를 확인합니다. Redis 같은 snapshot 시스템도 같은 원리를 사용하므로 백그라운드라고 비용이 없다고 하지 않습니다.