ファイルが存在しないように見えるのに、FreeBSDのramディスク(md)が file system is fullとなってしまいます。

何がどういったことをしているのか(どこかのプロセスがどんなファイルを作成しようとしているとか)を調べる手段を教えてください。
今回ではmysqlで大量のデータを流し込み、そのtmpdirがmdでした。どんなテンポラリファイルが原因で詰まったのか、と調査しようとしたのですが上記の現象になり困りました。
よろしくおねがいします。

FreeBSD 7.3-RELEASE amd64
%ls -lat
total 6
drwxrwxrwt 3 root wheel 512 Jun 22 10:47 ./
drwxrwxr-x 2 root operator 512 Jun 22 10:46 .snap/
drwxr-xr-x 16 root wheel 512 Jun 22 09:50 ../
%df -h | grep md
/dev/md2 3.9G 3.5G 16M 100% /usr/local/tmp

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2010/06/22 12:01:22
  • 終了:2010/06/29 12:05:02

ベストアンサー

id:doropon No.5

回答回数94ベストアンサー獲得回数162010/06/22 18:17:17

ポイント17pt

v4.1なんですが、

http://dev.mysql.com/doc/refman/4.1/ja/temporary-files.html

http://dev.mysql.com/doc/refman/4.1/ja/full-disk.html

とありますね。

再起動してしまうと内容が消えるのは、まあ当然でしたね。

私も勘違いしていたかもしれないです。申し訳ない。

id:Yousan_O

マニュアルでディスクフル時の動作に言及されているとは知りませんでした。

書き損ねましたがmysqlは5.1を使用しています。4.1との差異は10分ごとに警告を発することらしいですね。

再起動などはしておらず、mysql -f < data.sql (エラーを無視してコマンド続行)でデータを流し込んでいる裏で、mdがフルになり、dfではいっぱいにみえるけどファイルは見えない、という状況です。

再現性があり、データを流し込んでいる状況でdfすると徐々にmdの空き容量が減っていきます。その間、一切のファイルは見当たりません。

(この辺の状況が後出しでごめんなさい)

今回の質問はOS側で、なんらか理由でfile system is fullと言われる原因について知りたいです。

わかりにくかったかもしれませんが質問文中にある"file system is full"はOSから発せられたエラーです。

個人的にはmysqlが今回の問題に関わっているとはあまり思っていません。

ただ先の回答でいただいたような、"mysqlは隠しファイルを作成する"といったos+softの組み合わせ固有で起こりうる問題だったりする可能性を捨てきれなかったのです。

2010/06/23 12:07:13

その他の回答(7件)

id:koriki-kozou No.1

koriki-kozou回答回数480ベストアンサー獲得回数792010/06/22 12:37:40

ポイント18pt

MySQLは大容量の隠し一時ファイルを作るから、とりあえずテンポラリはHDD上に設定するほうがいいね

とりあえずの次の対応はクエリの見直し(WHEREで条件を極力絞るなどしてORDER BYやGROUP BYで大量のデータを扱わないようにすれば一時ファイルの容量は抑えられるし、結果として応答性もあがる)だね

id:Yousan_O

>MySQLは大容量の隠し一時ファイルを作るから、とりあえずテンポラリはHDD上に設定するほうがいいね

隠しファイルを作るというのは初めて聞きました。そしてその隠しファイルを調べる方法を質問したつもりでした。

2010/06/22 17:21:17
id:doropon No.2

回答回数94ベストアンサー獲得回数162010/06/22 12:48:59

ポイント17pt

.snapの下はどうなんでしょうか。

cd //usr/loca/tmp
ls -laR
du
df -i

などの結果があるといいかと思います。

iノードが足りないのとは違う気もしますが、duと.snapの下は見ておいてもいいかと。

id:Yousan_O

今は調べることはできませんが、問題発生時に行ったdf -iは問題がなく、.snap以下にファイルもありませんでした。\

duでも確か(-hをつけない状態で)4と出力されていたと記憶します。

