テクノロジー · 実用ガイド
PostgreSQL の「could not resize shared memory segment」：まず枯渇した filesystem を証明する
ENOSPC だけでは data disk の満杯を意味しません。正確な allocation error を保存し、PostgreSQL と同じ runtime namespace から mount を調べ、失敗 workload と peak を結び付けてから一つの境界だけを変更します。
ENOSPC だけでは data disk の満杯を意味しません。正確な allocation error を保存し、PostgreSQL と同じ runtime namespace から mount を調べ、失敗 workload と peak を結び付けてから一つの境界だけを変更します。
PostgreSQL の parallel operation は dynamic shared memory を使います。Linux の POSIX shared memory は通常 /dev/shm の tmpfs にあり、host や data volume に空きがあっても container の private mount は小さい場合があります。
1. allocation と runtime identity を保存する
完全な error、要求 size、SQL/maintenance、backend PID、時刻、database、request ID と、実際の container ID・pod UID・service task を保存します。
host volume graph から始めません。ENOSPC は境界到達だけを示し、path・DSM implementation・process namespace が調査先を示します。
2. PostgreSQL の namespace から mount を見る
同じ container/pod で df -h /dev/shm、df -i /dev/shm、findmnt -T /dev/shm を実行し、size、used、inode、filesystem、mount option を保存します。
SHOW dynamic_shared_memory_type と parallel setting を記録します。posix なら Linux の /dev/shm、別 type なら文書化された 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 を制限します。server 稼働中に /dev/shm の PostgreSQL らしい file を削除しません。
5. 同じ workload で exit gate を設ける
rollout 後に active runtime で findmnt と df を取り直し、同じ SQL、parallelism、代表 concurrency で peak を監視します。
元の操作が完了し、headroom が残り、新しい DSM error がなく memory budget 内なら受け入れます。失敗が移動しただけなら戻します。
