Linuxサーバーのハードディスク容量が不足しており、書き込みができませんが、ハードディスクにはまだ空き容量があります。どうやら、原因はiノードにあるようです！

Ubuntuシステムでハードディスクの空き容量が不足し、書き込みができないという問題が発生した場合

存在する リナックス サーバーでは、ハードディスクに十分な容量があるように見えても、書き込めませんこれは通常、 iノード 疲れ果てた。

ハードディスクに書き込みができない場合ディスク容量まだ残っている場合は、inodeが枯渇している可能性があります。小さなファイルを整理したり、ファイルシステムあるいは、アーカイブストレージなどの方法で問題を解決し、監視や最適化設計と連携して同様の問題が再発しないようにします。

iノードとは何ですか?

i ノードは、ファイルに関するメタ情報 (ファイルの権限、所有者、作成時間など) を格納するファイル システム内のデータ構造です。
各ファイルは、ファイルのサイズに関わらず、inodeを1つ占有します。inodeが使い果たされると、ハードディスクにまだ空き容量があっても、残りのスペース新しいファイルを作成することはできません。

ハードディスクと i ノードの使用状況を確認するにはどうすればよいでしょうか?

ディスク容量を確認する

df -h

これにより、ディスクの使用量が人間が読める形式で表示されます。

inodeの使用状況を確認する

df -i

出力例:

ファイルシステムのInode IUsed IFree IUse% マウント先
/dev/sda1 1000000 999999 1 100% /

IUse%はinodeの使用率を示します。IUse%が100%に達すると、inodeが使い果たされたことを意味します。

• 小さなファイルが多すぎると、特にログ ファイルや一時ファイルなど、大量の inode が消費されます。
• ファイルシステムの種類。一部のファイルシステム（ext4 など）では、作成時に固定数の inode が割り当てられ、動的に調整することはできません。
• アプリケーションの問題: アプリケーションが小さなファイルを継続的に生成し、i ノードがすぐに使い果たされる可能性があります。

100%を占有するinodeの解決策

まず、システムログファイルを削除します

