Hideaki KONDO
kondo****@nttco*****
2011年 3月 3日 (木) 10:07:23 JST
高舘さま お疲れ様です。 近藤です。 トラブル発生の状況報告有難うございます。 なかなかレスが付かないようですので、直接コーディングは行って おりませんでしたが、以前仕様検討には関わっていたこともあり、 以下について私が把握している範囲で回答させて頂きます。 （認識違い等があれば、直接開発やコーディングに関わったメンバ等 指摘やフォローしてもらえると有難いです。） > 1. > l7vsdが落ちる数日前、SSLProxyが停止する別の問題が発生しました。 > 過去ML情報より、SSLProxyのnum_threadパラメータを10⇒1にすれば > 回避できるという情報を入手したのですが、まだ未設定の状態です。 > http://sourceforge.jp/projects/ultramonkey-l7/lists/archive/users/20100126/000279.html > > 上記、SSLProxyの問題がトリガーとなってl7vsdの停止につながるなど、 > 関連性は考えられないでしょうか？ ★ l7vsd と SSLProxy は、独立したプログラムとなっており、 SSLProxy の問題に引きずられて直接的に l7vsd に影響を与えて l7vsd ダウンに至る可能性は、低いと考えられます。 SSLProxy によるメモリ破壊等で間接的に l7vsd が影響を受けることは 考えられますが、この場合は l7vsd だけでなく OS全体が不安定になる はずですので、l7vsd ダウン原因として可能性は低いと考えられます。 > 2. > l7vsdのデフォルト起動スクリプトにて、プロセスの最大fd数を65536に > 設定していると思います。また、l7vs.cfの"max_events"は1024になって > いますが、fdに合せて"max_events"を65536に設定する必要なないのでしょ うか？ > （epollだからOK？） ★ max_events をプロセスの最大fd数に合わせる必要はないです。 max_events を大きくしすぎますと、これまでの性能検証結果からも 分かっておりますが、性能低下の原因になります。 当初の狙いは、epoll() を利用することで、同時接続数を増加させても あまり性能低下にならないことを期待してましたが、実際は max_events が 4096 を超えたあたりからやや顕著に性能低下が見られたと記憶しています。 > また、最大値1024に到達した場合、どのような挙動となるのでしょうか？ ★ 同時に接続できるコネクション数が制限され、使用中のコネクションが(一つ でもよいので)解放されるまで、それ以上コネクション接続できない状態が続く ことになるはずです。（言うまでもなく、最大値1024に達したからといって、 exit(1)等で l7vsd 停止やl7vsd ダウンさせるような仕様ではありません。） 以上、少しでも参考なればと思いレスさせて頂きました。 (2011/02/28 17:11), yosuke takadate wrote: > 高舘です。 > > レプリケーション機能停止後にも、 > l7vsdが落ちる現象が再発してしまいました。 > 停止箇所は、以前お伝えした箇所と同じです。 > >>> (2)ログレベルwarnで落ちる場合 >>> >>> Program terminated with signal 6, Aborted. >>> #0 0x00002b30736de265 in raise () from /lib64/libc.so.6 >>> #1 0x00002b30736dfd10 in abort () from /lib64/libc.so.6 >>> #2 0x00002b307371884b in __libc_message () from /lib64/libc.so.6 >>> #3 0x00002b307372030f in _int_free () from /lib64/libc.so.6 >>> #4 0x00002b307372076b in free () from /lib64/libc.so.6 >>> #5 0x000000000042dc82 in l7vs_conn_send (iom=0x1130e980, >>> dest_fd=<value optimized out>) at conn.c:2923 >>> #6 0x000000000042e78f in l7vs_conn_sending (iom=0x1130e980, >>> another_iom=0x1130e960) at conn.c:1690 >>> #7 0x000000000042f55f in l7vs_conn_rs_callback (iom=0x1130e980) >>> at conn.c:2014 >>> #8 0x000000000040c8f8 in l7vs_iomux_poll (timo=<value optimized >>> out>, blocking=-1) at iomux.c:773 >>> #9 0x000000000040bd04 in main (argc=2, argv=0x7fff6800c0f8) at l7vsd.c: >> 429 >>> > ------------------------------------------ > > いくつか教えて頂いてよろしいでしょうか？ > > 1. > l7vsdが落ちる数日前、SSLProxyが停止する別の問題が発生しました。 > 過去ML情報より、SSLProxyのnum_threadパラメータを10⇒1にすれば > 回避できるという情報を入手したのですが、まだ未設定の状態です。 > http://sourceforge.jp/projects/ultramonkey-l7/lists/archive/users/20100126/000279.html > > 上記、SSLProxyの問題がトリガーとなってl7vsdの停止につながるなど、 > 関連性は考えられないでしょうか？ > > > 2. > l7vsdのデフォルト起動スクリプトにて、プロセスの最大fd数を65536に > 設定していると思います。また、l7vs.cfの"max_events"は1024になって > いますが、fdに合せて"max_events"を65536に設定する必要なないのでしょうか？ > （epollだからOK？） > また、最大値1024に到達した場合、どのような挙動となるのでしょうか？ > > > > 2011年2月22日10:19 Hideaki KONDO<kondo****@nttco*****>: >> 高舘様 >> >> 近藤です。 >> 度々すみません。 >> >> もう一点補足です。 >> >>>> そもそもこの機能は、使用するプロトコルモジュールによって >>>> 意味のあるものとないものが存在し、無理に設定しなくても運用上 >>>> 問題ない場合が多いかと思います。 >> >> 先に送付されておりました設定ファイル(l7directord.cf)を >> 参照させて頂きましたら、プロトコルモジュールはすべて >> 「sessionless」でしたので、特別な意図がない限り、 >> レプリケーション機能は「無効」でよいかと思います。 >> >> レプリケーション機能は、sslidモジュールやipモジュールなど >> パーシステンス系のモジュールを使用する場合に、ActからSby側へ >> パーシステンス情報を障害切り替え時に備えて定期的に同期する >> ために実装されていたはずですので。 >> >> 以上です。 >> >> >> (2011/02/22 9:57), Hideaki KONDO wrote: >>> >>> 高舘様 >>> >>> 近藤です。 >>> >>> すみません。 >>> すでに(1)の起動モードについては、試されていたのですね。 >>> >>>>>>>> 現在、起動モードをブロッキングモードに変更し、CoreDump設定を >>>>>>>> 投入して静観中です。 >>> >>> ブロッキングモードで動作させた場合、l7vsdプロセスダウン発生頻度に >>> 変化等があるようであれば、共有頂ければ、竹林さん等の原因解析にも >>> 少し役立つと思いますので、よろしくお願いします。 >>> >>> >>> (2011/02/22 9:51), Hideaki KONDO wrote: >>>> >>>> 高舘様 >>>> >>>> お疲れ様です。 >>>> 近藤と申します。 >>>> >>>> 直接のUM-L7開発からは遠ざかっているので、あまり参考に >>>> ならないかも知れませんが、Ver.2.1.x頃の状況を知るものとして >>>> 障害状況から考えて、環境的に少々気になるところがあります。 >>>> お時間があれば、切り分けの意味で試してみては如何でしょうか。 >>>> >>>> (1) >>>> 起動モードについては、「non-blocking」を選択されておりますが、 >>>> 性能的には1〜2割程度しか変わらず、CPU使用率やおそらく安定性( >>>> 諸事情から動作検証はblockingモードの方が多くされてきていました） >>>> の面でも有利な「blocking」モードを試して切り分けされては如何で >>>> しょうか。 >>>> この起動モードが、オーバーフローや二重free等の障害に間接的に >>>> 関係している可能性があるかも知れません。 >>>> もしl7vsdプロセスダウンが発生しなくなったり、発生頻度に変化が >>>> あれば、関係している可能性が高いと思います。 >>>> >>>> (2) >>>> レプリケーション機能を「有効」にして利用されておりますが、 >>>> 可能であれば一度「無効」にして様子をみては如何でしょうか。 >>>> こちらもl7vsdプロセスダウンの発生頻度の違いを確認した方がよい >>>> かと思います。 >>>> 開発当時はそれなりに動作検証がなされてきてましたが、私の知る限り >>>> 長期間使用した実績がなく、あまり利用を推奨していなかった記憶が >>>> あります。 >>>> そもそもこの機能は、使用するプロトコルモジュールによって >>>> 意味のあるものとないものが存在し、無理に設定しなくても運用上 >>>> 問題ない場合が多いかと思います。 >>>> >>>> 以上、少しでも参考になればと思い、レスさせて頂きました。 >>>> >>>>>>>> 高舘と申します。 >>>>>>>> l7vsdプロセスが落ちるという問題が発生しており >>>>>>>> 原因を調査中です。 >>>>>>>> >>>>>>>> >>>>>>>> 環境 >>>>>>>> CentOS5.5 (2.6.18-194.32.1.el5xen x86_64) >>>>>>>> UltraMonkey-l7 2.1.3 >>>>>>>> 起動モード: non-blocking >>>>>>>> heartbeatによるHA構成 >>>>>>>> -l7vsdはクローンで正副2台で稼働 >>>>>>>> -レプリケーションは有効 >>>>>>>> >>>>>>>> 設定 >>>>>>>> ※設定ファイルを別途添付させて頂きます >>>>>>>> >>>>>>>> 発生頻度 >>>>>>>> ほぼ1日に1回のペース >>>>>>>> アクセスがあまりない時期に落ちることはありませんでしたが >>>>>>>> 定量的なアクセスの増加時に発生するようになりました >>>>>>>> >>>>>>>> ログ >>>>>>>> ログレベルはすべて"warn"レベルにしておりましたが、 >>>>>>>> 停止前にログは出力されておりませんでした。 >>>>>>>> 一度"debug"レベルに変更してみたのですが、別の問題（恐らく下記URLが原因↓） >>>>>> で >>>>>>>> l7vsdプロセスが停止してしまう状況となりログからの調査が難しくなっております >>>>>>>> http://sourceforge.jp/projects/ultramonkey-l7/lists/archive/develop/20100802/000627.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 現在、起動モードをブロッキングモードに変更し、CoreDump設定を >>>>>>>> 投入して静観中です。 >>>>>>>> >>>>>>>> 似たような問題が発生した方、回避方法など知見をお持ちの方がいましたら >>>>>>>> ご教示頂けたらと思い、ご連絡させて頂きました。 >>>>>>>> >>>>>>>> よろしくお願い致します。 >>>> -- Hideaki Kondo
UltraMonkey-L7
Fork