何がどういったことをしているのか(どこかのプロセスがどんなファイルを作成しようとしているとか)を調べる手段を教えてください。
今回では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
No.5
94
16
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
とありますね。
再起動してしまうと内容が消えるのは、まあ当然でしたね。
私も勘違いしていたかもしれないです。申し訳ない。
No.1
48079
18pt
MySQLは大容量の隠し一時ファイルを作るから、とりあえずテンポラリはHDD上に設定するほうがいいね
とりあえずの次の対応はクエリの見直し（WHEREで条件を極力絞るなどしてORDER BYやGROUP BYで大量のデータを扱わないようにすれば一時ファイルの容量は抑えられるし、結果として応答性もあがる）だね
>MySQLは大容量の隠し一時ファイルを作るから、とりあえずテンポラリはHDD上に設定するほうがいいね
隠しファイルを作るというのは初めて聞きました。そしてその隠しファイルを調べる方法を質問したつもりでした。
No.2
9416
17pt
.snapの下はどうなんでしょうか。
cd //usr/loca/tmp ls -laR du df -i
などの結果があるといいかと思います。
iノードが足りないのとは違う気もしますが、duと.snapの下は見ておいてもいいかと。
今は調べることはできませんが、問題発生時に行ったdf -iは問題がなく、.snap以下にファイルもありませんでした。\
duでも確か(-hをつけない状態で)4と出力されていたと記憶します。
No.3
34220
>さて、時は流れまして、Linux カーネル 2.6.13 で、新たに inotify という監視機構が組み込まれました。
魅力的な機能で是非試してみたいところですが、使用中のOSはFreeBSDです。
No.4
48079
17pt
>隠しファイルを調べる方法
MySQLユーザーかrootから以下のコマンドで隠しファイルも表示されるはずだけど、ファイルの存在を確認したところで、触ることはできないと思うよ（MySQLを停止させた状態でファイルを消すなどはできるけど、多分、他のデーモンのテンポラリにも設定してるんじゃない？）
ls -a
残念ながら質問の意図から外れています。
ls -aはドットで始まる隠しファイルを表示するコマンドと認識しています。
質問文中に書いたls -latの結果から対象ディレクトリ直下には.snap以外ににファイルが見つからないと見受けます。
また通常mysqlのtmpdirには#sqlといった文字列で始まるテンポラリテーブルのファイルがtmpdir直下に作成されます。
先の回答では質問内容を受けて、このファイル以外でlsしても見えない隠しファイルがあるのかと思いました。
またこれらのファイルが見当たらないのにfile system is fullとなってしまう、その原因調査をしたいというのが質問内容です。
通常の動作ですとmysqldを落とした段階でテンポラリテーブルのファイルは消えます。
他のデーモンのテンポラリには指定していません。
No.5
9416
ここでベストアンサー
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
とありますね。
再起動してしまうと内容が消えるのは、まあ当然でしたね。
私も勘違いしていたかもしれないです。申し訳ない。
マニュアルでディスクフル時の動作に言及されているとは知りませんでした。
書き損ねましたが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の組み合わせ固有で起こりうる問題だったりする可能性を捨てきれなかったのです。
No.6
137254
17pt
ありがちなのは、ルート以下に巨大なダンプファイルができてる。swapファイルがたくさんできて、削除されないまま放置されている。/var/vmとか。とにかく巨大なファイルを探すことです。find のオプションで指定できます。http://www
ルートなどはスライスで区切ってあります。
OSから生成されるswapは専用のパーティションがあります。
今回の問題はmomory device以下がいっぱいになることです。
巨大なファイルを探したいのですがそれが見つからないので質問した次第です。
No.8
29137
10pt
あるファイルを削除したけど、削除以前からそのファイルをオープンしたままのプロセスがある場合に、ls などで見えるファイルとしては存在しない何かがディスク領域を利用し続けるケースがあります。
/usr/local/tmp にファイルを作りそうなプロセスを終了してみて、df で空き容量が増えるのが確認できれば、そのプロセスが犯人・・といった感じの切り分けは可能かと思います。あとはそのプロセスがつかんでいるファイルを lsof などで調査・・という感じでいかがでしょうか。
ど
2010/06/23 17:56:12
2
2
2
1
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の組み合わせ固有で起こりうる問題だったりする可能性を捨てきれなかったのです。