アカウント名:
パスワード:
板情報を配信するプログラムは本来、1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分、合計3万5000Kバイト確保するよう記述しなければならない。だが、1銘柄当たりのメモリー領域を誤って4バイトとしてしまったため、プログラムは本来の320分の1の109.375Kバイトしか確保しなかった。結果として89銘柄以上の板情報の問い合わせが同時に発生すると、作業用メモリーが足りなくなり、情報配信システムがダウンした。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
ちょっと違う (スコア:4, 参考になる)
データ容量のサイズが28000銘柄分のはずが88銘柄分しか確保できてなかった。
http://itpro.nikkeibp.co.jp/article/NEWS/20080722/311271/
Re: (スコア:5, 参考になる)
Re: (スコア:1)
Re: (スコア:1, 興味深い)
皆さん現役の方ですよね。世の中にはこの手のバグを飼ってるソフトが多数出荷されてるってことになりますか。
Re: (スコア:0)
プログラマも人間なんで、間違いはいくらでもやります。
でも、特に大きなシステムの場合、ソースコードを複数人で確認するはずで、
確認していればこういう記述ミスレベルのものは、大抵発見できるですよ。
もちろんその前後にテストだってやるし。
作りこむことは多数あっても、出荷する前に見つかって直ってます。
ええ、大抵は。
#「データ容量のサイズ」という変な表現を直したかった。
Re:ちょっと違う (スコア:1, おもしろおかしい)
そんなプロジェクトありません(笑)
＃笑っちゃいけないところだけど。
Re:ちょっと違う (スコア:1)
>そんなプロジェクトありません(笑)
一度に複数人で確認する事は無いけど、3ヶ月ごとに別の人がメンテする案件というのはありがち。
まあ、今回に限って言えば、いかにコーディングを正確に行ったかよりも、
境界値・例外値・適正値の検証不足が原因でしょう。
人の数より、質の問題。
一見コードは正しいけど、運用でコケるって類のミスを防ぐには、
PGが複数人居て見ても気がつきにくい、なぜなら業務のプロでないから。
いわゆるユーザー系SIであれば、業務にも通じている人間が常時いるけど、
大規模アプリの全モジュールをチェックできる人数抱えていない罠。
＃88銘柄にしろ28000銘柄にしろ、上限値を超えた時の例外処理にも問題があるように思える。