sudo rm -rf /var/log/*.log

システムログファイルを削除した後、inodeの使用率が依然として100%のまま、あるいはわずかに減少しただけであることがわかりました。この時点で、システム内のどのディレクトリファイルが過剰なスペースを占有しているかを特定する必要があります。

一般的に Linux では、/home に Web サイトのプログラム ファイルが格納され、システム プログラム ファイルは通常 /var ディレクトリに格納されます。

次に、どのディレクトリが多くのスペースを占有しているかを確認し、ルート ディレクトリ内のフォルダーのサイズを確認し、サイズで並べ替えます。

du -h --max- Depth = 1 / |ソート -hr

さらに、ディレクトリサイズに基づいて、varディレクトリ内のどのディレクトリが多くのファイルを占めているかを確認します。この方法に従って、他のディレクトリも確認します。

du -h --max- Depth=1 /var |ソート -hr

調査中、/usr/local/lsws/logs が 9.4GB を占めていることがわかりました。そのディレクトリに入ると、約 8GB を占めるauditmodsec.log ファイルがありました。

Auditmodsec.log は ModSecurity の監査ログ ファイルであり、セキュリティ ルールをトリガーする HTTP 要求と応答データを記録します。

調査を続けると、/var/lib/lsphp/session/lsphp83 ディレクトリが多くのスペースを占有しており、ファイルが多すぎることがわかりました。

/var/lib/lsphp/session/lsphp83 ディレクトリは、LiteSpeed PHP (lsphp) セッションに関連するストレージディレクトリです。このディレクトリは通常、LiteSpeed Web Server が PHP スクリプトを処理するために使用する API である LSAPI (LiteSpeed SAPI) に関連しています。

/var/lib/lsphp/session は、LiteSpeed PHP セッションファイルが保存されるディレクトリです。PHP セッションファイルはここに保存され、セッション ID に基づいて名前が付けられます。

セッションディレクトリ内のファイルが多すぎる、または大きすぎる場合、ストレージ容量が不足する可能性があります。無効なセッションファイルを定期的に削除してください。

上記のinodeは100%を占有しています。多くの場合、このディレクトリに問題があります。/var/lib/lsphp/sessionフォルダ内のファイル数が膨大であるため、inodeが100%を占有し、ハードディスクがファイルを書き込めません。ハードディスクがいっぱいであることに加えて、inodeが100%を占有していることも原因の一つです。

これらの問題はどちらも、ハードディスクへのコンテンツの書き込み不能を引き起こします。ハードディスクがファイルの書き込み不能状態になると、Webサイトやデータベースは動作中に一時ファイルへの書き込みが必要になります。一時ファイルの書き込みに失敗すると、Webサイトの機能停止、データベースの停止などの問題が発生します。

セッションファイルのクリーニングと管理

cronを使用して期限切れのセッションファイルを定期的に削除することで、ディレクトリが過剰な容量を占有するのを防ぐことができます。通常、期限切れのセッションファイルはシステム設定に従って自動的に削除されますが、session.gc_maxlifetimeを設定することで削除の頻度を制御することもできます。

まず、PHP 設定ファイルでリサイクル管理を有効にします。

PHPにおけるセッションガベージコレクション（GC）は、期限切れのセッションデータをクリーンアップするためのメカニズムです。環境要件（開発環境、高トラフィックの本番サーバーなど）に応じて、session.gc_probability、session.gc_divisor、session.gc_maxlifetimeの設定を最適化できます。

以下は、シナリオに応じてリサイクルを有効にするための最適な設定に関する推奨事項です。

主要パラメータの最適化の説明

セッション.gc_確率

目的: セッションが初期化されるたびにガベージ コレクションをトリガーする確率を制御します。
推奨設定:
開発環境: 1. デバッグの干渉を減らすために、セッション データを頻繁にクリーンアップすると便利です。
実稼働環境: 1. ガベージ コレクション メカニズムがオンになっていることを確認します。

セッション.gc_divisor

機能: session.gc_probability と組み合わせて、ガベージコレクションが実行される確率を決定します。ガベージコレクションの確率式は以下のとおりです。
コードをコピー
ガベージコレクションの確率 = gc_probability / gc_divisor
推奨設定:
開発環境: 100 (つまり、ガベージ コレクションがトリガーされる確率は 1/100)。
トラフィック量の多い本番環境: 1000 (つまり、ガベージ コレクションがトリガーされる確率が 1/1000 で、パフォーマンスのオーバーヘッドが削減されます)。

セッション.gc_maxlifetime

目的: セッションファイルの最大存続時間（秒単位）を設定します。この時間経過後に使用されないセッションは「ジャンク」とみなされます。
推奨設定:
開発環境: 必要に応じて調整し、通常はより短い時間 (1440 秒 = 24 分など) を設定します。
実稼働環境: アプリケーションの要件とユーザーの習慣に応じてセットアップする時間が長くなります。
例えば：
通常のeコマースプラットフォーム：3600（1時間）
エンタープライズ バックエンド システム: 7200 (2 時間) 以上、例: 14400 (4 時間)。

; ガベージコレクションメカニズムを有効にします。本番環境では、session.gc_probability = 1、session.gc_divisor = 1000、session.gc_maxlifetime = 14400 の設定を推奨します。; 4時間に設定しますが、ビジネスニーズに応じて調整できます。

あるいは、PHP のガベージ コレクション メカニズムに頼るのではなく、cron ジョブまたはその他のツールを使用してセッション データを定期的にクリーンアップします。

find /var/lib/lsphp/session/lsphp83 -type f -mmin +240 -delete

上記のコマンドは、240 分以上前に最後に変更されたセッション ファイルをクリーンアップします。

さて、Ubuntuシステムが登場しますハードディスクの空き容量が不足しています書けない問題が解決しました！