restore の最大のボトルネック2007年05月29日 12時37分57秒

restore もファイル数が多くなると大変だ。

ファイルを元に戻す為のプログラムなので、I/O の性能が良い方が作業が速いに決まっている。しかし、ファイル数が増えてくると、ディスクの性能よりもメモリの方が大切になる。

restore はまず、ディレクトリを最初に作る。全てのディレクトリを作った後に、ファイルを全て作る。その作業が切り替わる時にソートが行われるみたいなのだ。

推測を確かめるにはソースを見た方がいいのだろう。しかし、ソースを見ても、今すぐに取らないといけない対策が変わるわけでもないので、見てはいない。

ディレクトリを生成している間、restore の占有メモリはどんどん増えていく。作ったディレクトリの名前を保持しているかのようだ。そして、 大量のファイルを restore するのに、メモリの量が少ないと少しずつをスワップに書き出し始める。そして、ディレクトリを作り終わったあたりで、急にスワップインとスワップアウトを繰り返すようになるのだ。見た感じだと、restore のほぼ全てのメモリが入れ替わり立ち替わり、出入りしているようだ。

もし、この時点でスワップの暴風雨が暴れているのであれば、ここで一番時間を食い潰す可能性は大だ。I/O の性能を犠牲にすることになってもメモリの多い計算機で、作業してから付け直すか、メモリの増設を考えた方がいい。

恐らく三万から四万ファイルぐらいはあっただろう。I/O が遅いがメモリの多いノートの方が、I/O は速いがメモリが少ないデスクトップの方が実際に速かった。でs久トップ機は 256MB と少ないメモリのせいか、ディレクトリを作っている最中からスワップに勤しんでいた。スワップの嵐が来たときに、出口がまったく期待出来そうも無かったので、諦めたぐらいだった。

コメント

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※なお、送られたコメントはブログの管理者が確認するまで公開されません。

名前:
メールアドレス:
URL:
コメント:

トラックバック

このエントリのトラックバックURL: http://uyota.asablo.jp/blog/2007/05/29/1540949/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。