2010/06/22 17:43:28
id:koriki-WeKan No.3

koriki-WeKan回答回数342ベストアンサー獲得回数202010/06/22 14:24:31

ポイント17pt

inotifywatchを使って監視する。

http://www.usupi.org/sysad/157.html

id:Yousan_O

>さて、時は流れまして、Linux カーネル 2.6.13 で、新たに inotify という監視機構が組み込まれました。

魅力的な機能で是非試してみたいところですが、使用中のOSはFreeBSDです。

2010/06/22 17:35:05
id:koriki-kozou No.4

koriki-kozou回答回数480ベストアンサー獲得回数792010/06/22 18:03:27

ポイント17pt

>隠しファイルを調べる方法

MySQLユーザーかrootから以下のコマンドで隠しファイルも表示されるはずだけど、ファイルの存在を確認したところで、触ることはできないと思うよ(MySQLを停止させた状態でファイルを消すなどはできるけど、多分、他のデーモンのテンポラリにも設定してるんじゃない?)

ls -a
id:Yousan_O

残念ながら質問の意図から外れています。

ls -aはドットで始まる隠しファイルを表示するコマンドと認識しています。

質問文中に書いたls -latの結果から対象ディレクトリ直下には.snap以外ににファイルが見つからないと見受けます。

また通常mysqlのtmpdirには#sqlといった文字列で始まるテンポラリテーブルのファイルがtmpdir直下に作成されます。

先の回答では質問内容を受けて、このファイル以外でlsしても見えない隠しファイルがあるのかと思いました。

またこれらのファイルが見当たらないのにfile system is fullとなってしまう、その原因調査をしたいというのが質問内容です。

通常の動作ですとmysqldを落とした段階でテンポラリテーブルのファイルは消えます。

他のデーモンのテンポラリには指定していません。

2010/06/22 18:35:09
id:doropon No.5

回答回数94ベストアンサー獲得回数162010/06/22 18:17:17ここでベストアンサー

ポイント17pt

v4.1なんですが、

http://dev.mysql.com/doc/refman/4.1/ja/temporary-files.html

http://dev.mysql.com/doc/refman/4.1/ja/full-disk.html

とありますね。

再起動してしまうと内容が消えるのは、まあ当然でしたね。

私も勘違いしていたかもしれないです。申し訳ない。

id:Yousan_O

マニュアルでディスクフル時の動作に言及されているとは知りませんでした。

書き損ねましたがmysqlは5.1を使用しています。4.1との差異は10分ごとに警告を発することらしいですね。

再起動などはしておらず、mysql -f < data.sql (エラーを無視してコマンド続行)でデータを流し込んでいる裏で、mdがフルになり、dfではいっぱいにみえるけどファイルは見えない、という状況です。

再現性があり、データを流し込んでいる状況でdfすると徐々にmdの空き容量が減っていきます。その間、一切のファイルは見当たりません。

(この辺の状況が後出しでごめんなさい)

今回の質問はOS側で、なんらか理由でfile system is fullと言われる原因について知りたいです。

わかりにくかったかもしれませんが質問文中にある"file system is full"はOSから発せられたエラーです。

個人的にはmysqlが今回の問題に関わっているとはあまり思っていません。

ただ先の回答でいただいたような、"mysqlは隠しファイルを作成する"といったos+softの組み合わせ固有で起こりうる問題だったりする可能性を捨てきれなかったのです。

2010/06/23 12:07:13
id:kick_m No.6

kick_m回答回数1372ベストアンサー獲得回数542010/06/22 22:55:27

ポイント17pt

ありがちなのは、ルート以下に巨大なダンプファイルができてる。swapファイルがたくさんできて、削除されないまま放置されている。/var/vmとか。とにかく巨大なファイルを探すことです。find のオプションで指定できます。http://www

id:Yousan_O

ルートなどはスライスで区切ってあります。

OSから生成されるswapは専用のパーティションがあります。

