記事ディレクトリ
数日前、友人が深夜にメッセージを送ってきて、彼のサーバーがクラッシュしたと言ってきた。
具体的な症状は特に奇妙だった。ウェブサイトが突然エラーを発生させ始め、ログを書き込むことができなくなり、新しいファイルを作成しようとするとすぐにディスクがいっぱいだというメッセージが表示されるようになった。
しかし、`df -h`コマンドで確認してみると、ディスクには明らかに数十ギガバイトもの空き容量があることが分かり、彼は衝撃を受けた。どうして満杯になっているのだろうか？
私はその場で彼にこう言った。「兄弟、君のストレージ容量がいっぱいなだけじゃない、君のinodeは過負荷状態だよ。」
彼は疑問符付きでこう答えた。「イノードとは一体何ですか？」
実際、多くの人が彼と全く同じように、この罠に陥った時に反応する。なぜなら、学校では誰もこういうことを教えてくれなかったからだ。
まず、iノードとは何かを明確にしておきましょう。
図書館の索引カードを想像すれば、理解しやすいでしょう。
ディスク容量は本棚のようなもので、そこに何冊の本を置けるかは容量によって決まる。これは誰にとっても理解しやすいだろう。
iノードは、各書籍に対応する索引カードのようなもので、書籍の名前、場所、そして誰が移動させたかを記録します。
Linuxでは、ファイルのサイズに関係なく、すべてのファイルとすべてのディレクトリはinodeを占有する必要があります。
たとえ空のファイルであっても、システムはインデックスカードを1枚消費します。
システムが作成できるファイルの総数には制限があり、その制限はinnodeの総数に等しい。
iノードが使い果たされると、たとえディスクに数百ギガバイトの空き容量が残っていても、オペレーティングシステムは新しいファイルの作成を拒否します。
ログの書き込みもキャッシュの作成もできず、ウェブサイトが完全にクラッシュする――これがあなたが目撃している奇妙な光景です。
正直言って、これは非常に厄介な状況です。なぜなら、エラーメッセージはあなたが見ていない場所から送信されているからです。
まず最初に、`df -i` コマンドを使って概要を素早く把握する方法があります。
HestiaCP環境では、ターミナルにSSH接続して、以下の行を入力するだけで済みます。
df -iマウントされた各パーティションについて、innodeの総数、使用中の数、および残りの数を一覧表示します。
出力結果には「IUse%」という列があり、これが注目すべき重要な指標です。
パーティションのIUse%が100%に達すると、そのパーティションに十分なディスク容量が残っていても、新しいファイルやログを作成できなくなります。
私は友人に、まずこれを実行するように勧めました。そうすれば、問題がiノードにあるかどうかをすぐに特定でき、推測するよりもはるかに速いからです。
2つ目の方法は、`find`コマンドを使って特定のユーザーを正確にカウントすることです。
問題がinnodeにあることを確認したら、次のステップは、インデックスカードを過剰に消費しているユーザーを特定することです。
HestiaCPにはユーザーごとに個別のホームディレクトリがあります。特定のウェブサイトディレクトリの下にあるファイルとディレクトリの総数を数えるだけで済みます。
find /home/用户名/web/你的域名/public_html | wc -l「username」と「your domain name」を実際のパスに置き換えてください。ターミナルが返す数値は、そのディレクトリ内のすべてのファイルとフォルダの合計です。
各ファイルまたはディレクトリは1つのinodeに対応するため、この数値はinodeの使用量を表します。
一つ一つ確認するのが面倒で、サイト全体の全ユーザーの利用状況の分布を一度に確認したい場合は、単一のループコマンドもあります。
for d in /home/*; do echo -n "$d: "; find "$d" 2>/dev/null | wc -l; doneこの行は、/home以下の各ユーザーディレクトリにあるファイルの総数を表示するため、どのユーザーディレクトリに異常に多くのファイルが存在するかを簡単に特定できます。
3つ目の戦略は、最も多くのヨウ素を消費するサブディレクトリを特定することです。
ウェブサイトのinode値が異常に高いことは分かっていても、画面いっぱいに表示されたファイルの何が問題なのか、どうしても分からないことがあります。
このような場合は、キャッシュディレクトリ、セッションディレクトリ、ログディレクトリなど、多数の小さなファイルを含むサブフォルダを見つけるために、さらに階層を掘り下げる必要があります。これらのフォルダが最も問題のある領域です。
find /home/用户名/web/你的域名/public_html -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 | wc -l' \; | sort -n -r -k 2 | head -n 10このコマンドは、最も多くのファイルを使用している上位10個のサブフォルダを一覧表示します。
リストの一番上にあるパスには、多数の小さなファイルがまとめて保存されています。
私は友人に、おそらく何らかのキャッシュプラグインが密かに小さなファイルを生成しているのだろうと伝え、この行を実行すればそれがほぼ確実に確認できるだろうと言いました。
4つ目のヒントは、repquotaを使用して割り当て制限を確認することです。
サーバーでLinuxファイルシステムのクォータが有効になっている場合は、別の視点から問題を検討することができます。
repquota -aこのコマンドを実行すると、すべてのユーザーのファイル制限と実際のファイル使用量が表示されます。
出力結果の「ファイル制限」セクションに特に注意してください。「使用済み」列には、使用されたファイルの数が表示されます。
「soft」列と「hard」列は、それぞれソフトリミットとハードリミットのしきい値を表します。「used」が「hard」に達すると、システムは新規ファイルの作成を即座に拒否します。
これは、ディスクの空き容量とは全く別の話です。
最後に、今回の調査の結果をまとめて、点と点をつなぎ合わせてみましょう。
冒頭で、真夜中にサーバーをクラッシュさせた友人の話に戻りましょう。
彼は私が説明した4つの手順に従い、まず`df -i`を実行してinodeが実際に満杯であることを確認した。
次に、findコマンドを使って、大量の小さなファイルを生成していた、放棄された古いウェブサイトのキャッシュディレクトリを特定した。
最後に、`repquota`を確認したところ、確かに上限に達していたことが確認できた。
大量の不要なキャッシュを削除した後、ウェブサイトはすぐに復旧した。
ですから、次回「ディスクには明らかに空き容量があるのに、ファイルを書き込めない」という奇妙な状況に遭遇しても、すぐにハードドライブを追加しようとしないでください。
まず、`df -i` コマンドを使ってinodeを調べてみてください。もしかしたら、今まで気づかなかったインデックスカードに真実が隠されているかもしれません。
システムの核心に隠されたこうしたちょっとした常識的な考え方は、何百もの最適化リストを暗記するよりもずっと役に立つと私は心から信じています。
Chen Weiliang氏のブログ（https://www.chenweiliang.com/ ）に掲載されている記事「HestiaCPでinodeの使用状況を確認する方法？ディスク容量は十分にあるのにファイルを書き込めない原因」が、皆様のお役に立てば幸いです。
この記事のリンクはご自由に共有してください：https://www.chenweiliang.com/cwl-34619.html