なぜosは6.5Gの使用を示していますが、ファイル/ディレクトリに3.6Gしか表示されないのですか?
Amazon Linux AMI(Centosのように見える)でrootとして実行し、大量の空きメモリが利用可能で、スワッピングが発生せず、明らかなファイル記述子の問題がない。私が考えることができる唯一のことは、アプリケーションがそれに追加している間に削除されたログファイルです。
ディスクスペースの使用率はゆっくりですが継続的にフルキャパシティに向かって上昇しています(時々、非常に小さい減少で約1k /分)
説明はありますか?解決?
du --max-depth = 1 -h /
1.2G/usr
4.0K/cgroup
22M/lib64
11M/sbin
19M/etc
52K/dev
2.1G/var
4.0K /メディア
0/sys
4.0K/selinux
du:アクセスできません/proc/14024/task/14024/fd/4': No such file or directory du: cannot access<br/>
/proc/14024/task/14024/fdinfo/4 ':そのようなファイルやディレクトリはありませんdu:
アクセスできません/proc/14024/fd/4': No such file or directory du: cannot<br/> access
/proc/14024/fdinfo/4 ':そのようなファイルまたはディレクトリはありません0/proc
18M /ホーム
4.0K /ログ
8.1M/bin
16K/lost + found
12M/tmp
4.0K/srv
35M /ブート
79M/lib
56K /ルート
67M/opt
4.0K /ローカル
4.0K /分
.6G /df -h
使用されているファイルシステムのサイズ
/dev/xvda1 7.9G 6.5G 1.4G 84%/ tmpfs 3.7G 0 3.7G 0%/ dev/shmsysctl fs.file-nr fs.file-nr = 864 0 761182
削除されたファイルがプロセスによってまだ開かれている場合、プロセスがファイルを閉じる(または強制終了される)まで、スペースは再利用されません。ファイルを開いたままにしているプロセスを特定できない場合は、再起動すると、実行中のすべてのプロセスが閉じます(したがって、開いているすべてのファイルが閉じます)。
別の考慮事項は、ファイルシステムの破損です。これはルートファイルシステムであるため、再起動して再起動時にファイルシステムチェックを強制する必要がある場合があります(shutdown -rF now
)。 KVM=アクセスまたは同様のもの(起動プロセス中に対話できるようにする)がない場合を除いて、非対話型スキャン+修正を実行するように構成されていることを確認してください。チェック中にエラーが見つかった場合は入力します。
編集:(コメントの質問どおり)
ファイルを開いたままにしているプロセスがわかっている場合は、インスタンス全体ではなく、その特定のプロセス(サービスの停止/開始/再起動スクリプトを使用するか、手動で強制終了して再起動する)を再起動できます。
また、一部のプログラムは、再起動せずに自分自身をリセットできることをサポートします。これには、SIGHUPシグナル(kill
経由)の送信に応答して、ログファイルを閉じて再起動することが含まれます(削除されたログファイルがまだ開いているために問題が解決した場合)。 )。この方法でプロセスをリセットすると、サーバープロセスが新しい接続を受け入れることができない時間を短縮(多くの場合0)するため、好ましい場合があります。これは、しばしば/etc/init.d/<service> reload
の代わりに /etc/init.d/<service> restart
(実際にrestart
がこの方法で実装されているのを見た場合、適切なフルリセットを行うには/etc/init.d/<service> stop; /etc/init.d/<service> start
)。
/ proc // fd /のfdリンクを介して開いているプロセスを再起動せずにスペースを再利用するように管理されました。
1)保持プロセスファイル記述子のパスを取得します。
cd /proc/`lsof|grep '<deleted_file>'|head -1|awk '{print $2}'`/fd
2)プロセスfdリンクを見つける:
ll | grep <deleted_file>
3)空白で上書き(すべてのデータが失われます)
> <fd>