tmpfs・/dev/shm サイズを本番環境で設計する｜OOM 発生条件の確認とメモリ割り当て変更の影響評価

tmpfs と /dev/shm の役割を整理する

Linux の tmpfs は、物理メモリとスワップ領域を組み合わせて通常のファイルシステムと同じインターフェースで扱える仮想ファイルシステムです。マウントされたパスへの書き込みデータはカーネルのページキャッシュ上に存在するため、ディスク I/O には依存せず、揮発性の高速ストレージとして機能します。

/dev/shm は、その tmpfs を POSIX 共有メモリの実装基盤として利用するための標準マウントポイントです。shm_open() で作成されたオブジェクトは /dev/shm 上のファイルとして実体化されるため、/dev/shm のサイズ制限は共有メモリを多用するアプリケーションの動作に直接影響します。PostgreSQL の大規模クエリ処理、Chromium 系ブラウザの GPU プロセス間通信、Apache Spark のオフヒープバッファなどが典型的な利用者です。

重要なのは、tmpfs に書き込まれたデータはすべてシステムの物理メモリを消費するという点です。ディスク容量ではなくメモリを消費するため、サイズ設計の誤りが OOM（Out-of-Memory）キラーの発動に直結します。

OOM が発生するメカニズムとデフォルト設定の落とし穴

多くのディストリビューションにおける /dev/shm のデフォルトサイズは物理メモリの 50% に設定されています。物理メモリが 32 GB のホストであれば /dev/shm の上限は 16 GB として扱われます。この上限はハードリミットであり、実際にそこまでメモリが割り当てられるわけではありませんが、アプリケーションが積極的に書き込めばその分だけ物理メモリを消費します。

OOM が発生する典型的なシナリオはこのように進行します。アプリケーションが /dev/shm に対して大量のデータを書き込み、物理メモリを圧迫します。カーネルはスワップに逃がせるページを探しますが、tmpfs の匿名ページはスワップアウト対象になりにくい性質があります。その結果としてメモリプレッシャーが高まり、残余メモリが閾値を下回ると OOM キラーが起動します。

問題は、強制終了されるプロセスが /dev/shm を大量消費したアプリケーション自身とは限らないことです。OOM スコアはメモリ占有量や実行時間など複数要因で決まるため、データベースや主要サービスが誤射される事例が現場では繰り返し報告されています。また逆に、/dev/shm を小さくしすぎると共有メモリを前提とするアプリケーションが ENOSPC または ENOMEM で失敗します。設計のバランスを見つけるには、まず現状の使用実態を正確に把握することが不可欠です。

本番環境での現状確認手順

設定変更の前に、現行の使用状況を定量的に把握します。以下の確認を順に実施してください。

• 現在のマウント情報確認：findmnt -t tmpfs を実行すると、全 tmpfs マウントポイントのサイズと使用量が一覧表示されます。
• /dev/shm の実使用量：df -h /dev/shm でサイズ上限と現在の使用量を確認します。
• プロセスごとの共有メモリ使用量：ls -lh /dev/shm/ で各エントリを確認し、どのプロセスがどの程度消費しているかを把握します。
• 過去の OOM 発生履歴：journalctl -k -g "Out of memory" --since "7 days ago" で直近のカーネルログを確認します。
• メモリプレッシャーの傾向：vmstat 5 10 や sar -r で時系列の空きメモリ推移を確認します。

これらを組み合わせることで、/dev/shm がピーク時にどの程度消費されているか、OOM 発動までの余裕がどのくらいあるかを推定できます。ピーク使用量が現行上限の 70% を超えている場合、バースト時に上限に到達するリスクが高い状態といえます。

fstab および systemd による設定変更の実施

現状確認が完了したら、設定変更を実施します。変更には 2 つのアプローチがあります。

一時的な変更（動作確認用）

再起動なしで即座に反映したい場合は mount --remount を使います。

sudo mount -o remount,size=4G /dev/shm

この変更は再起動後に失われます。本番環境での動作確認フェーズに限定して使用してください。

永続化：/etc/fstab の編集

従来からの方法は /etc/fstab に明示的に記載する方法です。既存の /dev/shm エントリを探し、size オプションを追記または変更します。

tmpfs   /dev/shm   tmpfs   defaults,size=4G   0   0

編集後は sudo mount -o remount /dev/shm で即時反映できます。次回起動時からはこの設定が自動的に適用されます。

永続化：systemd drop-in による上書き（推奨）

systemd 環境では /dev/shm は dev-shm.mount ユニットとして管理されています。このユニットに drop-in ファイルを当てることで、fstab を編集せずに設定を上書きできます。

