年末に発生した原発監視装置の異常、メモリ不足が原因 83
ストーリー by hylom
世界が違う 部門より
世界が違う 部門より
あるAnonymous Coward 曰く、
2011年末に発生した全国の原子力発電所を監視するシステムのトラブルの原因は「メンテナンス不足」であった、という記事がasahi.comに掲載されました。
ニュースソースと思われる経済産業省の報道発表の別添資料を参照すると、『データ処理ソフトウェアを長期間使用していたため、一時的なデータ保存に必要なメモリ領域が不足し、当該ソフトウェアが停止したことが原因』なのだそうです。
さらに資料に目を通すと、『データ処理ソフトウェア(世界的に使用実績のある汎用品)』とか、『今後はデータ処理ソフトウェアの異常停止の防止策として、メモリ領域を解放するための操作を、年 2 回実施』とかいろいろ味わい深い表現が混じっています。
まあ、今回のシステムは原子力施設のものではなく、当然原子力プラントの制御に関わらず、単に情報をもらって蓄積・表示するシステムでの話のようですが、24時間対応体制を求められることになった関係者の方々がちょっと気の毒にもなりました。
時事通信によると、原発から送られてきたデータはデータベースに集約して保存されるようになっていたそうだ。このソフトは世界的に使われている汎用品とのことで、長期間連続稼働させるとメモリ不足が発生する不具合があったという。問題発生時は2年4か月の連続稼働が続いた状態だったとのこと。「ソフトを止めて再起動すればメモリー不足は解消されたが、思いつかなかった」らしい。
リソースの監視はしてないのか? (スコア:2)
リソースを監視しておくのが、
こういったシステムの常識ではないのか?
常識の無い人が運用したらどんなソフトを使ってもだめだぞ!
Re:リソースの監視はしてないのか? (スコア:1)
監視システムの監視システムの監視要員を監視する人を配置してなかったんでしょうか。
監視システムの監視システムの監視要員を監視する人を配置して、
監視システムの監視システムの監視する監視組織を監視する監視市民団体もかんししなきゃ
#あまりかんがえてない
後悔後を絶たず、と誰かが・・・ (スコア:0)
「防波堤を高くすれば津波は防げたが思いつかなかった」よりはマシか、な?
Re:後悔後を絶たず、と誰かが・・・ (スコア:2)
なぜ,誰も突っ込まない?
「後悔先に立たず」
http://oshiete.goo.ne.jp/qa/203028.html [goo.ne.jp]
野暮だったらゴメン.
Re: (スコア:0)
つfj
というか、参照URLの「後悔後に立たず」では日本語の文章としても成り立ってないだろ。論外。「後悔後を絶たず」は、なんど失敗し後悔をしても、人間は相変わらず失敗を繰り返し後悔し続けるものなのだというそこそこ深い含蓄がある文章だぞ。
Re: (スコア:0)
「防波堤を高くすれば津波は防げたが思いつかなかった」よりはマシか、な?
福一の教訓は「防波堤を高くすれば」じゃなくて、「予備電源を(津波などあらゆる災害でも)失わない位置に複数確保する」、
だと解釈していたけどこっちが共通認識になってるの?
海岸地形によるけど、最大遡上数十mとかで防波堤整備しろとか無理すぎ
Re:後悔後を絶たず、と誰かが・・・ (スコア:2)
福一の教訓は、そのどっちでもなくて、「日本の電力会社・原子力関係の公的機関は、原発事故の際の対策の研究・策定を、まともにやってきてなかったし、多分、今後も、まともにやらない」だと以下同文
Re: (スコア:0)
はい、「日本はだめだ」論で何がだめなのか考えなしは日本をだめにするね
Re:後悔後を絶たず、と誰かが・・・ (スコア:1)
いや、最近の調査で当時の状況がだいぶわかってきているの。
最大の問題はね「電源なしでも冷却を継続するための装置(非常用復水器)は備わってたけど、使わなかった」って事だと思うよ。
だいぶ時間がたってから非常用復水器の存在を思い出して稼働させたけど、壊れると困るからって再び停止させてたらしい。
他にも「正常時にしか正しく水位を測れない水位計を設置しており、異常事態下においてその水位を信じてチェックしていた」とか・・・
Re: (スコア:0)
> 福一の教訓は「防波堤を高くすれば」じゃなくて、「予備電源を(津波などあらゆる災害でも)失わない位置に複数確保する」、
> だと解釈していたけどこっちが共通認識になってるの?
米企業が「津波なんて知らないよ、予備発電設備は複数より地下が一番」。地下に設置しないと保証しない。
だったはず。
Re: (スコア:0)
> 福一の教訓は「防波堤を高くすれば」じゃなくて、「予備電源を(津波などあらゆる災害でも)失わない位置に複数確保する」、
> だと解釈していたけどこっちが共通認識になってるの?
米企業が「津波なんて知らないよ、予備発電設備は複数より地下が一番」。地下に設置しないと保証しない。
だったはず。
うん、だから、「予備電源を(津波などあらゆる災害でも)失わない位置に複数確保する」だったんじゃないの?ってのか元コメなんだけど。
それならこれほどの重大事故にならなかったわけで、今後の発電所設計の教訓になったわけでしょ?
Re: (スコア:0)
メインはこっち
Re: (スコア:0)
>地下に設置しないと保証しない。
メインはこっち
うん、だからそれ無視して予備電源を作っておけば事故は起こら(もうあほか
アメ企業から保証の金さえとれれば満足なの?
設計ミスはどこにあって、それをどう克服するかという話してんの。
お前ら、バグ発見したときに「そもそも労働者がソースコード組まなきゃよかった。労働者の責任」って外部の意見あったらそれに同調するのかよ
Re: (スコア:0)
だから予備電源をどうのとかの教訓は糞役に立たねって話なんだが、わかんねーかな
Re: (スコア:0)
>アメ企業から保証の金さえとれれば満足なの?
保証金がどうこうじゃないだろ
メーカーの指定通りに施工しておかないとテクニカルサポートが受けられないって話だよ
Re: (スコア:0)
Re: (スコア:0)
>設計ミスはどこにあって、それをどう克服するかという話してんの。
だから予備電源をどうのとかの教訓は糞役に立たねって話なんだが、わかんねーかな
え、予備電源どうでもよかったんですか?(#2079741) で貴方(orシンパ)が
>米企業が「津波なんて知らないよ、予備発電設備は複数より地下が一番」。地下に設置しないと保証しない。
>だったはず。
とか言ったのに?
ちょっとよくわからないですね。わたしは、今回の件をもとに「予備電源を喪失しないようにしないといけない」といっているのですが
なんで米企業の発言をもって「予備電源の確保有無は重要じゃない」みたいなこといってるのか理解不明です。
つか「糞役に立たねって話なんだが、わかんねーかな」って、トークできてませんよ。
それで論争相手を説き伏せようっていうのは、論争相手を馬鹿にすることで自分を上位において悦に入るだけですね。
Re: (スコア:0)
ああ、理解できた。齟齬があったと理解した。
元コメはこれだ。
>福一の教訓は「防波堤を高くすれば」じゃなくて、「予備電源を(津波などあらゆる災害でも)失わない位置に複数確保する」、
この「予備電源」は、今回機能した、(現在完了形的な)実在した予備電源ではなくて、理想的な設計でありうる「予備電源」だ。
津波が来ても、その後背地でボイラー噴かして、爆発を防いだんじゃないかって『いうふうに機能を期待されていた』「予備電源」だ。
対論者がどうしてもかみ合わなかったのはこうだろう。
>だから予備電源をどうのとかの教訓は糞役に
Re: (スコア:0)
> 対論者は、原発という仕組みが失敗したのだから、それにかかわるすべての枠組みが失敗しているはずだという
> 観念でいってますよね
原発という仕組みが失敗したからには
それにかかわるすべての個々の枠組みに
ついて失敗している可能性があると
疑って検証すべきだ。
Re:後悔後を絶たず、と誰かが・・・ (スコア:1)
親コメもだけど「保証」と「補償」を使い分けよう。
Re: (スコア:0)
それを突っぱねなかったのは日本側。
Re: (スコア:0)
止まってしまったことよりも、こんな大事なシステムが死活監視すらされておらず、データが表示されないことにたまたま誰かが気付くまで死んでることすら判らなかったというのが大問題だと思う。
Re: (スコア:0)
原発に賛成反対以前の話だな
ムリだわ
Re: (スコア:0)
経済産業省の報道発表の資料をみるとわかるんですが、今回のシステムは「監視専用」の「原発の運用とは関係ない」もののようです。
ここで「そもそもそんなもの必要だったの?」「原発からもらった監視データのデータベース化やWeb対応なら原発側でも似たようなことをやってるんじゃないの?」という疑問が沸いてきます。
まあ、第三者の異常監視はやるに越したことはないのですが、そんなものをさも危険な障害であるかのように報道する方も「単にセンセーショナルに報道して注目集めたいだけなんじゃない?」という気がします。
Re: (スコア:0)
Re: (スコア:0)
原因究明結果及び再発防止策の報告書 [meti.go.jp]の5ページに載っているシステムの概略からみて、妥当な運用費なんでしょうかね??
#誰かのところに還流されてるんじゃないんだろうかとか、つい思ってしまうのは悪い癖。
メモリリーク? (スコア:0)
サーバを業務開始前に再起動する運用のところもあるらしい
Re: (スコア:0)
某メガバンクが合併前のただの1銀行だったとき、そこの勘定系システムでは週1のシステム再起動が運用に加えられたという事もありましたねぇ。
ライブラリがリソース解放しないせいでメモリ枯渇するって理由だったかな。
Re:メモリリーク? (スコア:1)
deleteしたはずなのにメモリ解放されずにメモリ不足で止まったことがあった僕の経験から、
VC++でのデバッグ中はむしろメモリを開放せずに、何かの時のためにとっておく機能があると思います。
#最終的にメモリは同じ物をなるべく使いまわす設計にしました。
Oracle (スコア:0)
Oracleの古いバージョンはメモリアロケーションに問題があり、数年単位で無停止で使用するとメモリがなくなるバグがありました。
Re:Oracle (スコア:1)
Re: (スコア:0)
それをいったらWindowsは大丈夫でしたっけ?
#ライセンス的にも安定性的にも
Re: (スコア:0)
Windowsは使うなって明示されてなかったっけ?
Re: (スコア:0)
今は知りませんが、「医療関係に使って何かあっても、ウチら知らんで」
みたいな扱いだと、昔聞きました。
それはOracleに限らず、WindowsやらSQLServerでも同じだとか。
#ライセンスなんて読んだことないや…
Re:Oracle (スコア:1)
http://www.ustream.tv/recorded/19694240 [ustream.tv]
8分20秒あたり
Re:Oracle (スコア:1)
Xなんかも大昔(X11の初めの頃)にはメモリリークだらけで, 業務システム本体は大丈夫でも, X上の監視用画面がメモリを食い尽くしてダウンしたなんてことも. なもんで, ハード性能・機能的にはシステム本体と操作・監視系を同一にできても, あえて別ハードにするというのが定石でした.
そういう経験があると, Windowsサーバのように(今ではGUI系統を外すことはできるんですけど)サーバ本体でGUI画面を使うというのに気持ち悪さを感じてしまうのです.
Re:Oracle (スコア:1)
Postgresのちょっと古めのバージョンを組み込んだ某サーバソフトが定期的なvacuum処理やってなくて、
使っているうちにどんどんディスクを食い潰す、というバグを思い出した。
Re: (スコア:0)
>『データ処理ソフトウェア(世界的に使用実績のある汎用品)』
ってフレーズでぱっと浮かんだのはExcelだったんだ……
Re: (スコア:0)
おい。Accessを忘れるなよ。あれならOracleだろうがSQL鯖だろうが繋がるじゃないか。
Re:Oracle (スコア:2)
fj.jokes出身:
Re: (スコア:0)
僕の面倒見ているシステムでも起こりました。
でも、メモリが足りなくなるとかではなくて、稼働日が200日位を超えたらハングするだったかな?
solarisでoracle 8だったと思います。
調べたら、割と最近のバージョンでも似たような問題が有るみたいですね。
http://www.drk7.jp/MT/archives/001197.html [drk7.jp]
Re:Oracle (スコア:2, 参考になる)
あった。
これですね。
http://www.sunmanagers.org/pipermail/summaries/2002-June/001844.html [sunmanagers.org]
Re: (スコア:0)
Windowsの場合、かつて48日問題ってありましたよね。
こまめに再起動しろってことですけど、毎月セキュリティ修正を当てていたら、かなりの確率でシステム再起動になるはずなので、問題になっていないだけなのかな?
Re:Oracle (スコア:2)
> Windowsの場合、かつて48日問題ってありましたよね。
Windows だろうが他の OS を使ってようが
クリティカルなシステムを運用する場合、
走行試験で確認した日数を超えて運用し
つづけるべきではない。
走行試験で確認した日数に到達したら
現行系と待機系を切り替えるべきだ。
Re:Oracle (スコア:1)
Windowsの場合、かつて48日問題ってありましたよね。
49.7日問題 [wikipedia.org]。
Firefoxだろ? (スコア:0)
知ってるよ。
Re: (スコア:0)
ロシア語がなんだって?
Re: (スコア:0)
『перезапуск』って定期的に思考しなきゃいけなかったんですね。
Re: (スコア:0)
Firefoxだったら20コも前のバージョンのやつですよ。
Re:メンテナンスが問題なのか (スコア:1)
数年の無停止連続稼働を求められる案件は結構ありますよ。 たかだか2年くらいのスパンで生じるのであれば、 普通にテストしていればメモリリークくらいは発見できるのでは。
今ふと思ったんですが、QCの常道「加速劣化試験」のために2倍のクロックで動くマシンを用意してRTCをいじって、とかいうアプローチはないんでしょうか。
Jubilee