過去の記事: 2008年 3 月 1日

『シムエントリ』ご利用の皆様へお知らせです。

■処理速度を改善いたしました
1回の処理時間が最大10分の1程度、時間にして12,000エントリで1.5時間になりました(以前は12時間以上かかっていました)。
そのため、リリース直後時点以上に早く表示できるようになりました。
処理速度については皆様から様々なお話を頂戴しております。引き続き、最優先課題として改善を進めております。

■類似度計算時の閾値 再変更
スコアの範囲を 0.5 ＜ cos ＜ 1 の範囲に変更いたしました。
前回のお知らせで、スコアが0.1未満のエントリを切り捨てる処理を入れましたが、出てくるエントリ数があまりに減ってしまったために少し甘くしました。

【皆様へ】
コメント、トラックバック、そしてブログ上で様々なご意見を頂戴しております。
どうもありがとうございます。
進捗は引き続きこのブログで行っていきますので、どうぞよろしくお願いします。

そして、改善案を直接指南いただいたSさん、ありがとうございました！

【細かい話】
■処理別 最適化結果
RSS: 25分/12,000エントリ (以前は 約1時間/11,000エントリ)
計算: 1時間/12,000エントリ (以前は 約11時間/11,000エントリ)

■I/Oの問題
実計算よりもデータのI/Oに大きなコストがかかっていることがわかりました。
そこで、計算については極力I/Oが発生しない処理に最適化することで、速度が向上しています。
また、RSS取得処理についてはマルチスレッド処理にすることで速度を上げています。
アルゴリズム最適化やクラスタリングによる計算機容量の増強の前に、このあたりをどうにかしないといけなさそうです。

■cosの閾値
I/Oのお話の続きになります。
0.1の閾値で計算すると、50分/12,000エントリで計算が終わります。閾値を下げれば下げるほど指数関数のように保存データ量が増えて計算の足を引っ張っていることが、処理を遅くする原因のひとつのようです。
これは、DBのバッファキャッシュのチューニングすることで改善が図れるかと推測しています。

■省電力
カーネルが動的にCPUクロック数を変えるモード(governor = ondemand)で動いていました。そのため、時々クロックが低い状態で稼動したために遅さに拍車がかかっていることもわかりました。
そのため、I/O処理の最適化の後にフルパワー(governor = performance)で動くように変更しました。
これにより、計算が上記の最適化後さらに30~50%速くなるパターンもあることがわかりました。
詳しいお話はこちらもご覧ください＞
『Hot Linux - CPUの速度を動的に変えてみる(WhiteBoxEL4)』
『Core2 Quad で VMware Server の時刻が進む件は解決した - daily dayflower』