『シムエントリ』ご利用の皆様へお知らせです。
■処理速度を改善いたしました
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』
takさん＞
いろいろ教えていただきありがとうございます。
『転置インデックス』、これから本を開いて調べてみます。
クラスタリングしたとしても計算量そのものは変わりませんので、アルゴリズムそのものの変更でエントリ増加に何とか間に合わせていけたらと考えています。
リンク先、拝読いたしました。コンピュータ関連の研究をされていらっしゃるのですね。恐れ入ります。
またお気づきの点がありましたらよろしくお願いします。
エントリ数の２乗に比例する計算量がかかるというのは、
１回の（つまり類似度計算）コストをどんなに小さくしても、
エントリ数が増えればすぐに限界に達します。
転置インデックス作成とか、….自然言語処理系、クラスタリング系の技術色々導入して
計算量をN(log N)ぐらいまで減らせないと
今は大丈夫であっても、限界はもうすぐそこにありますよ
背景色は、透明か、自分で設定できるようにできませんか？
ブログで背景画像使ってるとかなり浮いてます。
シムエントリ、使わせていただいているのですが、
内容が全く違う記事のほとんどで
この記事に近いブログはこちら (Powered by シムエントリ)
* ブログを書く10のノウハウ（仮） (こみゅにけーしょん・で…)
* 関連キーワード表示2008 (研究開発)
* BTパートナー (マイクロアドの社長のア…)
と同一内容が表示されてしまっているのですが…
計算結果で何かエラーでもあるのでしょうか？
jar^2さん＞
木曜日はどうもありがとうございました！
目に見えて結果が出て、僕もとてもうれしいです(^^)
また夜によろしくお願いします！
劇的な処理速度の向上！
素晴らしいです。
お役にたてたようで嬉しいです。また飲みましょう。