アカウント名:
パスワード:
板情報を配信するプログラムは本来、1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分、合計3万5000Kバイト確保するよう記述しなければならない。だが、1銘柄当たりのメモリー領域を誤って4バイトとしてしまったため、プログラムは本来の320分の1の109.375Kバイトしか確保しなかった。結果として89銘柄以上の板情報の問い合わせが同時に発生すると、作業用メモリーが足りなくなり、情報配信システムがダウンした。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
ちょっと違う (スコア:4, 参考になる)
データ容量のサイズが28000銘柄分のはずが88銘柄分しか確保できてなかった。
http://itpro.nikkeibp.co.jp/article/NEWS/20080722/311271/
Re: (スコア:5, 参考になる)
Re:ちょっと違う (スコア:1)
Re:ちょっと違う (スコア:1, 興味深い)
皆さん現役の方ですよね。世の中にはこの手のバグを飼ってるソフトが多数出荷されてるってことになりますか。
Re:ちょっと違う (スコア:1, 興味深い)
同時に、東証のシステムが 64bit 化されていない事も推測できる、と ｗ
Re: (スコア:0)
プログラマも人間なんで、間違いはいくらでもやります。
でも、特に大きなシステムの場合、ソースコードを複数人で確認するはずで、
確認していればこういう記述ミスレベルのものは、大抵発見できるですよ。
もちろんその前後にテストだってやるし。
作りこむことは多数あっても、出荷する前に見つかって直ってます。
ええ、大抵は。
#「データ容量のサイズ」という変な表現を直したかった。
Re:ちょっと違う (スコア:1, おもしろおかしい)
そんなプロジェクトありません(笑)
＃笑っちゃいけないところだけど。
Re:ちょっと違う (スコア:1)
>そんなプロジェクトありません(笑)
一度に複数人で確認する事は無いけど、3ヶ月ごとに別の人がメンテする案件というのはありがち。
まあ、今回に限って言えば、いかにコーディングを正確に行ったかよりも、
境界値・例外値・適正値の検証不足が原因でしょう。
人の数より、質の問題。
一見コードは正しいけど、運用でコケるって類のミスを防ぐには、
PGが複数人居て見ても気がつきにくい、なぜなら業務のプロでないから。
いわゆるユーザー系SIであれば、業務にも通じている人間が常時いるけど、
大規模アプリの全モジュールをチェックできる人数抱えていない罠。
＃88銘柄にしろ28000銘柄にしろ、上限値を超えた時の例外処理にも問題があるように思える。
Re: (スコア:0)
だが、富士通から納入されている売買システムはＣＯＢＯＬだから今回の先物システムもＣＯＢＯＬじゃないの？
ＣＯＢＯＬでヌルポやポインタ記述ミスは起こらない。
そこで他の方が書かれているようにストレステストじゃなくてエラー処理検証用に最大数を８８（適当な数字）にして
エラーシーケンスのテスト後戻し忘れじゃないの？
これは受け入れ検査時だと思うので東証側のシステム担当者が悪い？ 保身の為にメーカに責任を負わせると次のシステムも
富士通に決定。
原因不明と言うよりも、”ヌルポ！ ガッ！”って言っとくほうが恥ずかしいバグですが誰もが納得して修正後は根治されたと納得できる。
Re: (スコア:0)
いうことで…。物凄い寒気がするんですが。
Re:ちょっと違う (スコア:1)
それはそれで怖いですな。小説のネタっぽいですが。
あぁそうそう、そうですよだから僕は三流プログラマなんですよ！
決して怠惰で勉強してないわけじゃないんですよ！
Re: (スコア:0)