☰

CentOS 6に十分なスペースがないため、回収する必要があります。 [閉じる]

tag-icon • tag-icon centos disk-usage
CentOS 6に十分なスペースがないため、回収する必要があります。 [閉じる]

CentOS 6にはすべてのスペースを使用しているが、スペースがどこに行ったのか分からない問題があります。

100％書き込んだと思います。

df -h

Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/vg_sugar-lv_root   50G   49G     0 100% /

50Gのうち49Gは公平ですが、正確に何が使用されているかを確認しようとすると、次のようになります（xはインストールの削除を意味します）。

du -xsh /*

1.8G    /usr
2.0G    /var

これは2つの最大のディレクトリであり、他のすべてのディレクトリを組み合わせた場合は1G未満です。

以下は、ディスク/dev/mapper/vg_sugar-lv_rootに関する情報です。これは50Gの近くに表示されます（これは仮想マシンです）。

fdisk -l

Disk /dev/mapper/vg_sugar-lv_root: 53.7 GB, 53687091200 bytes
255 heads, 63 sectors/track, 6527 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

ノード数は7％です。

df -i

Filesystem                   Inodes  IUsed     IFree   IUse% Mounted on
/dev/mapper/vg_sugar-lv_root 3276800 200552    3076248    7% /

システムが何度も再起動されたため、すべてのログファイルが削除された可能性があります。この問題を解決する方法に関するいくつかのヒントを知りたいです。

答え1

さて、それでは解決策を投稿します。この例では、ローカルディレクトリ/mnt/backupにインストールされているネットワークの場所/mnt/backupです。一度取り除かれたら

umount /mnt/backup

ローカルディレクトリがバックアップでいっぱいの45Gを占めていることを示しています。

cd /mnt/backup/ du -h 39G ./servers-unix-hq/sugar.gnsa.local 39G ./servers-unix-hq 4.5G ./db-mysql-hq/sugar.gnsa.local 4.5G ./db-mysql-hq 44G いくつかの古いバックアップが削除され、MySQLが起動します。

答え2

これは通常、誰かが増えるファイルを切り捨てるのではなく、削除した場合に発生します。ファイルを書き込むプログラムがディスク領域を閉じるまで、ディスク領域は解放されません。

lsof +L1削除されたがまだ開いているすべてのファイルとそのファイルを開いたままにするプロセスのリストを取得します。出力は次のとおりです。

# lsof +L1
COMMAND     PID     USER   FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
php-fpm7.  1364     root    3u   REG   0,45        0     0   41658 /tmp/.ZendSem.plytyh (deleted)

COMMANDフィールドとPIDフィールドは、どのプロセスがファイルを開いたままにしているかを示し、NAMEはファイル名が何であるかを示します。 TYPEフィールドの値はREGであり、これは通常のファイルであることを示します。 SIZE / OFF値は削除されたファイルのサイズに関するアイデアを提供できますが、常に信頼できるわけではありません（プログラムがファイルの最後に追加し続け、その間に何も更新しない場合にのみ）。幸いなことに、これはほとんどのログファイルのデフォルトです）。

問題の原因を特定したら、問題を解決するにはいくつかの方法があります。

1.可能であれば、そのプロセスのログローテーション機能を呼び出します。

問題ファイルがログファイルであり、開いているプロセスにログの回転を許可する機能がある場合（たとえば、プロセスにすべてのログファイルを閉じて再度開くように指示できます）、ログの回転機能をトリガーできます。多くのデーモンはkill -HUPこの目的のために1つ以上の他の信号を受け入れます。削除されたファイルのデータは、最初に回復しないと失われます（下記参照）。

2.ファイルを開いたままにするプロセスを停止して再起動します。

ファイルを開いたままプロセスを停止して再開すると、問題が解決し、削除されたファイルの内容が永久に失われます（最初に復元しない限り、以下を参照）。

3.（対処方法）削除したファイルにアクセスしたがまだ開いているファイルを0サイズに切り捨てます。

出力でPID番号とFD番号を使用すると、lsof +L1rootアクセス権がある場合は、ファイルシステムを介して「削除されたがまだ開いている」ファイルにアクセスできます/proc。上記の例のファイルは/proc/1364/fd/3。

（FD番号の後のすべての文字は、どのようにプロセスがファイルにアクセスしているので無視できます。 )

cat削除されたファイルの内容を回復する必要がある場合は、出力を別のファイル（十分な空き容量を持つ別のファイルシステム）に転送するだけです。

ディスク容量のみを確保する必要がある場合は、コマンドを使用してファイルをゼロサイズに切り取ることができます> /proc/1364/fd/3（つまり、コマンドなしでコマンドラインを使用すると、出力を切り取るファイルにリダイレクトするだけです）。

メモ:既存のデータのみが削除されます。より多くのデータが削除されたファイルに蓄積されるのを防ぐことはできませんが、メンテナンスダウンタイムをスケジュールできるまで重要なサービスを実行し続けることができます。

記録中のログファイルを削除することは、初心者のUnixシステム管理者がよく犯す間違いです。ほとんどすべての人がUnix / Linuxのキャリアで少なくとも一度はこの間違いを犯します。良い人は自分の間違いから教訓を得て、間違いが発生した場合は直し、将来は間違いを避ける方法を学びます。

関連情報