プロセスファイルハンドルの漏洩によるディスク領域の解放が不可能な問題の解決
12295 ワード
プロセスファイルハンドルの漏洩によるディスク領域の解放が不可能な問題の解決
問題の発生
今日突然1台のサーバーのディスクの空間の使用率が90%に達する警報を受け取って、そこで機械に上陸してディスクの使用状況を調べて、確かに/dataに掛けた1枚のディスクの使用率が90%に達したことを発見しました:
[root@awsuw7-46 data]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 100G 17G 84G 17% /
devtmpfs 30G 0 30G 0% /dev
tmpfs 29G 0 29G 0% /dev/shm
tmpfs 29G 2.7G 27G 10% /run
tmpfs 29G 0 29G 0% /sys/fs/cgroup
/dev/xvdf 246G 209G 26G 90% /data
tmpfs 5.8G 0 5.8G 0% /run/user/1000
tmpfs 5.8G 0 5.8G 0% /run/user/1003問題を分析する
この場合、私の一般的な処理方法は、対応するディレクトリにジャンプし、どのディレクトリが大きいかを確認し、さらに整理することです.このディスクは/dataディレクトリに外付けされているため、ディレクトリの各ディレクトリディスクの使用量を確認します.
[root@awsuw7-46 data]# du -h --max-depth=1
3.7G ./photo
16K ./lost+found
9.1G ./mls2
36K ./parser
79G ./web
15G ./mls
106G .この外挂ディレクトリは全部で106 Gしか使用されていないが、df-hはこのディスクが209 Gを使用していることを示している.では、使用している他の103 Gはどこに行ったのだろうか.しかも、このディスクには複数のパーティションがなく、このパーティションだけが/dataの下にマウントされている.これは確かに奇妙な問題で、ネット上で原因を検索しました.ファイルを正しく削除しなかったためです.
Linuxオペレーティングシステムでは、ファイルが削除されると、ファイルシステムディレクトリに表示されなくなるため、duは統計を取りません.しかし、この時点で削除されたファイルのハンドルを実行するプロセスがある場合、このファイルは本当にディスクから削除されず、パーティションスーパーブロックの情報も変更されないため、dfコマンドで表示されるディスクの占有量は減少しません.Linuxではディスクパーティションのスーパーブロックが重要であることを知っています.inodeとblockの総量、残量、使用量、ファイルシステムのフォーマットなどの情報を含む、このパーティション上のファイルシステムの全体情報をsuperblockに記録します.したがって、superblockが更新されないと、ディスクの使用量は必然的に変化せず、オペレーティングシステムはファイルのディスクに対してsuperblockの情報を事前に読み取り、使用可能なinodeとblockを割り当てる必要があります.
問題を解決する
1.まずファイルハンドルの漏洩のプロセスを探し出して、私の方法はlowを比較して、システムの中で起動時間の比較的に長いjavaプロセスを探し出して(この機械は主にjavaサービスなため)、それからlsofでこのプロセスのファイルハンドルの使用状況を見ます.なぜなら、最近起動したプロセスでハンドルが漏洩する可能性が低いためです.ハンドルが漏洩しても、再起動後にファイルハンドルが解放されるからです.2962このプロセスでは、ハンドルの漏洩が最も発生する可能性が高いことがわかります.
[root@awsuw7-46 data]# ps -eo pid,lstart,comm | grep java
746 Thu Jan 18 19:44:15 2018 java
1117 Thu Feb 8 02:20:03 2018 java
1160 Thu Feb 8 02:20:09 2018 java
2962 Thu Nov 16 23:08:40 2017 java
3610 Wed Feb 7 22:55:37 2018 java
4579 Thu Feb 8 20:45:09 2018 java
5155 Mon Dec 25 19:01:32 2017 java
6481 Wed Jan 10 05:16:28 2018 java
6519 Thu Jan 18 00:51:07 2018 java
9756 Thu Feb 8 02:36:23 2018 java2.lsofを使用して、上に見つかったプロセスファイルのハンドルの使用状況を分析すると、そのプロセスにハンドルの漏洩が確かに存在し、非常に深刻で、すでに2208のファイルが解放されていないことがわかります.
[root@awsuw7-46 ~]# lsof -p 2962 | grep "delete" | wc -l
2208
[root@awsuw7-46 ~]# lsof -p 2962 | grep "delete" | head -n 20
java 2962 web 17r REG 202,2 2098273 17844538 /tmp/winstone962950350375526798.jar (deleted)
java 2962 web 168w REG 202,80 0 1969499 /data/web/mls/data/jobs/mls_91/builds/590/23.log (deleted)
java 2962 web 325w REG 202,80 0 6455947 /data/web/mls/data/jobs/mls_39/builds/1080/10.log (deleted)
java 2962 web 341w REG 202,80 0 1975873 /data/web/mls/data/jobs/mls_113/builds/1054/29.log (deleted)
java 2962 web 347w REG 202,80 0 2506849 /data/web/mls/data/jobs/mls_59/builds/.1073/21.log (deleted)
java 2962 web 350w REG 202,80 8192 1975877 /data/web/mls/data/jobs/mls_113/builds/1054/31.log (deleted)
java 2962 web 352w REG 202,80 0 5387403 /data/web/mls/data/jobs/mls_80/builds/505/23.log (deleted)
java 2962 web 354w REG 202,80 0 3422611 /data/web/mls/data/jobs/mls_29/builds/.385/23.log (deleted)3.メモリの漏洩が発生した上記のプロセスを再起動し、ディスク使用量が正常な状態に戻ったことを確認します.
[ec2-user@awsuw7-46 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 100G 17G 84G 17% /
devtmpfs 30G 0 30G 0% /dev
tmpfs 29G 0 29G 0% /dev/shm
tmpfs 29G 2.7G 27G 10% /run
tmpfs 29G 0 29G 0% /sys/fs/cgroup
/dev/xvdf 246G 128G 106G 55% /data
tmpfs 5.8G 0 5.8G 0% /run/user/1000
tmpfs 5.8G 0 5.8G 0% /run/user/1003
tmpfs 5.8G 0 5.8G 0% /run/user/1005
tmpfs 5.8G 0 5.8G 0% /run/user/1008
tmpfs 5.8G 0 5.8G 0% /run/user/1007
tmpfs 5.8G 0 5.8G 0% /run/user/1006その後、同僚と確認したところ、確かにタイミングスクリプトを書いてこのプロセスで発生したファイルを整理し、定期的にrmを削除していることが確認され、プロセスにハンドルが漏れることになります.
関連リンク:
https://www.cnblogs.com/heyonggang/p/3644736.html http://www.eygle.com/archives/2009/10/linux_unix_file_handle_deleted.html