著者：未完成交響曲
異常な
まず、我々はインターフェイス要求のhttpタイムアウトの数が多い、アプリケーションがまだ異常で再起動し、問題なく、それ自体が異常を判定するために実行されるアプリケーションをLinuxサーバのネットワーク環境を確認するにはログイン、検索、オンラインジャーナルのプラットフォームのJavaアプリケーション環境を発見した社内で構築されました問題。
予備的な質問を探します
命令によって：ビューGCのJVMメモリフットプリントと条件-gcutil JSTAT：
これは、メモリ使用量は、古い年の高すぎる割合であることがわかった、と毎回fullGC後の効果的な回復はなかったです。次のように歳のメモリ使用率の変更は次のとおりです。
予備判決多数の要求の直接の原因の麻痺はタイムアウトとサービス：
fullGCのメモリフットプリントのそれぞれが増加した後、
メモリ使用量をより速く成長し、より速く
高く高くfullGC周波数
最終占有率が100％に達し、サービスが完全に麻痺し
分析処理
説明書を使用する：jmapの-histo：ライブ*** |より多くのヒープメモリ内のオブジェクトの数とサイズを確認するには
多くのLog4jLogEventこのオブジェクトのインスタンスは、メモリも非常に大きい取ることが判明し、予備的な分析は、非同期ログ転送速度でメモリ内に蓄積ログオブジェクトで、その結果、維持することはできません。
、単一の伝送水路の量を増やし、最大遅延時間を短縮：送信ログ水路は、調整パラメータを使用しようとする
アプリケーションは、状況を呼び出して再起動すると、インターフェイスが通常の状態に一時的に戻ってアプリケーションを見つけ監視します。
その後の分析
jmapの-dump：リアルタイムで導出形式= B、ファイル= heapDump.hprofメモリ情報（一時的な問題は、その後の分析で処理されているように、ダンプ処理が比較的遅い）、マットの使用の分析命令を用いてメモリながら、前のステップの分析メモリ構造：
あなたはそれが本当に水路非同期転送ログジャムの問題である、オブジェクトの主な情報は、ヒープメモリを占有見ることができます。
概要
問題を見つけるために、主にうまく利用して、類似したJSTAT JVM提供、jmapのおよび他の分析ツールをこのような問題を解決するために、JVMのメモリリーク。一方で、この問題を解決するが、そのような問題のその後の再発のリスクが依然としてあります。だから、JVMのトラブルシューティング機能の強化に加えて、我々はまた、問題の早期発見を容易にするため、JVMのメモリ、スレッド、および他のリアルタイムパフォーマンス指標を監視することを期待して、議題にアプリケーション監視プラットフォームを確立することを計画しています。
サポートのおかげで、ヨーヨーの記事を覚えて賞賛のポイントのように、みんなと共有へようこそ！