![GlassFish インスタンスを使用した mod_jk を使用した Apache、少数のユーザーに対して多数の接続が確立される](https://rvso.com/image/617796/GlassFish%20%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%20mod_jk%20%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%20Apache%E3%80%81%E5%B0%91%E6%95%B0%E3%81%AE%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%81%AB%E5%AF%BE%E3%81%97%E3%81%A6%E5%A4%9A%E6%95%B0%E3%81%AE%E6%8E%A5%E7%B6%9A%E3%81%8C%E7%A2%BA%E7%AB%8B%E3%81%95%E3%82%8C%E3%82%8B%20.png)
ポータルの運用サーバーをチューニングしています。サーバーは 4 台あり、2 台は Web 用、2 台はアプリケーション用です。Web サーバーの前後にファイアウォールがあります (つまり、アプリケーション サーバーと Web サーバーの間にファイアウォールがあります)。ここでの問題は、ファイアウォールによってアプリケーション サーバーと Web サーバー間のアイドル接続が切断されたことから始まりました。多くの解決策を試しましたが、今では、ファイアウォールからの切断が原因でアプリケーションでスタックしていた壊れた接続が問題になっているようです。この問題は、ポータルへの負荷が低いときに発生し、解決するにはすべてのアプリケーション サーバーを再起動する必要がありましたが、今は代わりに負荷の高い日に問題が発生しています。緊急の解決策は、Apache Web サーバーをすばやく再起動することでした。この問題を解決する方法を教えてください。
Jboss ロードバランシング構成ジェネレーターの助けを借りて変更を加えました:http://lbconfig.appspot.com/?lb=mod_jk&mjv=1.2.28&nca=64&ncj=64&nai=2&nji=2&njips=6&f=true&c=false&lr=false&lrl=&mpm=Prefork
また、netstat コマンドと Google Analytics のリアルタイム概要を使用して両方のサーバーの接続を監視したところ、最後の再起動から 3 日後に約 40 人の訪問者に関する次の統計が得られました。
ウェブ側(サーバーは 2 台ですが、接続は「それぞれ」であり、合計ではありません):
ESTABLISHED ~700 - 750
TIME_WAIT: 100-200 (big jumbs for one second 150 another 200 another 170 and then 120 and so)
アプリ側(ここでは、すべての接続を数えました。チェックするたびに、そのほとんどは ESTABLISHED で、少数は CLOSE_WAIT 0 - 5 でした):
S1 (4 instances running) : 900-950
S2 (5 instances running) : 1000-1100
サーバーの詳細:
- Web 2x サーバーの場合: Apache 2.2.14 / mod_jk 1.2.37
- アプリ 2x サーバー: ajp13 を使用した Clustered Glassfish 2.1.1 (各サーバーに 6 つのインスタンス)
- すべてのサーバーは Solaris SPARC 64 V-CPU、32GB の RAM を搭載しています。
私の設定: ジェネレータが私に与えたものとほぼ同じです(リンクを参照)。
conf: に次のように入力します。
KeepAlive On
ServerLimit 12800
StartServers 5
MinSpareServers 5
MaxSpareServers 20
MaxClients 12800
MaxRequestsPerChild 5000
ExtendedStatus Off
ワーカープロパティ:
worker.maintain=30
worker.template.type=ajp13
worker.template.session_cookie=JSESSIONID
worker.template.lbfactor=1
worker.template.ping_timeout=10000
worker.template.connection_pool_timeout=10
worker.template.socket_keepalive=True
worker.template.socket_timeout=600
worker.template.connect_timeout=10000
worker.template.prepost_timeout=10000
worker.template.connection_ping_interval=20
worker.template.ping_mode=A
worker.template.socket_connect_timeout=600000
グラスフィッシュ側からクラスター構成側から 10 秒のタイムアウトを設定します。
HTTP サービス プロパティ:
- 接続タイムアウト = 10000
リクエスト処理:
- スレッド数: 2133
- 初期スレッド数: 20
- スレッド増分: 10
キープアライブ(有効):
- スレッド数: 400
- 最大接続数 256
- タイムアウト: 10秒
接続プール:
- 最大保留数 4096 接続
それで:
- 私の設定は正しいのでしょうか?
- 確立された接続の数が多い場合の解決方法、または安全方法を教えてください。負荷が再び高くなった場合に Apache のダウンタイムを再度発生させたくありません。
答え1
mod_jk / mod_ajp について: 私たちはこれを少し大きめのセットアップで使用しましたが、バグやエラーが時々発生し、接続が切断されることもありましたが、問題の本当の解決策は見つかりませんでした (ただし、まだ存在するバグもいくつか見つかりました)
私のアドバイス: 代替セットアップとパフォーマンス テスト (mod_jk と proxy_http) を作成し、proxy_http が許容範囲内であれば mod_jk をスキップしてください。私は現在、2 つの異なるセットアップでこれを実行しました (さらに、apache を nginx に置き換えることもでき、大成功です)。後悔はしていません。
長所
- デバッグが容易
- より多様な lb/フロントエンド ゲートウェイ (haproxy、nginx、varnish) が使用可能
- ハイゼンバグが少ない
短所
- 見つけられなかった