From nakano.hiroaki ＠ nttcom.co.jp Thu Oct 6 17:54:41 2011 From: nakano.hiroaki ＠ nttcom.co.jp (=?ISO-2022-JP?B?GyRCQ2ZMbiEhOShPLxsoQg==?=) Date: Thu, 06 Oct 2011 17:54:41 +0900 Subject: [Ultramonkey-l7-develop 727] Re: =?iso-2022-jp?b?GyRCJUElZSE8JUslcyUwJU4lJiVPJSZDViQtPmwbKEI=?= In-Reply-To: <20111005.165707.1115292292773412545.tateishi.katsuyuki@oss.ntt.co.jp> References: <4E8AA86D.8000408@nttcom.co.jp> <4E8AB346.1080406@nttcom.co.jp> <20111005.165707.1115292292773412545.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: <4E8D6CD1.7090104@nttcom.co.jp> 中野＠幕張です。 (2011/10/05 16:57), TATEISHI Katsuyuki wrote: > 中野さま、 > 立石です。お疲れさまです。 > > 中野　宏朗-san wrote: > >> >>>> 付録のほうのCFSの設定項目ですが、RHEL6.0→6.1になって、また >>>> パラメータが変わってるみたいです。 >>>> 気が向いたら、RHEL6.1カーネルを調べてみます。 >>> >>> よろしくお願いします． >>> >>> それにしても，ip_conntrack は盲点でした・・・． >>> 他にも，LB では使いそうもない iptables 関連のロードモジュールの >>> あたりは付けられますか？ >> >> どうでしょう。ip_conntrackを削除しようとすると、たぶん関連モジュールを >> 依存関係上消していかないといけないので、自然と使いそうもないものを >> 削除することになると思います。 >> 他には特になかったか、あってもCPUを食ってるものではなかったです。 >> nf_conntrackに目をつけたのは、Oprofileをとったら、sessionlessの試験 + >> iptables使っていないのに、conntrackがCPUをそれなりに食ってたからですｗ >> >> ただ、tproxyを使う場合はiptablesを使うので、ip_conntrackは消せなくなると >> 思います。 >> この辺は導入するケースによりけりですね。まあ、チューニング手法なので、シ >> ステムで変わります。 > > tproxy を使わない場合でも、state モジュールが conntrack に依 > 存してるようなので、動的なルールが使えなくなります。これは > iptables をファイアウォールとして使う場合はかなり厳しい制限です。 > > また、conntrack を外すと性能がアップする、というのは UM-L7 > に限った話でもなさそうですし、どうしてもあと数パーセントの性 > 能を出したい場合の最終手段ですかね。 ですです。 チューニングなんてのは、システムによって異なって当然なので、 conntrackが必要と予測されるシステムならば、外さなければいいのです。 あの資料は、あくまで「検証環境で遅くなるボトルネックを見つけて、 速くなる対処」を求められた結果なので、環境が異なればまた変わります。 ということで、決して万能扱いしないようにｗ > ちなみに、性能を確認されたときは kernelパラメータ > nf_conntrack_max はチューニングされてましたでしょうか。あまり > に小さい値だと同時接続数が多い場合にはこの値が性能に影響する > 場合があります。 > 搭載メモリで初期値は変わるはずですし、実際に追跡中のコネクショ > ン数がこの値に到達すると新しい通信を開始できなくなるので、未 > 設定でも問題ない値になっているか、エラーとかで気づく可能性が > 高いとは思いますが念のため確認させてください。 もう検証環境がハードウェアごと撤去されて、何も残ってないので 確認しようがありません＾＾；が、たしかチューニングされてたような。 もっとも、iptables -L で、チェーンがすっからかんだったので、 追跡中コネクションはまったくないとは思います。 アプリケーションレイヤもhttpで、ftpとか使ってたわけじゃないし。 > スケジューラについてはシステム全体に影響するパラメータだと思 > いますので、UM-L7専用サーバでない環境における他への影響が気に > なります（たとえば httpd と同居する場合とか）。 > 何か情報をお持ちであれば、共有していただければと思います。 これも、万能な解はないので、システムごとに自分で判断しないと いけないです。 # なので、技術者の出番があるともいえます。 少なくとも、判断できる最低限の情報は、資料に書いたつもりです。 httpdがどのNIC使ってるかとか、connect、listen、acceptを マルチスレッドもしくはマルチプロセスで、どういう実装で行って いるかとか、待ち合わせをhttpdがどうやっているかに依存します。 httpd以外にも気になるやつがいれば、それらについても同様に 実装に依存します。 それらをわかってやらないといけないので、(神経質にやるとw)大変です。 まあ、サーバプログラムなんて大体決まった実装方法があったりして、 UM-L7よりも洗練された実装だったりするので、UM-L7より影響が 少ない気がしますw ちなみにPostgreSQLは、たぶんあのCFSのチューニングでトランザクション 量が改善します。 それは、PostgreSQLがロックの実装を独自のスピンロックで行っていて、 それのスリープと起床で、あのパラメータが効くからです。 その辺の話は、DB-Gの大塚くん、OS-Gの伊藤さん、フェルあたりが 知っています。＞って、完全に内輪話になってしまったｗ サーバプログラムなんて、頻繁にコンテキスト切り替えて インタラクティブ性を重視するようなものじゃないので、 悪い影響はでない、むしろ良いんじゃないかと思いますけどね。 「UM-L7サーバの上で、X立ち上げてFirefox動かしたら、クリックした後 反応が0.5秒ほど遅い！問題だ！！ヽ(｀Д´)ノ」とかいうんで なければｗｗｗ -- 中野 宏朗 (NAKANO Hiroaki) NTTコムウェア 品質生産性技術本部 技術SE部 基盤ソフトSE・OSS部門 OSS適用推進担当 Tel: 043-211-2452 (Ext: 特番+26-8341), Fax: 043-211-5086 Zip/Address: 261-0023 千葉県千葉市美浜区中瀬1-6 NTT幕張ビル21F-En From tateishi.katsuyuki ＠ oss.ntt.co.jp Thu Oct 6 18:52:11 2011 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Thu, 06 Oct 2011 18:52:11 +0900 (JST) Subject: [Ultramonkey-l7-develop 728] Re: =?iso-2022-jp?b?GyRCJUElZSE8JUslcyUwJU4lJiVPJSZDViQtPmwbKEI=?= In-Reply-To: <4E8D6CD1.7090104@nttcom.co.jp> References: <4E8AB346.1080406@nttcom.co.jp> <20111005.165707.1115292292773412545.tateishi.katsuyuki@oss.ntt.co.jp> <4E8D6CD1.7090104@nttcom.co.jp> Message-ID: <20111006.185211.1422951639833041055.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。 中野　宏朗 -san wrote: >>>>> 付録のほうのCFSの設定項目ですが、RHEL6.0→6.1になって、また >>>>> パラメータが変わってるみたいです。 >>>>> 気が向いたら、RHEL6.1カーネルを調べてみます。 >>>> >>>> よろしくお願いします． >>>> >>>> それにしても，ip_conntrack は盲点でした・・・． >>>> 他にも，LB では使いそうもない iptables 関連のロードモジュールの >>>> あたりは付けられますか？ >>> >>> どうでしょう。ip_conntrackを削除しようとすると、たぶん関連モジュールを >>> 依存関係上消していかないといけないので、自然と使いそうもないものを >>> 削除することになると思います。 >>> 他には特になかったか、あってもCPUを食ってるものではなかったです。 >>> nf_conntrackに目をつけたのは、Oprofileをとったら、sessionlessの試験 + >>> iptables使っていないのに、conntrackがCPUをそれなりに食ってたからですｗ >>> >>> ただ、tproxyを使う場合はiptablesを使うので、ip_conntrackは消せなくなると >>> 思います。 >>> この辺は導入するケースによりけりですね。まあ、チューニング手法なので、シ >>> ステムで変わります。 >> >> tproxy を使わない場合でも、state モジュールが conntrack に依 >> 存してるようなので、動的なルールが使えなくなります。これは >> iptables をファイアウォールとして使う場合はかなり厳しい制限です。 >> >> また、conntrack を外すと性能がアップする、というのは UM-L7 >> に限った話でもなさそうですし、どうしてもあと数パーセントの性 >> 能を出したい場合の最終手段ですかね。 > > ですです。 > チューニングなんてのは、システムによって異なって当然なので、 > conntrackが必要と予測されるシステムならば、外さなければいいのです。 > > あの資料は、あくまで「検証環境で遅くなるボトルネックを見つけて、 > 速くなる対処」を求められた結果なので、環境が異なればまた変わります。 > > ということで、決して万能扱いしないようにｗ そうですね、もともと iptables を完全に止めていて関係ない場合 もあるでしょうし。 > >> ちなみに、性能を確認されたときは kernelパラメータ >> nf_conntrack_max はチューニングされてましたでしょうか。あまり >> に小さい値だと同時接続数が多い場合にはこの値が性能に影響する >> 場合があります。 >> 搭載メモリで初期値は変わるはずですし、実際に追跡中のコネクショ >> ン数がこの値に到達すると新しい通信を開始できなくなるので、未 >> 設定でも問題ない値になっているか、エラーとかで気づく可能性が >> 高いとは思いますが念のため確認させてください。 > > もう検証環境がハードウェアごと撤去されて、何も残ってないので > 確認しようがありません＾＾；が、たしかチューニングされてたような。 > もっとも、iptables -L で、チェーンがすっからかんだったので、 > 追跡中コネクションはまったくないとは思います。 了解です。 > > アプリケーションレイヤもhttpで、ftpとか使ってたわけじゃないし。 > >> スケジューラについてはシステム全体に影響するパラメータだと思 >> いますので、UM-L7専用サーバでない環境における他への影響が気に >> なります（たとえば httpd と同居する場合とか）。 >> 何か情報をお持ちであれば、共有していただければと思います。 > > これも、万能な解はないので、システムごとに自分で判断しないと > いけないです。 > # なので、技術者の出番があるともいえます。 > 少なくとも、判断できる最低限の情報は、資料に書いたつもりです。 > > httpdがどのNIC使ってるかとか、connect、listen、acceptを > マルチスレッドもしくはマルチプロセスで、どういう実装で行って > いるかとか、待ち合わせをhttpdがどうやっているかに依存します。 > > httpd以外にも気になるやつがいれば、それらについても同様に > 実装に依存します。 > それらをわかってやらないといけないので、(神経質にやるとw)大変です。 > > まあ、サーバプログラムなんて大体決まった実装方法があったりして、 > UM-L7よりも洗練された実装だったりするので、UM-L7より影響が > 少ない気がしますw > > ちなみにPostgreSQLは、たぶんあのCFSのチューニングでトランザクション > 量が改善します。 > それは、PostgreSQLがロックの実装を独自のスピンロックで行っていて、 > それのスリープと起床で、あのパラメータが効くからです。 PostgreSQLについての情報ありがとうございます。 httpd と同居する可能性が高いと思うので、気になる場合は一度 httpd について調べておいたほうが良さそうですね。 > サーバプログラムなんて、頻繁にコンテキスト切り替えて > インタラクティブ性を重視するようなものじゃないので、 > 悪い影響はでない、むしろ良いんじゃないかと思いますけどね。 応答性よりもスループットって感じですかね。 UM-L7ェ・・・ > > 「UM-L7サーバの上で、X立ち上げてFirefox動かしたら、クリックした後 > 反応が0.5秒ほど遅い！問題だ！！ヽ(｀Д´)ノ」とかいうんで > なければｗｗｗ たしかにw -- TATEISHI Katsuyuki