「東証システム障害の真因」にトラックバックがあったが……。
「1銘柄当たりのメモリー領域を誤って4バイト」と指定できてしまうような仕様にそもそもの原因があると思う。「1銘柄当たり1280バイトの作業用メモリー領域」であるならば、銘柄数が決まれば確保すべき作業用メモリー領域も決まってしまうのだから、銘柄数を指定するだけでも充分なはずである。
これに対して以下のように書かれていた。
最大銘柄数は東証の拡張にともなって変更される可能性があります。そしてこの作業用メモリーの領域サイズを計算するには、「最大銘柄数×１レコードのバイト数（1280バイトって奴）」となり、バイト数も必要です。また、１レコードのサイズも将来的に変更される可能性もあります。
東証の拡張にともなって変更される可能性は考慮していたから、「銘柄数」を固定にしろとは書いてない。銘柄当たりの作業用メモリー領域も将来的に変更される可能性はある。だが、C言語におけるsizeof演算子等を使い、銘柄当たりの作業用メモリー領域の大きさを自動的に算出するのはプログラマとして常識的な手法である。銘柄数を指定するだけで充分なはずである。
で、４バイトというのがまた絶妙ですね。C系のプログラマーの方は、これを聞いた瞬間にピンと来たはず。昔、NASAでロケットを打ち上げる際、FORTRANのプログラムソースで「.」記号を一個忘れたために、ロケットが落ちてしまったという笑えない話がありましたが、こちらも「sizeof(*hoge)」の括弧中の「*」記号を１文字忘れたためにおきたポインタがらみのバグの可能性が濃厚です。これはC系の言語でプログラムを作った人は誰もが一度は通過儀礼としてやってしまうバグの典型であります。
「東証が派生商品の立会取引を再開、システムを変更前の状態に戻す」等の記事によれば、派生売買システムの動作プラットフォームは富士通のPRIMEQUESTとなっている。PRIMEQUESTは、64ビットのItanium 2を採用しているので、ポインタのサイズは8バイトのはずである*1。
あまり多いと、メモリーを無駄に搭載するか、それともスワップを起こしてパフォーマンスを低下させる事になりますので、多ければよいという問題ではありません。まあ、最近では35Mbyte程度どうって事無い量になっちゃいましたが、少なくともここで作業エリアの件数として算出の根拠とするのは、銘柄数ではなく同時アクセス数の推計であるという事で。
データがメモリー上に無いと、HDDから読み込んでくることになり応答時間が悪化する。アルゴリズム取引の普及により、世界の証券取引所は応答時間の短縮競争に巻き込まれている。短縮競争に遅れをとっていると批判されている東証が、HDDから読み込む等の、処理が遅くなるとわかりきっている手法を使えるはずがない。
*1:Itanium 2は32ビット動作もするが互換性のためであり、新規のアプリケーションを32ビットで動かすとは思えない
