Last update: Saturday, 04-Jun-2011 17:28:54 JST |
_ ふとしたことから録画鯖の同時録画ストリームベンチ。5ストリーム同時で更に外部からネットワーク経由コピーなどの負荷がかかると稀にパケットドロップが認められる・・・CPUは超よゆー、ディスクパフォーマンスはまだなんとかなりそうだし、メモリ上に一時溜め込んでおく手段もあるだろうから、ちょっと弱くないかな・・・。
_ ・・・と、ふとディスクそのもののベンチをとってみた・・・128MBでリード70MB/s・ライト30MB/sとか、RAID0なのに遅すぎるなーと思ったら・・・Intel Matrixドライバを入れ忘れていることに今頃気づいた罠。そりゃいかんわー(苦笑)。
_ ドライバ入れて、UPS付いてるからライトバックキャッシュも問題なかろうということでON。リード・ライトとも170MB/s。めでたし。
_
ああ、あとちょっとだけメインPCの位置替え。生暖かい排気を食らわなくて済むように。
_ 最初から分かってはいたがやはり気になってきたこと。同一フォルダ(ドライブ)に複数のRecTestで録画ストリームが同時に書き込まれると、それらが出力する内容はちょっとずつ細切れになるため、運が悪いと思いっきり断片化状態になる。*1
*1: 複数のストリームが隣接してしまうことがあまりないようにファイルシステムが調整しているはずなので、必ず発生するというわけでもない。ただ、空き容量が減ってくれば効果は落ちるし、それがすでに断片化が進んでいるドライブなら、わりと遭遇する事態ではある。
_ 対策としてクラスタサイズは64KBに拡げてあって、おまけにRAID0なので書き込み速度上は問題ない。そもそもRecTest自体も書き込みが2MBずつ(初期値)なので、極端にパフォーマンスが落ちるような断片化は起こらないのだが、それでも精神衛生上あまりよろしくない。
_ ということで改善を試みる。動作試験2時間くらいだから信用しちゃいかんよ(苦笑)。
_ やってることは簡単で、書き出すときにSetEndOfFile()で先に1GBずつディスク領域を確保しちゃって、後からそこを埋めるように書き込む方式にしているだけ。原理上はRecTestの書き込み単位を拡げれば同等の効果はあるはずだが、拡げると消費メモリは増えるし書き込みスレッドの粒度が荒くなってパフォーマンスに何か影響を及ぼすかもしれないのに比べれば、こちらの方式のほうがずっとマシなはず。
メールはこちらへ...[後藤浩昭 / Hiroaki GOTO / GORRY / gorry@hauN.org]