df
を実行すると、ルートデバイスがいっぱいであることが示されます。
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.9G 9.4G 0 100% /
inode
の使用状況を確認しましたが、ルートデバイスに使用できるスペースはかなりあります。
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 640K 103K 538K 16% /
しかし、du
コマンドを実行すると、2G
のうち9.9G
のみを使用したことが示されます。
ip-XXX-XXX-XXX-XXX:/$ du -xh --max-depth=1
14M ./etc
4.0K ./mnt
96K ./tmp
3.5M ./bin
0 ./sys
964K ./boot
4.0K ./srv
0 ./dev
55M ./lib
25M ./root
1.1G ./usr
4.0K ./opt
846M ./var
4.3M ./sbin
23M ./home
16K ./lost+found
0 ./proc
2.0G .
それは私を夢中にさせて面白いものにしました。ルートディスク/
がいっぱいで、サイトの一部の機能が失敗しているため、これは私たちにとって大きな問題です。
この問題を解決する(また理解する)のを手伝ってください。
ありがとう。
* nixでファイルが削除されると、プロセスがファイルを開いている限り、ファイルはディスク上に存在し続けます(そしてディスクスペースを占有します)。これを利用して一時ファイルを小さなサイズで作成して削除し、削除されたファイルを使用して他のプロセスが(簡単に)アクセスすることを心配せずにデータを保存することで、一時ファイルを「保護」することはかなり一般的です。たとえば、一時データベースまたはマルチメディア編集セッションがこのように処理されている場合、削除されたファイルのスペースの量はかなり大きくなる可能性があります。プログラムを再起動または再起動せずにシステムを(複数回)アップグレードした場合、「失われた」スペースが非常に多くなる可能性があります。その結果、古い.soライブラリはすべて、以前に開始されたプログラムによって開かれたままになります。アップグレードして、まだ実行中です。
df
は、デバイスに割り当てられているスペースの量を確認するだけなので、これらのファイルが使用するスペースを確認しますが、対応するディレクトリエントリがないため、du
はファイルを確認しません。
このような「非表示」の使用済みスペースは、ファイルを削除したプロセスが開いている場合にのみ解放できます。これらのプロセスは、fuser
コマンドで見つけて終了できます(または、多くのデーモンの場合、開いているファイルを閉じて再度開くように指示するシグナルを送信します)。
ディスクがいっぱいになると、大量のファイルを削除した場合でも、再起動/再マウントするまでディスクがまだいっぱいであると混乱することがあります。
私の側では、単にsyslogdを再起動して、ディスク容量を取り戻しました。 3GBが足りませんでした!私のサーバーは250日間稼働していました。
アプリケーションを再起動せずにスペースをクリーンアップする方法があります。詳細は次のとおりです。
プロセスfoo
を実行し、abc.logという名前の2GBファイルを作成しているとします。ここで、このabc.logが他の誰かによって削除されたとしましょう。
foo
のpidを取得します(たとえば123)。したがって、/proc/123/fd
は、foo
によって開かれたファイル記述子のリストを表示します。 abc.logのあるものは削除済みとして表示されます。 abs.logのfd
が111であるとしましょう。less /proc/123/fd/111
を実行すると、2GBのデータがすべて表示されます。
echo " " > /proc/123/fd/111
を実行します。これにより、内容が空の文字列で上書きされます。このコマンドの後でdf
を試行すると、abc.logをクリーニングすることでさらに2GBが回復したことが表示されます。
それでおしまい。 CentOSでこれを試しましたが、機能します。