ページキャッシュは、そこそこのサイズが良い

ファイルシステムのページキャッシュがデカいと、ダーティーキャッシュをディスクにライトバックするのに時間がかかるので、その間に謎のエラーが出まくるのだ。 …という口伝のまとめ。
4
こなみひでお @konamih

メモリ使用の流儀が量的だけではなく質的にも変わってきたのだなあ

2010-08-18 02:29:56
M. Watanabe @labidochromis

@konamih 動的確保&ガベージコレクションが普通になってきてるし。昔のBASICもそうだったけど。 > メモリ使用の流儀が量的だけではなく質的にも変わってきたのだなあ

2010-08-18 10:04:34
M. Watanabe @labidochromis

N88BASICで計測器を制御するプログラムを書いて、ガベージコレクションで時折秒単位で止まられるのは困るのでガベージコレクションを誘発する文(文字列変数に空文字列を代入、だったかなぁ?)を入れて強制的にこまめにガベージコレクションさせたものだ。

2010-08-18 10:34:18
M. Watanabe @labidochromis

メモリを大量に搭載したLinuxマシンではファイルシステムのページキャッシュが実メモリを埋め尽くすとそれをライトバックするまで数秒(下手をすると数分)間メモリが確保できず停止状態になる事があって、ライトバック開始サイズを小さめに設定しないといろいろ問題が起きる。

2010-08-18 10:41:43
M. Watanabe @labidochromis

例えばあるプロセスがロックファイルを作成しても、メモリが確保されてページキャッシュ上にコピーされるまでの間はそのファイルの情報はそのプロセスからの出力バッファ上にあるだけでファイルとして見える状態では存在していない。なのでロック制御はうまく働かない。

2010-08-18 10:46:18
M. Watanabe @labidochromis

「touch abc; ls abc」を実行すると「ls: cannot access abc: No such file or directory」になったりするのだ。

2010-08-18 10:49:49
M. Watanabe @labidochromis

ファイルの存在を確認する前に sync して sleep したりもしたものの、何秒スリープすれば確実と言う事もないし。

2010-08-18 10:53:24
M. Watanabe @labidochromis

ファイル名の変更はページキャッシュを使用しないので、あらかじめ作っておいたファイルを mv する事でロックファイルとして使うと言う手はよく使った。「mv hoge.unlocked hoge.locked」でロック状態に以降、みたいに。

2010-08-18 10:55:28
M. Watanabe @labidochromis

プロセス間でのデータのやり取りに「ファイルの中身」を使うのもその問題のせいでうまくいかない。書き換え中にロックファイルを作る(mvしてロック中なファイル名にする)などしても、実際に中身が書き換わるのは数十秒後だったりする。

2010-08-18 11:00:33
M. Watanabe @labidochromis

なので、ファイル名で情報をやり取りすると言う手もよく使った。「mv message.0 message.1.S=1:A=312:C=124」みたいな感じで。

2010-08-18 11:04:13
こなみひでお @konamih

@labidochromis そういうのは首をひねりますね.> touch abc; ls abc」を実行すると「ls: cannot access abc: No such file or directory」

2010-08-18 11:06:35
M. Watanabe @labidochromis

プロセス間通信を使うと言う手もあるけど、非同期的に動く場合や受け手が複数ある場合なんかにはプロセス間通信ではやりにくい。

2010-08-18 11:07:40
M. Watanabe @labidochromis

vi で作ったテキストを保存してから終了して、ls してみると無い。あれ?と思いつつトイレに行って帰ってきたらある。みたいな事が起きる。メモリが64GBも載ってるとディスクへのライトバックはそりゃ大変なもんです。

2010-08-18 11:11:07
M. Watanabe @labidochromis

キャッシュメモリは大きければ大きいほど動作が軽くなると思ってはいけない。

2010-08-18 11:12:04
M. Watanabe @labidochromis

設定ファイルを書き換えてサーバープログラムを kill -HUP してもうまくいかなくて reboot したら正常に動作、なんて事の原因にもなる。

2010-08-18 11:20:13
M. Watanabe @labidochromis

クリーンなキャッシュ(ライトバック済みのキャッシュ)は即座に開放できるので、この問題の原因になるのはダーティーなキャッシュだけ。

2010-08-18 11:21:54
M. Watanabe @labidochromis

ライトバックキャッシュはデバイスへのアクセスが不連続にならない最小限の容量があればそれ以上は不要なのでライトバック開始サイズはある程度小さく設定しても性能に悪影響はない。

2010-08-18 11:26:48
M. Watanabe @labidochromis

/etc/sysctl.conf で vm.dirty_ratio と vm.dirty_background_ratio (特に前者が重要)を小さめに設定してしまえば良いのだ。

2010-08-18 11:28:16
M. Watanabe @labidochromis

ただし、この設定はハードディスクのみならずCD-RやDVD-Rなんかにも影響するので、あまり小さくするとDVDを焼いている最中にバッファアンダーランが発生したりするのでほどほどにしなければいけない。

2010-08-18 11:30:26
大' @satodainu

ライトバックのサイズって、そんなとこに設定があったのか。 QT @labidochromis: /etc/sysctl.conf で vm.dirty_ratio と vm.dirty_background_ratio (特に前者が重要)を小さめに設定してしまえば良いのだ。

2010-08-18 11:30:46
M. Watanabe @labidochromis

データをディスクに書き戻さずにメモリ上に貯めておくためにデータベースエンジンがスワップアウトされるとか、面白いことが起きるのだ。

2010-08-18 11:33:47
M. Watanabe @labidochromis

サーバが時々応答しなくなるからメモリを増設してみたらさらに悪化、なんて事にもなる。

2010-08-18 11:35:08
M. Watanabe @labidochromis

というわけで、vm.dirty_ratio は Linux の重要なチューニング項目だ!

2010-08-18 11:36:13
M. Watanabe @labidochromis

@konamih 数年前までハードウェアメーカーの開発の人でしたから。 > 64 GB って何のマシンですか?

2010-08-18 11:37:57
1 ・・ 4 次へ