ZimaOSの大きなスワップファイルは、実際にスワップが逼迫していることと同じではありません。ブートディスクの空き容量を回復するために削除するのは適切な方法ではありません。スワップの実使用量、メモリプレッシャー、Dockerのディスク使用量、ログ、AppDataの保存場所を確認してから、スワップ設定を変更してください。
2026年の元スレッドでは、3.8GBの.swapファイルが、ほぼ満杯になった48GBのブートディスクの原因だとされていました。しかし計算上、スワップが不足容量に占める割合はごくわずかでした。その後、システムでは約20GBの空き容量が回復しており、スワップの縮小よりも、一時的なDockerやキャッシュのクリーンアップが原因である可能性が高いと考えられます。
予約済みスワップ容量と実際のスワップ使用量
次を実行します：
free -h
swapon --show4GBのスワップファイルがディスク上に存在していても、実際に使用されているのはごく一部ということがあります。ファイルサイズは予約された容量であり、RAMが4GB分あふれたことを意味するわけではありません。
システムディスクを圧迫している原因を確認する
次を実行します：
df -h
du -xh /var/lib/docker --max-depth=1 2>/dev/null | sort -hアプリケーションのメディアが別の場所にマッピングされていても、Dockerのイメージレイヤー、書き込み可能なオーバーレイ、ログ、キャッシュ、一時データによって、小容量のシステムディスクが圧迫されることがあります。
AppDataをシステムドライブの外に置く
現在のZimaOSアプリデータガイドでは、システムドライブを圧迫するのではなく、ストレージ領域をApp data locationに設定することを明確に推奨しています。
これですべてのDocker関連のシステム使用量がなくなるわけではありませんが、アプリケーションのデータベースやメディアキャッシュがデフォルトでブートデバイスを圧迫するのを防げます。
コンテナログを確認する
ログの出力が多いコンテナでは、JSONログが急速に増えることがあります。ランダムにファイルを削除する前に、Dockerのディスク使用量とコンテナログのサイズを確認してください。
特定のアプリが原因なら、アクティブなログファイルを手動で削除するのではなく、ログの出力方法を修正するか、ログローテーションを設定してください。
スワップ使用量が多い場合でもRAM不足とは限らない
free -hで利用可能なメモリが少なく、スワップが実際に使用されている場合は、RAMを消費しているプロセスを特定してください。負荷の高いデータベース、写真のインデックス作成、AIワークロード、仮想マシンによって、少ないメモリのシステムがスワップに移行することがあります。
症状を隠すためだけにスワップを無効にしない
スワップは、短時間のメモリ急増時にシステムを稼働し続けるのに役立ちます。メモリに余裕のないサーバーでスワップを無効にすると、動作の遅延がメモリ不足によるプロセス強制終了に変わる可能性があります。
RAMを増設するタイミング
継続的なワークロードによって物理メモリが常に不足し、重要なサービスが頻繁にページングしている場合は、RAMを増設してください。スワップファイルが存在するというだけでRAMをアップグレードする必要はありません。
パフォーマンスのトラブルシューティングガイドを使うと、遅いサーバーをすべてRAMの問題として扱うのを避けられます。
メモリプレッシャーを時間をかけて測定する
Linuxは空きRAMをキャッシュとして積極的に使用するため、free -hの1回の結果だけでは誤解を招くことがあります。利用可能なメモリと、ワークロード中にスワップイン／スワップアウトが継続しているかを確認してください。
システムで利用できるツールが継続的なスワップを示し、サーバーの動作が遅い場合は、スワップファイルのサイズだけに注目せず、どのアプリや仮想マシンがメモリを消費しているかを特定してください。
Dockerイメージもシステム領域を消費する
AppDataを/DATAに移動しても、すべてのDockerイメージレイヤーやランタイムファイルが移動するわけではありません。そのため、ユーザー向けのデータボリュームがすべて別の場所を指していても、多数のアプリをインストールまたは更新するとシステムディスクが圧迫されることがあります。
プルーニングを実行する前に、Docker本来のディスク使用量表示を使って、イメージ、コンテナ、ローカルボリューム、ビルドキャッシュを区別してください。未使用だと確信できるオブジェクトだけを削除します。
小容量のシステムディスクが構造的な問題か確認する
48GBのブートディスクでも運用できますが、複数のアプリイメージ、アップデート、ログ、一時処理のための余裕はほとんどありません。クリーンアップを適切に行ってもシステムが繰り返し100%近くまで使用される場合は、より大容量のシステムディスクに交換するか、永続的なワークロードをメインストレージに移すことが、持続的な解決策になる可能性があります。
空き容量不足は二次障害を引き起こすことがある
書き込み可能なシステム領域がほぼ満杯になると、アプリの更新、データベースへの書き込み、ログ、一時ファイルが、ストレージとは無関係に見える形で失敗することがあります。別のアレイにテラバイト単位の空き容量があっても、空き容量が極端に少ない状態は運用上のリスクと考えてください。
FAQ
なぜ一晩でディスクの空き容量が戻ったのですか？
一時的なDockerレイヤー、キャッシュ、ログ、またはクリーンアップ処理によって空き容量が解放された可能性があります。スワップファイル自体が縮小したという意味ではありません。
.swapファイルを削除すべきですか？
いいえ。まず、実際のスワップ使用量と、ディスク容量を消費している本当の原因を確認してください。
3～4GBのスワップは正常ですか？
数GBのスワップファイルが存在すること自体は珍しくありません。重要なのは、スワップが実際にどれだけ使用されているか、そしてメモリプレッシャーが継続しているかどうかです。
AppDataを/DATAに置いているのに、なぜブートディスクが使用されるのですか？
Dockerエンジンのメタデータ、イメージレイヤー、ランタイムオーバーレイ、ログ、システムファイルは、マッピングしたアプリケーションデータとは別の場所に残るためです。
