ファイルを削除してもスペースが解放されないのはなぜですか?

Linux 環境で、ファイルが削除されたのにスペースが解放されないという状況に遭遇したことがありますか?この短い記事では、この問題のシナリオと対応する解決策を紹介します。

当社のアプリケーション サーバーの 1 つ、オペレーティング システムは Red Hat Linux、モニタリング アラーム、/opt/applog ファイル システムの使用量がしきい値を超えています。全体の容量は 50G ですが、実際のファイル容量は 20G です。残りの 30G は何ですか空間？ ？

Linux 環境では、すべてがファイルの形式で存在することがわかっています。システムはバックグラウンドで各アプリケーションにファイル記述子を割り当てます。これにより、アプリケーションとオペレーティング システム間の対話が容易になります。一般的なインターフェイスが提供されます。 . ファイルなのでスペースを消費しますが、このとき、システムが現在開いているファイルを一覧表示できる lsof コマンドを使用できます。

リーリー

ヘッダーのフィールドには次の意味があります:

コマンド: プロセスの名前
PID: プロセス識別子
ユーザー: プロセス所有者
FD: ファイル記述子。アプリケーションはファイル記述子を通じてファイルを識別します。 cwd、txt など。
TYPE: DIR、REG などのファイルタイプ。
DEVICE: ディスクの名前を指定します
SIZE: ファイルのサイズ
NODE: インデックス ノード (ディスク上のファイルの識別)
NAME: 開いているファイルの正確な名前

一部の行では、NAME が (削除された) を識別していることがわかります。

/opt/applog/E.20171015.info.001.log (削除済み)

これが意味するのは、ファイルは削除されましたが、開いているファイルへのハンドルは閉じられていないということです。コマンド名が filebeat で、USER プロセスの所有者が app であることに注目してください。これがログ収集プロセスです。アプリユーザーがファイルビートプロセスを開きます。

ログ収集プラットフォームを挿入

従来のオープン ソース ログ プラットフォームである ELK は、ElasticSearch、Logstash、Kiabana の 3 つのオープン ソース ツールで構成されています。その内訳は次のとおりです。

Elasticsearch は、オープンソースの分散型検索エンジンであり、分散型、ゼロ構成、自動検出、自動インデックス シャーディング、インデックス コピー メカニズム、Restful スタイル インターフェイス、複数のデータ ソース、自動検索読み込みなどを備えています。
Logstash は、後で使用できるようにログを収集、フィルタリング、保存できるオープン ソースの収集ツールです。
Kibana は、Logstash および ElasticSearch にログ分析しやすい Web インターフェイスを提供し、重要なデータ ログを集約、分析、検索できるオープンソースのグラフィカル Web ツールです。

一般的な展開図は次のとおりです

上記の filebeat とは何ですか? ELKとの関係は何ですか？

Zhihu については、偉大な専門家 Rao Chenlin (「ELKstack Authoritative Guide」の著者) による紹介があり、非常に洞察力に富み、https://www.zhihu.com/question/54058964/answer/137882919# から引用されています。

##logstash は jvm によって実行され、大量のリソースを消費するため、作成者は後に golang を使用して、機能は少ないがリソース消費量が少ない軽量の logstash フォワーダーを作成しました。ただし、著者は単なる 1 人であり、

簡単に言えば、filebeat はログ収集のプロセス エージェントであり、アプリケーション ログ ファイルの収集を担当します。

上記の問題に関して、(削除された) 未解放のファイル ハンドルが多数あるのは、ディスク容量が非常に限られているため、12 時間前のログを 1 時間ごとに削除するタスクを一時的に追加したためです。つまり、スケジュールされたタスクは、現時点で filebeat が開いているいくつかのファイルを自動的に削除するため、これらのファイルは未解放のファイルとなり、実際のファイルは削除されますが、スペースは解放されません。

解決策 1:

占有スペースをすぐに解放するための最も直接的な方法は、-9 filebeat プロセスを強制終了することです。この時点でスペースが解放されます。しかし、これは根本的な解決策ではなく、スケジュールされたタスクによって、filebeat で開かれたこれらのファイルも削除され、スペースがいっぱいになってしまいます。

解決策 2:

Filebeat の設定ファイル filebeat.yml には、実際には 2 つのパラメータがあります:

close_older: 1 時間

• 説明
  : close old は、close_older より長い間変更されていないファイル ハンドラーを閉じます。2h (2 時間)、5m (5 分) などの時間文字列を使用できます。
つまり、一定期間ファイルが更新されなかった場合、監視対象のファイルハンドルはクローズされます(デフォルトは1時間)。

• force_close_files: false
  説明: このオプションは、ファイル名が変更されるとすぐにファイルを閉じます。この設定オプションは Windows でのみ推奨されます。Filebeat は、読み取っているファイルを開いたままにします。これにより、ファイルが削除されると問題が発生する可能性があります。ファイルは、Filebeat が読み取りを閉じるまで完全には削除されません。Filebeat は、ignore_older の後にファイル ハンドラーを閉じます。この間、同じ名前の新しいファイルは作成できません。一方、この機能をオンにすると、データが失われる可能性があります。ファイルを回転します。ファイルの回転後、読み取りが最後から始まるため、新しいファイルの先頭がスキップされることがあります。ファイルをより速く解放するには、このオプションを false のままにし、ignore_older の値を下げることをお勧めします。

つまり、名前変更や削除など、ファイル名が変更されると、ファイルは自動的に閉じられます。

これら 2 つのパラメータを組み合わせます。アプリケーション要件によると、ファイルが 30 分以内に更新されない場合はハンドルを閉じる必要があります。ファイルの名前が変更または削除された場合は、ハンドルを閉じる必要があります。

閉じる_古い: 30分
Force_close_files: true

filebeat 収集ログと履歴ファイルの定期的な削除の基本要件を満たすことができます。

以上がファイルを削除してもスペースが解放されないのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。