今回の問題はmomory device以下がいっぱいになることです。

巨大なファイルを探したいのですがそれが見つからないので質問した次第です。

2010/06/23 11:54:13
id:kick_m No.7

kick_m回答回数1372ベストアンサー獲得回数542010/06/23 23:14:20

ポイント17pt

findのオプションで指定、検索できます。

id:Yousan_O

lsしても見つからないファイルはどういったオプションで見つかるのでしょうか?

2010/06/24 06:20:15
id:toohigh No.8

toohigh回答回数291ベストアンサー獲得回数372010/06/26 20:33:45

ポイント10pt

あるファイルを削除したけど、削除以前からそのファイルをオープンしたままのプロセスがある場合に、ls などで見えるファイルとしては存在しない何かがディスク領域を利用し続けるケースがあります。


/usr/local/tmp にファイルを作りそうなプロセスを終了してみて、df で空き容量が増えるのが確認できれば、そのプロセスが犯人・・といった感じの切り分けは可能かと思います。あとはそのプロセスがつかんでいるファイルを lsof などで調査・・という感じでいかがでしょうか。

  • id:doropon
    難しいですね。FreeBSDであればkqueueを使ってファイルシステムをモニタすることもできるんじゃないかなとは、
    思いますが、簡単にできるものでもありませんし。
    MySQLのテンポラリファイルの可能性もありますが、特定できないと意味が無いですものね。
    MySQLのエラーログがどこまで詳細に取れるのか。
    あとは再現できるのか。
    でしょうか。
    あ、パンパンになってきている状態であれば、lsofで開いているファイルを見ることができる気がします。
    役に立たずすんません。
  • id:Yousan_O
    そうですね。kqueueを使ったコードを自分で書く元気は無いです。
    実はある程度原因に予測を付けてるのです。
    おそらくmysql側ででかいファイルを作ろうとOSに要求を出して、それを受け取ったOSが実際にファイルに書く前に領域を確保しようとしてる、そんでその情報がfat?のようなところで見えるのでdfだと確かに容量が減ってて、osは警告を流す。
    という妄想です。あたかも通販サイトでカートに入れたら在庫から引き出し処理を行ってるような、実際に購入までいってないから購入したという情報はありません、という状況じゃないかな、と。

    残念ながらあまりunix/freebsdに長けている訳ではないのでその辺の処理がよくわかんない、のが現状です。
    mysqlで流してるデータは一通り把握してて、tmpdirを利用するようなクエリは入ってない*はず*なのです。おそらくそれが間違いなのでしょうけれど、そこの原因を突き止めたく、どんなファイルを作ろうとしているのかわかれば最高、という感じです。#mysqlhogehoge.MYIとかが見えちゃったりしたら強制的に抜き出して生きてるmysqlに突っ込んで中身見たりできるかなとか妄想を抱いています。

    lsofですか!さくっとほかのホストで使ってみたらこれぞ答えな気がします。
    再現性はありますのでこれで試してみようと思います。これでファイルつかもうとしてる現場を押さえられればスッキリします。
  • id:Yousan_O
    ちょうど稼働中のサーバが不運・幸運にもダウンすることになったのでlsofをしてみました。
    mysqlがしっかりファイルを握ろうとしていました。
    ばっちりこれでmysqlが握ろうとしていることがわかりました。

    色々な回答ありがとうございました。
  • id:doropon
    おお、見つかりましたか。
    良かったか、どうかってのは、
    まあ言えないですが、
    今後の運用の問題の一つが明確になってよかったかなと。勝手に思ってます。
    あとは、mysqlが必要とする一時ファイルなりの容量を正確に見積もれればいいんだろうなと。
    テーブルのサイズ、インデックスのサイズ、SQLの書き方でも変わってきそうなのでソースを読んでも最低このくらいってぐらいしかわからなそうではありますが。
    一番動作が重くなるところなので、チューニングしたいと思いますね。
    自分ももっとmysqlの中身を知ろうと思います。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません