吉田の独自タイム指数検証開始

Posted on :| コメント (0)

 何回かこのブログの記事にした、新タイム指数ですが、ようやく細部の構成が決まってきたので一度検証にかけることにしました。 タイム系指数で一番面倒な馬場指数の設定と、基準タイムの設定は手つかずでそのまま残っています。

 今回は式の優劣を判断するのが目的なので、 馬場指数および基準タイムは西田式スピード指数で使用しているものをそっくりそのまま流用することにしました。

 近5走の出馬表形式での表示はとっくにできていますが、これを見た感じでは、あまり特性に差はないといえます。 式のなかでもっとも大きな要素である「馬場指数」と「基準タイム」を流用しているので、まぁ仕方がありませんが。

 検証は指定期間の出馬表をファイルに書き出してから行います。元になるデータはEveryDBによって蓄積されたSQL Server2005上のものを利用していますが、5走分の戦績付きの出馬表を作成するには、結構時間がかかります。 1レースあたり2-5秒ですが、1年分でだいたい3456レース(1日12レース換算)になるため、 単純計算で5時間はかかることになります。

 しかし、ここに落とし穴があり、だいたい7ヶ月分のデータを出力したあたりで、がくんとパフォーマンスが低下します。SQL Serverはメモリ消費が大きいため、連続したクエリーを発行するとPCのメモリを消費しきってしまいます。 吉田の環境でだいたい2GBはSQL Serverが占有します。
 メモリ使用のピークにはもっと早い段階で達しますが、なぜか7ヶ月分のデータを出力したあたりでCPU負荷も100%から5% 程度まで落ち込んでしまいます。なお、SQLを発行するとたいていはCPUを使い切ってしまうのが普通です。

 SQL Serverに割り当てられたCPUリソースが軽くなると言うことは、それだけデータ作成時間が延びると言うことです。 実際、昨晩のPM10時にセットしたにも関わらず、 翌日のAM10時の段階では1年分のデータが出力されていません(だいたい11月ぐらいになっている)。
 おまけに、CPU負荷が軽いくせにすべての操作が非常に重たくなってしまいます。

 1日分のスピード指数をファイルに書き出して検証するという手法は、SQL Serverの挙動に対する苦肉の策として行っている方法です。いずれ、根本原因を追求して問題を解決したいと考えていますが、SQL Serverのことを完全に理解してないので、かなり手こずりそうです。

 さて、まだ1年分のデータが出力されてないので、検証結果はまた別の機会にでも。

コメント

コメントフォームに記入し投稿してください





Search
最近の記事
カテゴリー
過去の記事
Comments
TrackBacks
Feed
Powered by