기술 · 실용 가이드
PostgreSQL “could not resize shared memory segment”: 먼저 어떤 파일시스템이 찼는지 증명하세요
ENOSPC만으로 데이터 디스크가 찼다고 결론낼 수 없습니다. 정확한 할당 오류를 보존하고 PostgreSQL의 runtime namespace에서 mount를 확인한 뒤, peak를 실패 workload와 연결하고 한 경계만 바꿔 같은 작업을 재현합니다.
ENOSPC만으로 데이터 디스크가 찼다고 결론낼 수 없습니다. 정확한 할당 오류를 보존하고 PostgreSQL의 runtime namespace에서 mount를 확인한 뒤, peak를 실패 workload와 연결하고 한 경계만 바꿔 같은 작업을 재현합니다.
PostgreSQL parallel operation은 dynamic shared memory를 사용할 수 있습니다. Linux POSIX shared memory는 보통 /dev/shm의 tmpfs에 있으며 host와 data volume에 공간이 있어도 container의 private mount는 작을 수 있습니다.
1. 정확한 allocation과 runtime identity를 보존하세요
전체 PostgreSQL error, 요청 size, SQL/maintenance, backend PID, 시간, database, request ID와 실제 container ID·pod UID·service task를 보존합니다.
host data volume 그래프부터 보지 마세요. ENOSPC는 경계 도달만 말하며 path·DSM 구현·process namespace가 조사 대상을 정합니다.
2. PostgreSQL namespace에서 mount를 검사하세요
같은 container/pod에서 df -h /dev/shm, df -i /dev/shm, findmnt -T /dev/shm을 실행해 size, used, inode, filesystem, option을 저장합니다.
SHOW dynamic_shared_memory_type과 parallel setting을 기록합니다. posix면 Linux /dev/shm을, 다른 유형이면 문서화된 backing을 따릅니다.
3. peak를 실패 workload와 연결하세요
필요하면 실행 없는 EXPLAIN으로 parallel worker를 확인하고 max_parallel_workers_per_gather, 동시 query, 겹치는 VACUUM을 기록하며 재현 전후 /dev/shm을 측정합니다.
shared_buffers나 work_mem을 보편적 해법으로 쓰지 마세요. 요청 증가량과 동시 DSM 사용량을 active mount headroom과 비교합니다.
4. 증명된 경계 하나만 바꾸세요
Docker는 service에 shm size를 지정하고 container를 재생성해야 합니다. Kubernetes memory-backed emptyDir는 pod memory budget과 함께 설계합니다.
안전하게 늘릴 수 없으면 parallel worker나 concurrency peak를 제한합니다. server 실행 중 /dev/shm의 PostgreSQL처럼 보이는 파일을 임의로 삭제하지 않습니다.
5. 같은 workload로 exit gate를 확인하세요
rollout 후 active runtime에서 findmnt와 df를 다시 저장하고 같은 SQL, parallelism, 대표 concurrency로 peak를 관찰합니다.
이전 작업이 완료되고 headroom이 남으며 새 DSM error가 없고 memory budget 안일 때만 승인합니다. 오류가 이동했다면 되돌립니다.
