忙しい時間帯でも、本番環境でオーバーヘッドの少ない方法でJVMメモリモニターを行う方法を考えています。
本番環境に2つのtomcatアプリサーバーがあり、それらの背後に負荷分散が設定されているとします。jvmメモリー統計を表示できる場合は、OOMの問題が発生するサーバーへのリクエストの送信を停止するようにロードバランスに指示できます。これは理にかなっていますか?JconsoleまたはVisualVMがより多くのパフォーマンスリソースを消費するのは私の選択ではありません。
忙しい時間帯でも、本番環境でオーバーヘッドの少ない方法でJVMメモリモニターを行う方法を考えています。
本番環境に2つのtomcatアプリサーバーがあり、それらの背後に負荷分散が設定されているとします。jvmメモリー統計を表示できる場合は、OOMの問題が発生するサーバーへのリクエストの送信を停止するようにロードバランスに指示できます。これは理にかなっていますか?JconsoleまたはVisualVMがより多くのパフォーマンスリソースを消費するのは私の選択ではありません。
回答:
JMXが答えになります(JolokiaはJMXインターフェースです)。
あなたはまた見たいかもしれません -/programming/242958/best-tools-to-monitor-tomcat
他の人は、メモリ使用量を監視する方法についての提案を提供しています...
本番環境に2つのtomcatアプリサーバーがあり、それらの背後に負荷分散が設定されているとします。jvmメモリー統計を表示できる場合は、OOMの問題が発生するサーバーへのリクエストの送信を停止するようにロードバランスに指示できます。これは理にかなっていますか?
ちょっと。しかし、それは必ずしも問題を解決するための最良の方法ではありません。
問題の根本に戻ってみましょう... OOME。Tomcatのコンテキストでは、OOMEは次のいずれかによって引き起こされる可能性があります。
あなたの問題を解決するには、最初にこれらのどれが起こっているかを知る必要があります...解決策はそれぞれで異なります。
1)これがメモリリークかどうかを確認するには、メモリ分析ツールを使用して長期的なメモリ使用パターンを調べる必要があります。これはおそらく鋸歯状のパターンを示します...これは正常です。あなたが探す必要があるのは、時間とともに上昇する「歯」の底のレベルです。これは、何かが収集できないゴミを作成していることを示しています。つまり、メモリリークです。
メモリリークがある場合、最善の解決策は、コードのどの部分が原因であるかを特定し、修正することです。それ以外のもの...ロードバランシングを含む...は応急処置ソリューションであり、将来的に問題を悪化させる可能性があります。
2)メモリリークを解消したら、一度に処理する要求が多すぎることが問題であるかどうかを把握する必要があります。それを行うための最良の方法はわかりませんが、これが問題である(または問題があると思われる)場合は、いくつかの解決策があります。
Tomcatサーバー構成を調整して、ワーカースレッドの数を減らします。
リクエストがI / Oバウンドの場合、別の可能性は、サーブレット仕様の最新バージョンで利用可能な非同期リクエスト処理サポートを調べることです-http://docs.oracle.com/javaee/7/tutorial/doc/を参照してくださいservlets012.htm。しかし、それはより多くの仕事になります。
3)特定のリクエストがメモリを使いすぎていることが問題であることが判明した場合、それらのリクエストを事前に検出して「対処する」方法を理解する必要があります。これらのリクエストの検出と処理はどちらも難しい場合があります。アプリケーションの詳細なしにアドバイスするのは困難です。しかし、いくつかの実用的なソリューションは次のとおりです。
異常な要求を大きなヒープを持つ別のサーバーに転送します。OOMEは「通常の」要求を妨害しません。
ヒープサイズを増やします。十分な物理メモリがある場合、より大きなヒープで実行すると、実際にはTomcatサーバーの効率が向上するだけでなく、OOMEも回避できます。
要約すると、OOMEを回避するために負荷分散を試みるのではなく、OOME を取得する理由を理解し、OOMEの原因に直接対処することをお勧めします。
たぶん、jvmtopは一見の価値があります。
メモリ使用量、CPU使用率、スレッド数などのメトリックを監視する「トップライク」な方法で、JVMごとに表示します。