From hibari.michiro ＠ lab.ntt.co.jp Thu Jan 23 09:16:31 2014 From: hibari.michiro ＠ lab.ntt.co.jp (Hibari Michiro) Date: Thu, 23 Jan 2014 09:16:31 +0900 Subject: [Ultramonkey-l7-develop 1030] Re: [RFP] using SO_REUSEPORT on UltraMonkey-L7 In-Reply-To: <52DF7245.7060806@nttcom.co.jp> References: <52D77651.3040601@nttcom.co.jp> <52DF7245.7060806@nttcom.co.jp> Message-ID: <52E05F5F.8030006@lab.ntt.co.jp> 中野さま ひばりです。 おはようございます。 > V2ではl7vs_maxvsでVS数を制限できるオプションが > あったみたいですが、このオプションの必要性が > 知りたいです。 l7vsadmコマンドで表示できるVS数に上限があって、 それを超えないようにl7vs_maxvsでVS数を制限 しているのだと思います。 私が知っている範囲で思い当たるのは上記のみです。 他にも理由があるのかもしれませんが・・・ (2014/01/22 16:24), Hiroaki Nakano wrote: > 中野@幕張です。 > V2時代を知っている人に質問です。 > > V2ではl7vs_maxvsでVS数を制限できるオプションが > あったみたいですが、このオプションの必要性が > 知りたいです。 > > virtual service自体はGLibの双方向リンクリスト > で管理されてるので、配列とかと違って最大値を > 事前に設定せずともメモリのある限りアイテムは増やせるはず。 > epollのmax eventとかに関連があるんでしょうか？ > > > 子プロセス化の際、複数プロセスをもつVSを > 1として数えるのか、子プロセスを1として数えるのか > どっちにしなきゃいけないのかなー、と思って。 > > ・・・それともなんとなく最大値設定できるように > しただけで、特に意味はないとか？ > > (2014/01/16 15:04), Hiroaki Nakano wrote: >> 中野@幕張です。 >> >> SO_REUSEPORTの使い方をいろいろ検討してみた >> ので、とりあえず提案してみます。 >> >> [Abstruct] >> ・RHEL7よりSO_REUSEPORTというソケットオプションが追加されます。 >> 　これは同じIPアドレス、同じport番号で複数のソケットをlisten状態で >> 　待ち受けることができ、かつacceptをするときはOSが適宜ランダムに >> 　一つのソケットを選んでacceptさせる、という機能です。 >> 　kernel3.9から実装されています。概要はLWN.netの以下の記事で。 >> >> 　https://lwn.net/Articles/542629/ >> >> 　これを使ってUltraMonkey-L7で何か利点がないかなー、と検討しました。 >> >> [Useage SO_REUSEPORT] >> ・使ってみた人がいました。 >> >> 　http://umezawa.dyndns.info/wordpress/?p=3944 >> >> 　この人のプログラムのように、同じIPアドレス、ポート番号に対して >> 　一つのプロセス(スレッド)で独立したsocketインスタンスを作って、 >> 　そのプロセス(スレッド)を複数作ることができます。 >> 　一つのcontext内で、open, bind,listen, accept, closeを >> 　完結させることができます。 >> 　該当IPアドレス、ポートにパケットが到着したとき、どのsocket >> 　インスタンスでacceptするかはkernelが良しなに振ってくれます。 >> >> [Suggesting UltraMonkey-L7 design using SO_REUSEPORT] >> ・V3ではopen, bind, listenをvirtualserviceスレッドで、 >> accept待ちを1つのセッションスレッドでやって、 >> accept以降の処理を並列化している構造。 >> 　これを、上記のようにopenからそれぞれのスレッド内で完結するように >> 　改造するのは大変そう・・・ >> ・同じIP,portに対して完全に独立したsocketを起こせるなら、 >> 　スレッドにしなくても子プロセスでいいんじゃないだろうか。 >> 　各スレッドがアクセスする大域変数も必要なくなりそうだし、 >> 　起動コストも事前にpreforkとして起動するようにすれば通信時には問題ない。 >> >> →ということは、V3ベースに改造するより、V2を子プロセス化したほうが >> 　まだ楽なんじゃないか？ >> >> ・ただし、SSLは実装しなきゃだし、SNMPもないし、バグとかも >> 　V3に比べてまだ残ってそう(X-Forwarded-Forとか)。それらを >> 　実装、直すのと、V3の構造を作り直すのではどちらが楽だろうか・・・ >> 　個人的には、V2ベースの方が楽そう。 >> >> ・あと、子プロセス化して独立したsocketインスタンスを生成するので >> 　あれば、SSL通信が速くなるのではないだろうか。 >> 　→V3でSSLが遅いのはOpenSSLがまともにMultiThread対応してなくて、 >> 　　証明書等スレッド間共有メモリにmutex掛けながら1スレッドずつ >> 　　アクセスしなきゃいけないのが原因だし。 >> 　　子プロセス内完結なら、SSLも独立したインスタンスになって、 >> 　　SSLを並列化できるんじゃないだろうか。 >> >> ということで、V2ベースでSO_REUSEPORT使って子プロセス並列化 >> というのを考えているのですが、どうでしょうか。 >> >> いや、V3ベースの方が楽じゃね？とか、 >> SSL並列化は無理じゃね？とか意見あったらお聞かせください。 >> > -- 雲雀　路朗 (Michiro Hibari) MAIL: hibari.michiro ＠ lab.ntt.co.jp 所属: NTT OSSセンタ 基盤技術ユニット 高信頼担当 TEL : 03-5860-5135 / FAX: 03-5463-5490 From nakano.hiroaki ＠ nttcom.co.jp Thu Jan 23 10:52:15 2014 From: nakano.hiroaki ＠ nttcom.co.jp (Hiroaki Nakano) Date: Thu, 23 Jan 2014 10:52:15 +0900 Subject: [Ultramonkey-l7-develop 1031] Re: [RFP] using SO_REUSEPORT on UltraMonkey-L7 In-Reply-To: <52E05F5F.8030006@lab.ntt.co.jp> References: <52D77651.3040601@nttcom.co.jp> <52DF7245.7060806@nttcom.co.jp> <52E05F5F.8030006@lab.ntt.co.jp> Message-ID: <52E075CF.3040401@nttcom.co.jp> 中野@幕張です。 (2014/01/23 9:16), Hibari Michiro wrote: > 中野さま > > ひばりです。 > おはようございます。 おはようございます。 >> V2ではl7vs_maxvsでVS数を制限できるオプションが >> あったみたいですが、このオプションの必要性が >> 知りたいです。 > l7vsadmコマンドで表示できるVS数に上限があって、 > それを超えないようにl7vs_maxvsでVS数を制限 > しているのだと思います。 > > 私が知っている範囲で思い当たるのは上記のみです。 > 他にも理由があるのかもしれませんが・・・ ありがとうございます。 表示上の問題でしたか。 ちょっとしょぼい理由・・・ｗ なら複数プロセス分のVSを1VSとして数える 仕様でよさそうですね。 l7vs_serviceのデータ構造をちっと見直さないと 対応できないかなぁ。 > (2014/01/22 16:24), Hiroaki Nakano wrote: >> 中野@幕張です。 >> V2時代を知っている人に質問です。 >> >> V2ではl7vs_maxvsでVS数を制限できるオプションが >> あったみたいですが、このオプションの必要性が >> 知りたいです。 >> >> virtual service自体はGLibの双方向リンクリスト >> で管理されてるので、配列とかと違って最大値を >> 事前に設定せずともメモリのある限りアイテムは増やせるはず。 >> epollのmax eventとかに関連があるんでしょうか？ >> >> >> 子プロセス化の際、複数プロセスをもつVSを >> 1として数えるのか、子プロセスを1として数えるのか >> どっちにしなきゃいけないのかなー、と思って。 >> >> ・・・それともなんとなく最大値設定できるように >> しただけで、特に意味はないとか？ >> >> (2014/01/16 15:04), Hiroaki Nakano wrote: >>> 中野@幕張です。 >>> >>> SO_REUSEPORTの使い方をいろいろ検討してみた >>> ので、とりあえず提案してみます。 >>> >>> [Abstruct] >>> ・RHEL7よりSO_REUSEPORTというソケットオプションが追加されます。 >>> 　これは同じIPアドレス、同じport番号で複数のソケットをlisten状態で >>> 　待ち受けることができ、かつacceptをするときはOSが適宜ランダムに >>> 　一つのソケットを選んでacceptさせる、という機能です。 >>> 　kernel3.9から実装されています。概要はLWN.netの以下の記事で。 >>> >>> 　https://lwn.net/Articles/542629/ >>> >>> 　これを使ってUltraMonkey-L7で何か利点がないかなー、と検討しました。 >>> >>> [Useage SO_REUSEPORT] >>> ・使ってみた人がいました。 >>> >>> 　http://umezawa.dyndns.info/wordpress/?p=3944 >>> >>> 　この人のプログラムのように、同じIPアドレス、ポート番号に対して >>> 　一つのプロセス(スレッド)で独立したsocketインスタンスを作って、 >>> 　そのプロセス(スレッド)を複数作ることができます。 >>> 　一つのcontext内で、open, bind,listen, accept, closeを >>> 　完結させることができます。 >>> 　該当IPアドレス、ポートにパケットが到着したとき、どのsocket >>> 　インスタンスでacceptするかはkernelが良しなに振ってくれます。 >>> >>> [Suggesting UltraMonkey-L7 design using SO_REUSEPORT] >>> ・V3ではopen, bind, listenをvirtualserviceスレッドで、 >>> accept待ちを1つのセッションスレッドでやって、 >>> accept以降の処理を並列化している構造。 >>> 　これを、上記のようにopenからそれぞれのスレッド内で完結するように >>> 　改造するのは大変そう・・・ >>> ・同じIP,portに対して完全に独立したsocketを起こせるなら、 >>> 　スレッドにしなくても子プロセスでいいんじゃないだろうか。 >>> 　各スレッドがアクセスする大域変数も必要なくなりそうだし、 >>> 　起動コストも事前にpreforkとして起動するようにすれば通信時には問題ない。 >>> >>> →ということは、V3ベースに改造するより、V2を子プロセス化したほうが >>> 　まだ楽なんじゃないか？ >>> >>> ・ただし、SSLは実装しなきゃだし、SNMPもないし、バグとかも >>> 　V3に比べてまだ残ってそう(X-Forwarded-Forとか)。それらを >>> 　実装、直すのと、V3の構造を作り直すのではどちらが楽だろうか・・・ >>> 　個人的には、V2ベースの方が楽そう。 >>> >>> ・あと、子プロセス化して独立したsocketインスタンスを生成するので >>> 　あれば、SSL通信が速くなるのではないだろうか。 >>> 　→V3でSSLが遅いのはOpenSSLがまともにMultiThread対応してなくて、 >>> 　　証明書等スレッド間共有メモリにmutex掛けながら1スレッドずつ >>> 　　アクセスしなきゃいけないのが原因だし。 >>> 　　子プロセス内完結なら、SSLも独立したインスタンスになって、 >>> 　　SSLを並列化できるんじゃないだろうか。 >>> >>> ということで、V2ベースでSO_REUSEPORT使って子プロセス並列化 >>> というのを考えているのですが、どうでしょうか。 >>> >>> いや、V3ベースの方が楽じゃね？とか、 >>> SSL並列化は無理じゃね？とか意見あったらお聞かせください。 >>> >> > > -- 中野 宏朗 (NAKANO Hiroaki) NTTコムウェア 品質生産性技術本部 技術SE部 基盤ソフトSE・OSS部門 OSS・DB技術担当 Tel: 043-211-2452 (Ext: 特番+26-8341), Fax: 043-211-5086 Zip/Address: 261-0023 千葉県千葉市美浜区中瀬1-6 NTT幕張ビル21F-En From omoikanenomikoto ＠ gmail.com Thu Jan 23 21:06:29 2014 From: omoikanenomikoto ＠ gmail.com (Shinya TAKEBAYASHI) Date: Thu, 23 Jan 2014 21:06:29 +0900 Subject: [Ultramonkey-l7-develop 1032] Re: [RFP] using SO_REUSEPORT on UltraMonkey-L7 In-Reply-To: <52D77651.3040601@nttcom.co.jp> References: <52D77651.3040601@nttcom.co.jp> Message-ID: たけばやし＠東海道線です． 遅レスすみません． 私としては v2 ベースがよいかと思っています． ソケット FD をすべてイベント待ちリスナの iomux に登録して 反応があった FD を取り出して処理をする，というタイプの実装だからです． おそらく SO_REUSEPORT での実装でも同じような作りになると思います．