sudo mkdir -p /etc/systemd/system/dev-shm.mount.d/
sudo tee /etc/systemd/system/dev-shm.mount.d/override.conf <<'EOF'
[Mount]
Options=mode=1777,strictatime,nosuid,nodev,size=4G
EOF
sudo systemctl daemon-reload
sudo systemctl restart dev-shm.mount

drop-in によるアプローチは、OS アップデートでディストリビューションが提供するデフォルトユニットが更新されても設定が上書きされるリスクを低減できます。また、systemctl cat dev-shm.mount でマージされた設定全体を確認できるため、意図しない設定の混在を防ぎやすい利点があります。

変更後の検証と影響評価

設定変更後は、意図した通りに反映されているかを必ず確認します。

df -h /dev/shm
findmnt /dev/shm

Size 列が変更後の値に更新されていれば正常です。次に、メモリ全体への影響を評価します。

設定上の「size=4G」はハードリミットであり、実際には書き込まれた分だけ消費されます。しかしリミットを大きくすることで、これまで ENOSPC で失敗していた処理が通るようになり、結果として消費メモリが増加します。変更直後は watch -n 5 free -h や vmstat 5 でメモリ残量の推移を継続監視し、MemAvailable が想定範囲を下回っていないかを確認してください。

PostgreSQL のように shared_buffers を通じて共有メモリを確保するデータベースでは、/dev/shm のサイズ変更が設定パラメータの実効値に影響します。変更後にアプリケーションの起動ログや SHOW shared_buffers 等で設定が正常に適用されているかを合わせて確認することを推奨します。

切り戻し手順と設計上の注意点

設定変更後に問題が発生した場合の切り戻しは、変更方法によって異なります。

• fstab 変更の場合：元の記述に戻し、sudo mount -o remount /dev/shm を実行します。
• systemd drop-in の場合：作成した override.conf を削除し、sudo systemctl daemon-reload && sudo systemctl restart dev-shm.mount を実行します。
• 一時変更の場合：再起動するだけで元の設定に戻ります。

設計上の注意点として、サイズ指定は絶対値（例：4G）とパーセンテージ（例：50%）の両方が利用できます。物理メモリが異なる複数ホストに同じ設定を適用する場合はパーセンテージ指定が便利ですが、メモリの多いサーバーでは意図せず巨大な上限が設定されることがあります。構成管理ツール（Ansible 等）でサーバースペックごとに値を切り替えるアプローチが安全です。

コンテナ環境では /dev/shm の扱いがホストとは異なる点にも注意が必要です。Docker は起動時に独自の tmpfs を /dev/shm にマウントし、デフォルトサイズは 64 MB に設定されています。共有メモリを必要とするアプリケーションには不足することが多く、--shm-size オプションや Compose の shm_size キーで明示的に指定する必要があります。ホスト側の /etc/fstab や systemd 設定を変更してもコンテナ内の /dev/shm には影響しない点を特に注意してください。

2026 年時点の現行環境における差分と留意点

2024 年以降のディストリビューション（RHEL 9 系・Ubuntu 24.04・Debian 12 以降）では、tmpfs まわりにいくつかの変動があります。

カーネル 6.x 系では tmpfs のメモリ管理に対する改善が継続的に入っており、MGLRU（Multi-Generational LRU）との相互作用が変化しています。MGLRU は Linux 6.1 以降でデフォルト有効化が進んでおり、ページの再利用効率が上がったことで tmpfs のスワップアウト挙動が以前とやや異なります。過去の経験則をそのまま OOM 発動タイミングの予測に適用しないことを推奨します。

systemd の最新バージョン（v256 以降）では dev-shm.mount の生成ロジックが見直されており、一部の設定が従来と異なる形で生成されることがあります。drop-in を設計する前に systemctl cat dev-shm.mount で実際のユニット内容を確認する習慣をつけてください。

また、cgroupv2 が標準となった現行環境では、サービス単位でのメモリ制限がより細かく適用できます。/dev/shm をサービスごとに分離したい場合は、systemd サービスユニットの PrivateTmp=yes や MemoryMax= を組み合わせることで、ホスト全体の /dev/shm を変更せずに特定サービスのメモリ使用を制限できます。複数サービスが同居する本番ホストでのリソース分離に有効な手法です。

tmpfs と /dev/shm のサイズ設計は一度設定して終わりではなく、アプリケーションの変化やカーネルのアップデートに合わせて継続的に評価が必要な領域です。定期的に journalctl -k -g "oom" でカーネルログを確認する運用フローを組み込むことが、本番環境の長期安定稼働につながります。