アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
どうも情報がねじ曲ってるような気もしますので (スコア:5, 参考になる)
(2)1約定48byteもあればできるんじゃない?みたいなこをを書かれていますが、そんなに簡単じゃないです。色々な処理番号やらありますので。
(3)デスマーチ....でしたよ（笑）
(4)10年使ってたのは何故なんでしょうかね。取引所に金がない、ということが全てではないでしょうか。正確に言うとシステム投資をケチっている、ということです。あとは、取引所内では一番規模の大きなシステムでかなり(仕様が)スパゲッテイな状態だったみ
Re:どうも情報がねじ曲ってるような気もしますので (スコア:1)
業界に関しては素人ですが、
ネット取り引きが一般化している現在、負荷の増大は無制限に脹れあがる可能性もあるわけで、「一隻の大艦巨砲」というメインフレームのような、負荷が処理能力を越えないことが前提のシステムはそもそも通用しないという考え方もできます。
webサーバのように負荷分散でスケールアウトできないと、広く世界に開かれたインターネットへの対応という面では厳しいのかもしれません。
Re:どうも情報がねじ曲ってるような気もしますので (スコア:1, 参考になる)
# 止める というのはそれなりに安全な保護機能なわけで
Re:どうも情報がねじ曲ってるような気もしますので (スコア:1)
いろいろ難しいハードルがあるのは承知ですが。
DBの発想だとどうしてもそういう意見は出てきますが、同期の問題は単体での運用でも当然付きまとうわけで。クラスタ構成のDBは当然その部分のしくみに注力されているわけで。クラスタといっても単にディスク装置にCPUを二股かけているのとは違いますよね？
今はデータベースでも分散処理が真剣に求められるようになってますし、実際、オープン系ではクラスタ構成に移行したシステムを今では結構耳にすることが多くなってる。
Re:どうも情報がねじ曲ってるような気もしますので (スコア:5, 参考になる)
少なくとも、メインフレームのクラスタリング技術はオープン系のものよりもかなりと進んでいます。ホストを追加した分シームレスに性能が向上しますし、郵貯のオンラインやNTTのSTARシステムなど、10台以上のホストを使った、オープン系クラスタでは構築できないような大規模なシステムもあります。大体、東証の市場系システムも、ニューヨーク証券取引所のシステムも、メインフレームを使った並列シプレックス構成なので、プラットフォームは関係ないと思います
問題は東証のシステム負荷の見積もりが甘すぎるところでしょう。現状の運用方針では、1日の最高処理数の40%を余剰処理能力として想定しシステムを構築して、75%を超えればシステムを停める検討を行うという体制をとっています。これは、取引に人手が介在して限界が決まる場立ちがあった時代のシステム想定で、今のようにネット経由で大量の注文が寄せられ市場の取引量がシステムの処理能力によって限界が決まるような状況は想定していませんし、場中の発注･取消のレスポンスタイムを一定内に押さえるといった想定はしていません。これは、東証に限った話ではなく、大証やJASDAQは昨年から場中のレスポンスが大幅に低下していて、非常に問題になっています(東証より状況は悪いと思います)
Re:どうも情報がねじ曲ってるような気もしますので (スコア:1)
もともとクラスタリングすることを想定していなかったから？
もうすでに最大構成とか？
Re:どうも情報がねじ曲ってるような気もしますので (スコア:1)
一方で、クリアリング機構が運用する清算系システムは、今月末にハード更新が行われる予定です。04年中に次期システムに移行する予定でしたが、スケジュールの遅延で移行計画が先延ばしにされ、その間不足する磁気記憶装置の容量については、運用でカバーするという方針でした。しかし、昨年来の取引の急増に対して、運用カバーではなく、従来予定していなかったハード更新を行うことになった、というのがこれまでの状況です