Re: [SCore-users-jp] scored のクラッシュ

[Atsushi HORI]

堀@Allinea Software です。

On 2005/10/28, at 17:58, Naoya Maruyama wrote:

> 1. "Network freezing timeout"
> 一部の計算ノードのscoredから上記のメッセージが出され、そ 
> の後sc_watchによるモニ
> タリングがタイムアウトし、システム全体が再起動されます。また、 
> このメッセージを
> 出すノードは毎回一定ではありません。　
>
> ソースコードを見てみますと、同メッセージは
> score-src/SCore/scored/scored/scorepm.cc の freeze_sending 
> () 関数より出力された
> ものと思います。この関数内で pm_is_stable() 関数を最内 
> ループで繰り返し呼んでい
> ますが、10M回呼んでもリンクが "stable" にならな 
> かったため、SCORE_PANIC関数が呼
> ばれ、同メッセージが出力されたものと思います。

その通りです。

> この関数について、まず確認したいのですが、これはリンクの送信 
> バッファに未処理パ
> ケットが残っていないことを確認するものという理解でだいたい正し 
> いでしょうか？　

「未処理」の定義が不明ですが、だいたいはそんな感じです。

> また、SCore v5.8.2の該当部分を見てみますと、SCORE_PANIC 
> ()関数を呼ぶま
> での閾値が1万へ変更されていること、1000回以降は 
> ループボディの最後に
> usleep(100) としていること、の違いがあります。この変更につい 
> て、変更し
> た理由と当方の環境でのクラッシュがこの変更によって解決しそうか 
> どうか、
> 教えていただないでしょうか？また、そもそもなぜリンクが  
> "stable" 状態に
> ならないことついてどのような理由が考えられますでしょうか？

usleep() を入れたのは、最近の CPU が高速になり、ループだけ 
では不十分な場合があったためです。PentiumIII 1.4GHz だとま 
ず大丈夫だと思います。

もし、PM/Ethernet をお使いでしたら、上記の現象は PM/ 
Ethernet のバグとして（私の記憶違いがなければ）すでに認識および 
対応が施されており、次のリリースでは修正されております。

> 2. scbcastへの送信エラー
> sc_watchがタイムアウトを検出してシステム全体がシャットダウンさ 
> れた後、再起動を
> 試みて以下のログを残して失敗しました。
>
> sc_watch: <125> SCore-D:WARNING Failed to connect to sysmon server
> (n001.example.jp:9904).
>
> ここでいう sysmon server というのは scbcast のこと 
> だと思うのですが、scbcast と
> sc_watch は同一ノード (n001) で動いており、 
> sc_watch は通常通り稼働していまし
> たので、少なくともノードn001自身がダウンしていたわけでは 
> ないと思います。おそら
> く何らかの理由でn001上のscbcastがダウンしていたか、 
> n001へのTCP/IPリンクに問題が
> あったかだと思います。
>
> さらに、最初のシステムシャットダウンがそもそもなぜ起きたか調べ 
> てみますと、計算
> ノード中の最後尾にあるノードにおいて、以下の関数呼び出しが行わ 
> れ、最後の write
> システムコールでブロックしたままになっていることがわかりました。
>
> output_job_status() -> write_sysmon() -> score_write_short() ->  
> write()
> （途中の関数が一部抜けているかもしれません）
>
> そのため、sc_watchのモニタリングに応答できず、タイムアウ 
> トが発生したものと思わ
> れます。この一連の事象について以下の質問に答えて頂けると幸いで 
> す。
>
> まず、上記の解析は正しいでしょうか？

sc_watch がタイムアウトを検出するまでは正しいですが、なぜタイム 
アウトが発生したかは様々な可能性が考えられます。

が、もし、write_sysmon() で本当にブロックしているとした 
ら、これは明らかに SCore-D のバグです。SCore-D から 
の write() はいかなる状況でもブロックしてはいけませんし、 
本当に長時間ブロックすると sc_watch のタイムアウトが発生す 
るのは当然です。今すぐには確認できませんが、機会があって、バグを 
確認できれば修正することをお約束します。

もしかすると scbcast のバグのせいかも知れません。だれかが  
sctop の出力を ^S などで止めてしまうとこのような状態に陥る 
可能性があるかもしれません。

> また、正しいとすると、scbcastへのwriteについてタイ 
> ムアウトなどを設けず、ブロッ
> クさせてしまう理由は何かありますでしょうか？ scbcast そ 
> のものは scored とは別プ
> ロセスとして分離されているにも関わらず、scbcastがダウン 
> した際にscoredまでダウン
> させてしまうのはなぜでしょうか？

write() のタイムアウト実装は面倒なので。本来ならば  
NONBLOCK になっているべきなんですが。