赤松
akama****@oss*****
2009年 4月 13日 (月) 14:19:40 JST
To:加納様 赤松です。 返答がおくれてしまい、申し訳ございません。 > Apr 5 19:17:11 host02 heartbeat: [24518]: WARN: Gmain_timeout_dispatch: > Dispatch function for > client audit was delayed 5010 ms (> 5000 ms) before being called > (GSource: 0x64ca28) > Heartbeat2.1.4のプログラムを元に、ざっと解析しました。 上記メッセージは、まさに Gmain_timeout_dispatch という処理を開始 する際に、予め設定されたdelayの数値(5000s)を超えた為に出力されたと 思われます。 Gmain_timeout_dispatch は、登録された決められた間隔で、登録された 処理を呼び出して実行する為の、下回りの処理関数です。 登録された処理を呼び出す前に、最大遅延時間を超えているか判定 しています。 超えている時は上記メッセージを出力しますが、その後の処理に なんら分岐を与えるものでは無く、単にメッセージを出力するだけです。 （尚、この時にどんな処理を行いたかったのかまでは判り兼ねます） よって、可能様の推察通り、当メッセージの扱いについては、その時の サーバ負荷が多少高かった可能性があった、程度の認識で良いと思います。 当メッセージがトリガとなる事でfailoverが発生する事は、ないです。 以上です。 > 赤松様 > > 初めまして。加納と申します。 > # 関根とは同じ職場で働いております。 > > 古い話となってしまい、また質問ばかりで大変恐縮ですが、 > 下記についてご回答頂ければ幸いでございます。 > > 依然ご質問させて頂きましたアラートについては、 > 抑止対応を行いました。 > > ただ、先日同アラートと同じタイミングで下記アラートが発生しました。 > > ---------------------------------------------------------------------------- > --- > Apr 5 19:17:11 host02 heartbeat: [24518]: WARN: Gmain_timeout_dispatch: > Dispatch function for > client audit was delayed 5010 ms (> 5000 ms) before being called > (GSource: 0x64ca28) > ---------------------------------------------------------------------------- > --- > > 文言を見ると以前のアラートと同様、何かの処理が遅延したことによる > アラートのように見受けられます。 > > こちらも、以前ご回答頂いたものと同様、サーバの負荷を通知する為の > アラートで、Heartbeatの動作に影響を及ぼすものではないという認識で > よろしいでしょうか。 > > # そもそも「Gmain_timeout_dispatch」という関数が処理の遅延を > # 通知する働きをしているという認識でよろしいでしょうか。 > > 以上、どうぞよろしくお願い致します。 > > > > sekine.yuki wrote: > > 赤松 様 > > > > お世話になっております。 > > 詳細な説明ありがとうございます。 > > 影響範囲もだいぶイメージがついたので非常に助かりました。 > > > > いろいろ自分の勉強不足でした。 > > アラート抑止文言に関しては今後調査を進めさせて頂きます。 > > > > お忙しいところ対応ありがとうございました。 > > 今後ともよろしくお願い致します。 > > > > 関根 > > > > 赤松 さんは書きました: > > > >> To:関根さん > >> > >> 赤松と申します。 > >> 下記、インラインで回答いたします。 > >> > >> > >> > >> > >>> 上記の示すSIDCHLDシグナルは内部(各ノード単体)に閉じた世界 > >>> なのでしょうか？ > >>> それともクラスタグループ全体からの相互通信によるもの > >>> なのでしょうか？ > >>> > >>> > >>> > >> あくまでサーバ（host02？）内のHeartbeatの動作に特化したシグナルです。 > >> クラスタグループとは関係ありません。 > >> > >> > >> > >> > >>> また、今回のメッセージでクラスタ環境に悪影響を及ぼす様な事は > >>> 有るのでしょうか？ > >>> （リソースの消滅や多重起動など） > >>> > >>> > >>> > >> このメッセージは、処理依頼が来てから実際の処理を行うまでの間の時間が > >> 閾値（100msec、変更不可）を超えた事を知らせています。 > >> 実際の処理を行う前に、閾値を超えていたらログに出力しています。 > >> > >> おそらくコミュニティとしては、この時に多少の負荷が存在していた事を > >> 保守者へ伝える為のお知らせとして、組み込んだものと思われます。 > >> > >> このメッセージが出力されている時、それなりの負荷が存在した事を示す > >> 目安程度と考えるのが良いかと思います。 > >> 短い時間にあまりに頻発するようであれば、負荷によるリソースの監視 > >> タイムアウトが万一発生する可能性を考慮し、リソースの各種タイム > >> アウト値の調整を検討する、くらいの運用で良いのではないかと > >> 考えます。 > >> > >> > >> > >> > >>> 今回のアラートがトリガーとなってfailoverの発生してしまう場合は別途 > >>> 「ERROR」が出力されるイメージなのでしょうか？ > >>> > >>> > >>> > >> 上記に示しました通り、当アラートがトリガとなる事でfailoverが発生 > >> する事はないと思われます。 > >> > >> > >> > >> > >>> 監視抑止するのに「WARN」を全部抑止は考えていません。 > >>> どんな文言を抑止の対象とすれば障害の際に弊害とならずに済むでしょうか？ > >>> > >>> > >>> > >> 関根さんのご利用環境（Heartbeatのバージョンや追加パッケージ等）が > >> 判りませんし、運用方針にも依存するので、こうすべきと言い切る事は > >> できませんが、あくまで個人見解として述べさせて頂きます > >> （ちなみに私の環境は 2.1.3-1.p1 及び 2.1.4-1 です） > >> > >> 私としましては、ERROR及びCRITの二つは、重点的に見ています。 > >> （ERRORと出たからと言って必ずしもERRORではない場合もありました） > >> > >> それ以外の見方としましては、WARNやinfo等のファシリティ単位ではなく > >> 状態が変更された際のログそのものを監視対象にしています。 > >> > >> "状態の変更"とは主に、リソースの開始・監視・停止失敗時、クラスタ > >> グループへの参加・離脱、ネットワーク監視、Heartbeat用LANの断線・結線等 > >> が挙げられます。 > >> これらを試験的に実施し、出力されるログを参考にして監視対象にする > >> という方法を採っています。 > >> > >> > >> Heartbeatはログ解析がとても大変なので、この辺りの作業を楽にして > >> くれる追加パッケージの登場が待たれる所です。 > >> > >> > >> 以上です。 > >> > >> > >> > >> > >>> 赤松様 > >>> > >>> 回答ありがとうございます。 > >>> 1点気になっている点が有るのですが、 > >>> > >>> > >>>> SIGCHLD シグナルを受信してから、SIGCHLD シグナルに括りつけられた処理を > >>>> 開始 > >>>> するまでの時間 > >>>> > >>>> > >>> 上記の示すSIDCHLDシグナルは内部(各ノード単体)に閉じた世界なのでしょう > >>> か？ > >>> それともクラスタグループ全体からの相互通信によるものなのでしょうか？ > >>> 認識不足で申し訳ありませんが教えて頂けたらと思います。 > >>> > >>> また、今回のメッセージでクラスタ環境に悪影響を及ぼす様な事は有るのでしょ > >>> うか？ > >>> （リソースの消滅や多重起動など） > >>> > >>> 当アラートを検知する直前に毎回決まったメッセージが出力されています。 > >>> 何かの参考になればと思います。 > >>> =============================================== > >>> Daily informational memory statistics > >>> MSG stats: 6/9634137 ms age 0 [pid24518/MST_CONTROL] > >>> ha_malloc stats: 724/305366571 175824/93154 [pid24518/MST_CONTROL] > >>> RealMalloc stats: 404684 total malloc bytes. pid [24518/MST_CONTROL] > >>> Current arena value: 0 > >>> MSG stats: 0/0 ms age 6978126360 [pid24521/HBFIFO] > >>> ha_malloc stats: 440/473 51072/28485 [pid24521/HBFIFO] > >>> RealMalloc stats: 51072 total malloc bytes. pid [24521/HBFIFO] > >>> Current arena value: 0 > >>> MSG stats: 0/0 ms age 6978126360 [pid24522/HBWRITE] > >>> ha_malloc stats: 445/3364206 60876/33958 [pid24522/HBWRITE] > >>> RealMalloc stats: 69556 total malloc bytes. pid [24522/HBWRITE] > >>> Current arena value: 0 > >>> MSG stats: 0/0 ms age 6978126420 [pid24523/HBREAD] > >>> ha_malloc stats: 446/6422331 60968/34022 [pid24523/HBREAD] > >>> RealMalloc stats: 65012 total malloc bytes. pid [24523/HBREAD] > >>> Current arena value: 0 > >>> MSG stats: 0/0 ms age 6978126470 [pid24524/HBWRITE] > >>> ha_malloc stats: 447/3364216 61060/34086 [pid24524/HBWRITE] > >>> RealMalloc stats: 69740 total malloc bytes. pid [24524/HBWRITE] > >>> Current arena value: 0 > >>> MSG stats: 0/0 ms age 6978127740 [pid24525/HBREAD] > >>> ha_malloc stats: 448/6422345 61152/34150 [pid24525/HBREAD] > >>> RealMalloc stats: 65196 total malloc bytes. pid [24525/HBREAD] > >>> Current arena value: 0 > >>> These are nothing to worry about. > >>> =============================================== > >>> 今回のアラートがトリガーとなってfailoverの発生してしまう場合は別途 > >>> 「ERROR」が出力されるイメージなのでしょうか？ > >>> 監視抑止するのに「WARN」を全部抑止は考えていません。 > >>> どんな文言を抑止の対象とすれば障害の際に弊害とならずに済むでしょうか？ > >>> > >>> いろいろ質問が多く恐縮ですが、お力をお借りできたらと思っています。 > >>> > >>> 以上、宜しくお願い致します。 > >>> > >>> 関根 > >>> > >>> > >>> 赤松 さんは書きました: > >>> > >>> > >>>> To:関根様 > >>>> > >>>> はじめまして、赤松と申します。 > >>>> > >>>> 御提示頂きましたログ情報についての見解をお伝えします。 > >>>> > >>>> ログのメッセージは、Heartbeatの内部処理にて、SIGCHLD シグナルを > >>>> 受信してから、SIGCHLD シグナルに括りつけられた処理を開始するまでの > >>>> 時間が、予め設定された制限時間を超えた事を意味するものです。 > >>>> > >>>> なお、"予め設定された制限時間"は100msで、プログラム内にハード > >>>> コーディングされており、設定ファイル内の数値による調整は > >>>> できません。 > >>>> つまり当ログを出力させないようにする手順は、現時点では > >>>> ございません。 > >>>> > >>>> メッセージが出力された原因としましては、その時点での相応の負荷に > >>>> よるものではないかと推測できます。 > >>>> > >>>> 現時点での運用上で、特に問題が無い様であれば、暫定対処及び > >>>> 本格対処の検討等は必要ないと考えます。 > >>>> 運用監視ソフト等にて当メッセージを監視対象としている場合には > >>>> 監視対象から外して頂いても問題ないと思われます。 > >>>> > >>>> > >>>> 以上です。 > >>>> 宜しくお願い致します。 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> お世話になっております。 > >>>>> 関根 と申します。 > >>>>> > >>>>> 下記につきまして、対応の経験やトラブル対応のナレッジをお持ちの方がいま > >>>>> し > >>>>> たら返答願いたいと思います。 > >>>>> > >>>>> この度下記のアラーとが発生しております。 > >>>>> ================================== > >>>>> Feb 19 19:07:07 host02 logger: " host02 [messages] Feb 19 19:07:07 > >>>>> host02 heartbeat: [24518]: WARN: Gmain_timeout_dispatch: Dispatch > >>>>> function for check for signals took too long to execute: 580 ms (> 510 > >>>>> ms) (GSource: 0x64cba8) " > >>>>> Feb 19 19:07:07 host02 logger: " host02 [messages] Feb 19 19:07:06 > >>>>> host02 heartbeat: [24518]: WARN: Gmain_timeout_dispatch: Dispatch > >>>>> function for check for signals was delayed 2620 ms (> 510 ms) before > >>>>> being called (GSource: 0x64cba8) " > >>>>> Feb 19 19:07:07 host02 logger: " host02 [messages] Feb 19 19:07:06 > >>>>> host02 heartbeat: [24518]: WARN: Gmain_timeout_dispatch: Dispatch > >>>>> function for send local status was delayed 2860 ms (> 510 ms) before > >>>>> being called (GSource: 0x64c5a8) " > >>>>> ================================== > >>>>> 上記アラートが最近になってほぼ毎日、同じような時間に発生しています。 > >>>>> メッセージでは通信に遅延が発生しているように感じられます。 > >>>>> 通信に異常が出ていない為、問題はないのかとも考えていますが、本エラーに > >>>>> 関 > >>>>> する情報をお持ちの方が居たら教えて頂けたらと思います。 > >>>>> > >>>>> また参考までに構成ですがシンプルな2台構成でそれぞれにVIPを1つずつリ > >>>>> ソー > >>>>> スとして持たせています。 > >>>>> リソースはVIPのみで、襷掛けの形のActive-Standby構成になっています。 > >>>>> > >>>>> 変わった特徴としてはセグメントを3つ使用しVIPが上がるセグメント以外の2 > >>>>> つ > >>>>> のネットワーク帯でucast通信を行っています。 > >>>>> > >>>>> 現在、この時間に負荷がかかる様な処理は確認できませんが、半年以上 > >>>>> restart > >>>>> していないので不具合？とも疑っています。 > >>>>> > >>>>> 情報が少なくて恐縮ですが、お力を貸して頂けたら幸いです。 > >>>>> > >>>>> 以上、宜しくお願い致します。 > >>>>> > >>>>> 関根 > >>>>> > >>>>> _______________________________________________ > >>>>> Linux-ha-japan mailing list > >>>>> Linux****@lists***** > >>>>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> -- > >>> +----------------------------------------++ > >>> 関根 勇喜 (sekine.yuki) > >>> 株式会社 シンプレクス・テクノロジー > >>> 〒106-6016 > >>> 東京都港区六本木1-6-1 泉ガーデンタワー16F > >>> mailto:sekin****@simpl***** > >>> TEL: 03-5545-7870 > >>> FAX: 03-5545-7875 > >>> +----------------------------------------++ > >>> > >>> _______________________________________________ > >>> Linux-ha-japan mailing list > >>> Linux****@lists***** > >>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan > >>> > >>> > >> _______________________________________________ > >> Linux-ha-japan mailing list > >> Linux****@lists***** > >> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan > >> > >> > >> > > > > > > > > > -- > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > 加納 峻佑 (Shunsuke,Kano) > 株式会社 シンプレクス・テクノロジー > 〒106-6016 > 東京都港区六本木1-6-1 泉ガーデンタワー16F > mailto:kano.****@simpl***** > TEL: 03-5545-7870 > FAX: 03-5545-7875 > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan
Fork