読者です 読者をやめる 読者になる 読者になる

squid2.6のCOSSの話(その2)

squid2.6のCOSSの話の続き

COSSのパフォーマンスのよさに関して「俺だまされてない?」というモヤモヤ感が高かったんだけど,あちこちの方々と議論した結果これが正解だろうという結論に行き着いた.


ありがとう!>あちこちの方


友人との会話.

yamaz: おっすおっす。いる?
xxxxx: お久しぶりです!
yamaz: squid2.6のCOSSって知ってる?
xxxxx: 初耳です。<COSS
yamaz: http://blog.nomadscafe.jp/archives/000705.html
yamaz: http://wiki.squid-cache.org/SquidFaq/CyclicObjectStorageSystem
yamaz: このあたりの話なんだけど、
yamaz: なぜコレが速いかっていう見解って持ってる?
xxxxx : 3年ぐらい前、apacheをプロファイリングしたら、select()の次にopen()がコストを食ってました。で、そのときは、open("/home/xxxx/hoge/hoge/hoge.gif") とかしたとき、/home, /home/xxxx,...のディレクトリファイルを読みに行って、そこでDISK IOが詰まってるんじゃないか?と思ってました。
yamaz : なかなか説得力あるなw


ぴろさんとの会話

ぴろさん: それは一般的なrawデバイス使うメリットだよね
yamaz: そうですね。
ぴろさん: open()/stat()は激遅いので、なるべく使わないですむようにするのは基本じゃね?w
ぴろさん: Squidあんまりしらないんだけど、他のストレージ形式は
ぴろさん: オブジェクトごとに1ファイルなの?
yamaz: apacheのmod_proxyはそうですね。
ぴろさん: それはフツーに最悪だと思う
yamaz: squid2.5も1オブジェクト1ファイル
ぴろさん: ディレクトリエントリの検索だけで、オブジェクト数増えたらシャレにならん
yamaz: それでもメモリに載ってる分には速いと思ってたんですが、実はそうでもないくらいopen/statは遅いってのがCOSSの出発点なのかも知れないですね。

selectが遅いのはともかくopenが遅いのは私にとっては結構意外で,この話を元に下記の実験をしてみた.


1. open/closeは1回だけ
open(2KB) + (read 2k + rewind) x 1000万回 + close
3.65s user 26.89s system 99% cpu 30.605 total


2. open/closeを繰り返し
(open + read 2k + close) x 1000万回
6.11s user 79.89s system 99% cpu 1:26.17 total


3. メモリに載るファイルサイズでCOSSもどき
open(0.5GB) + (ramdom lseek + read 8k) x 1000万回 + close
4.50s user 35.25s system 99% cpu 39.839 total


4. メモリに載らないファイルサイズでCOSSもどき
open(8GB) + (random lseek + read 8k) x 1000万回 + closes
戻ってこなかったので中断.


5. メモリに載らないファイルサイズだけど,アクセスする場所を
メモリに載る程度に絞ってCOSSもどき.
6.00s user 271.49s system 66% cpu 6:54.40 total


これらの結果から類推すると下記のような考察ができる.

  1. open/closeのコストはやっぱり高い
  2. バッファキャッシュにのらないと(ディスクにアクセスにいくため)やっぱり遅い
  3. mod_proxyは1キャッシュURLに対して1ファイルを消費するという実装になっている一方でCOSSはopen/closeのコストがないので,キャッシュ量が同じならCOSSの方が速そう.
  4. open/closeのコストは比較的バカにできないので、そこで稼げた分だけディスクに多少余分にアクセスがあってもいいのかもしれない.
  5. なので、あまりにキャッシュヒットが悪いケースではCOSSもやっぱり遅そう
  6. 実験5が実験4と比べて非常に遅いのは,lseekがランダムでブロックサイズにあわせたアクセスになってないとかそういう理由が考えられる.なので、ここは改善の余地がありそう(というかそれこそがCOSSがやってることだ).


上記実験は非常に単純なものなので,さらなる考察は必要だと思うが,これなら感覚的にも納得ができる.


COSSはいつキャッシュがあふれて遅くなるのかが読みにくいので,ちょっと癖がある感じだが,なぜ速いかの理由がわかったので,うまく使えばよさそうというのがわかってよかった.

(おしまい)

あわせて読みたい

Write Great Code〈Vol.1〉ハードウェアを知り、ソフトウェアを書く

Write Great Code〈Vol.1〉ハードウェアを知り、ソフトウェアを書く

この本はあちこちで紹介されているので,私から言うことは特にはないが,本エントリを書くにあたってメモリシステムとメモリのキャッシュシステムに関する章はものすごく参考になった.本書を読んだ上でハードディスクを無茶苦茶遅いメモリととらえて本エントリを読み直せば,より一層理解が深まると思う.


ちなみに上記章群は「メモリアクセスはとーっても遅いので,できるだけL1,L2キャッシュに乗るようにコンパイラのはき出すアセンブラのメモリレイアウトを意識してコードを書きましょう」という感じで,いまどきのLLなプログラマを完全においてけぼりにしてるとしか思えないスタンスで書かれている.そういう意味でも本Blogの読者の方々にはオススメ.


ファイル構造

ファイル構造

一昔前のファイルシステム(UFSとかext2?)の実装に関する本なので,おすすめ度は中くらい.


yamaz的日常

Greeの勉強会を聞いてきた.

今回は鵜飼さんによるプログラムがmainにたどり着くまでだった.


PICのアセンブラ的なイディオムやint 0x80付近をシステムコールへのジャンプと解釈してシステムコールすらフックするテクがあるみたいな話とか聞けてなかなかおもしろかった.


最近OS系とアセンブラのあたりの話や書籍とかが増えてきててなかなかいい傾向だと思う.こことかみたいに次はもう一段上のシステムコールの具体的な実装に関する書籍のブームがおきないかなぁと思ったり.


ちょっと即発されてひさびさにFreeBSDのソースを追ってみた.selectの実装が知ってたのと全然違っててびっくり.