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

[Naoya Maruyama]

Atsushi HORI <hori ＠ allinea.com> wrote:
> > また、SCore v5.8.2の該当部分を見てみますと、SCORE_PANIC 
> > ()関数を呼ぶま
> > での閾値が1万へ変更されていること、1000回以降は 
> > ループボディの最後に
> > usleep(100) としていること、の違いがあります。この変更につい 
> > て、変更し
> > た理由と当方の環境でのクラッシュがこの変更によって解決しそうか 
> > どうか、
> > 教えていただないでしょうか？また、そもそもなぜリンクが  
> > "stable" 状態に
> > ならないことついてどのような理由が考えられますでしょうか？
> 
> usleep() を入れたのは、最近の CPU が高速になり、ループだけ 
> では不十分な場合があったためです。PentiumIII 1.4GHz だとま 
> ず大丈夫だと思います。

当方の環境でもこの現象が頻繁に確認されるわけではないのですが、感覚的に
は1月に1回程度は起きてしまっております。

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

クラッシュ前のscoredの関数トレースを取ってみましたところ、
myri2kIsSendStable()が繰り返し呼ばれていることを確認しました。ですので、
PM/EthernetではなくPM/Myrinetの話ではないかと思います。

> 
> > 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 のタイムアウトが発生す 
> るのは当然です。今すぐには確認できませんが、機会があって、バグを 
> 確認できれば修正することをお約束します。

失礼しました。もう一度確認しましたところ、write()システムコールでブロッ
クしているわけではなく、score_write()のループにはいったままsc_watchの
タイムアウトがかかったようです。こちらも関数トレースをとって確認したの
ですが、以下のscore_write()がwrite()呼び出しが成功せず、ループでスピン
していた模様です。 

int score_write( int fd, char *buf, int length ) {
  int st;

  do {
    errno = 0;
    st = write( fd, buf, length );
  } while( errno == EINTR );
  return( st );
}

このループの実行中に他のスレッドに処理が移ることはなく、sc_watchの
patrol()にも反応できなくなっていたと思われます。

また、以上の関数トレースはMPICHのJumpshotで表示できるフォーマットでとっ
てあります。もし参考になるようでしたら、仰っていただければお見せするこ
ともできます。

よろしくお願いします。

丸山直也
東京工業大学数理計算科学専攻松岡研究室