web-dev-qa-db-ja.com

ほとんど使用されていませんが、tmpfsがいっぱいになります。これをデバッグするにはどうすればよいですか

Tmpfsに/があるシステムがあります。ほとんどの/サブディレクトリには、読み取り専用のベースファイルシステムで読み取り/書き込みルートファイルシステムをオーバーレイするaufsがマウントされています（システムは読み取り専用メディアから起動します）。以前は、aufsの代わりにunionfsを使用していました。最近tmpfsがいっぱいになり始めるまで、正常に動作していました。何が変化を引き起こしたのかわかりません。それは、aufsの変更、カーネルのアップグレード、またはシステムのいくつかの変更と、ファイルシステムへのアクセス方法に対するunionfsである可能性があります。

とにかく、どういうわけか間違った動作をするのはtmpfsのようです。

システムはtmpfsに多くを書き込むべきではありませんが、かなりの量が使い果たされています。

# df -m /
Filesystem     1M-blocks  Used Available Use% Mounted on
tmpfs                200    50       151  25% /

一方：

# du -smx /
2       /

これは私のテストシステムで、基本的に何もしていません。使用率がすぐに90％を超え、システムがクラッシュすると、本番システムで問題が発生します。

これらは削除されたファイルがまだ開いていると思われますが、次のようになります。

# lsof | grep deleted

何も表示されません。

もう1つのアイデアは、/上の一部のファイルが、その上にマウントされたファイルシステムによってマスクされるというものだったので、これを試しました。

# mount --bind / /mnt
# du -sm /mnt
2       /mnt

それでも、48MBの痕跡は失われていません。

Tmpfsファイルシステムを使い果たしているものを見つけるにはどうすればよいですか？

システムインフォメーション：

# uname -rm
3.4.6 i686

更新：カーネル3.4.17および3.6.6を試しました–変更はありません。

linuxtmpfsaufs
4
Jacek Konieczny

私はaufsのメンテナーである岡島淳二郎の助けを借りて、自分で謎を解きました。

問題をデバッグするための最初のステップは、制御された方法で問題を再現することでした。ファイルがaufsを介して書き込まれ、削除されるときに問題が発生することを見つけるのに少し時間がかかりました（今はなぜそんなに多いのだろうか）。

問題の再現

マウントポイントを作成します。

# cd /tmp
# mkdir rw
# mkdir mnt

tmpfsをマウントします。

# mount -t tmpfs none /tmp/rw

/ usrを/ tmp/rwでオーバーレイして、aufsをマウントします。

# mount -t aufs  -n -o "br:/tmp/rw:/usr" none "/tmp/mnt"

これで、/ tmp/mntの下に/ usrの内容が表示されます。

# ls /tmp/mnt
bin  games  include  lib  lib64  local  sbin  share  src

私が興味を持っているのは、以下のtmpfsの使用済み/使用可能なスペースです。

# du -sk /tmp/rw   
0   /tmp/rw
# df /tmp/rw  
Filesystem     1K-blocks  Used Available Use% Mounted on
none             1031128    24   1031104   1% /tmp/rw

/ tmp/rwにファイルはありませんが、24ブロックが割り当てられています。それでも大きな問題ではありません。

Aufsにファイルを書き込むことができます。ファイルは/ tmp/rwのtmpfsに保存されます。

# dd if=/dev/zero of=/tmp/mnt/test bs=1024 count=100
100+0 records in
100+0 records out
102400 bytes (102 kB) copied, 0.000343903 s, 298 MB/s
# du -sk /tmp/rw
100 /tmp/rw
# df /tmp/rw
Filesystem     1K-blocks  Used Available Use% Mounted on
none             1031128   128   1031000   1% /tmp/rw

使用統計がどのように変化したかに注意してください。 duは、予想どおり100kBが追加されたことを示していますが、df出力の「Used」値は104ブロック増加しました。

ファイルを削除すると：

# du -sk /tmp/rw   
0   /tmp/rw
# df /tmp/rw
Filesystem     1K-blocks  Used Available Use% Mounted on
none             1031128    28   1031100   1% /tmp/rw

4つのブロックが失われます。

ddコマンドとrmコマンドを数回繰り返すと、次のようになります。

# df /tmp/rw                                         
Filesystem     1K-blocks  Used Available Use% Mounted on
none             1031128    36   1031092   1% /tmp/rw

ますます多くのtmpfsブロックがなくなり、どこにあるのかわかりませんでした…

私が同じことをしたところ– ddとrmを/ tmp/rwで直接、この方法で何も失われませんでした。そして、aufsをアンマウントした後、tmpfsで失われたスペースが回復されました。したがって、少なくとも、責任を負うのはtmpfsではなくaufsであることがわかりました。

何が起こっているのか

何が原因かを知っていたので、aufs-usersメーリングリストに自分の問題を説明しました。私はすぐに最初の答えを受け取りました。 J。R. Okajimaのもの 欠落しているtmpfsブロックに何が起こっているのかを説明するのに役立ちました。

確かに削除されたファイルでした。ファイルがユーザースペースプロセスによって開かれたり、mmapされたりしなかったため、lsofまたは/proc/<pid>/*のどこにも表示されませんでした。ファイル「xinoファイル」は、aufsの外部iノード番号変換テーブルであり、カーネルaufsモジュールによって内部的に使用されます。

ファイルへのパスはsysfsから読み取ることができます：

# cat /sys/fs/aufs/si_*/xi_path         
/tmp/rw/.aufs.xino

ただし、ファイルが削除されると、直接表示することはできません。

# ls -l /tmp/rw/.aufs.xino
ls: cannot access /tmp/rw/.aufs.xino: No such file or directory

ただし、そのサイズと他の特別なaufsファイルのサイズに関する情報はdebugfsから読み取ることができます。

# for f in /sys/kernel/debug/aufs/si_8c8d888a/* ; do echo -n "$f: " ; cat $f ; done 
/sys/kernel/debug/aufs/si_8c8d888a/xi0: 1, 32x4096 132416
/sys/kernel/debug/aufs/si_8c8d888a/xi1: 1, 24x4096 626868
/sys/kernel/debug/aufs/si_8c8d888a/xib: 8x4096 4096
/sys/kernel/debug/aufs/si_8c8d888a/xigen: 8x4096 88

詳細は aufsのマニュアルページ で説明されています。

ソリューション

'xinoファイル'は、次の方法で手動で切り捨てることができます。

# mount -o remount,itrunc_xino=0 /tmp/mnt

自動xinoファイルの切り捨ては、aufsのマウント中にtrunc_xinoオプションを使用して要求できます。

# mount -t aufs -n -o "br:/tmp/rw:/usr,trunc_xino" none "/tmp/mnt"

それがファイルシステムのパフォーマンスにどのように影響するのか、またはこれが本番環境でのtmpfsスペース不足の問題を本当に解決するのかどうかはまだわかりませんが、多くのことを学びました。

10
Jacek Konieczny

これは、ファイルが削除されたが、プロセスがファイルを保持している場合に発生することを確認しました。これは、プロセスが再起動されるまでスペースが解放されなかったことを意味します。私はこれをApacheログファイルで見ました。削除されたログファイルへの書き込みを継続しているようで、再起動するまでスペースはクリアされませんでした。

削除されたファイルを保持している可能性のあるプロセスを見つけるには、各プロセスを再起動して、スペースがクリアされるかどうかを確認してください。もしそうなら、あなたはあなたの犯人を見つけました。

HTH

1
drone.ah