問題を再現するために、
2020年の新年は、オンラインGCを問題のトラブルシューティングを行います。最も直感的な現象は、1月2日、オンラインクエリサービスElasticsearchは、ほぼ同じ時刻に、ビジネスデータのクエリページのエラーを報告し、リアルタイムのフィードバック突然のアラームです。同時に、バックログのjava.lang.OutOfMemoryErrorを参照してください。GCoverheadlimitexceeded、Eurakeは、サービスページを登録されたハートビートが検出されないた、除外サービスのレジストリリストからサービスへのイニシアチブをとります。緊急時、このサービスのクラスタノードが最初に表示され、最近では驚きで、ビットを反復なしのバージョンを更新しました。すぐに、サービス、大-Xms1024m -Xmx1024m転送する元-Xms128m -Xmx512mの値を復元し、その優先順位はビジネスユースを確保するための措置を講じ、正常にサービスバックを再開し、通常のバックグラウンドを記録し、すべてが正常なようです。
理由の調査
エラーの開始後しばらくのビジネスは、タイムアウトの出現に対応するインタフェースページのネットワークを解析することにより、バックエンドのインタフェース発見を要求します。いくつかのESクエリは、実際に、スレッドとスレッド間の場合ケイトンに登場し、15Sの周りの時間のカトンロットを49Sを取り上げました。
サービスは、ESの生産に半年以上を実行している理由を推測ので、ESの順序1.上の一部のデータが大きなパーティーのクエリ操作となっている必要があり、ESのパフォーマンスが問題ではありません、ES自体をチェックし、リソースの使用状況、および応答は正常でしたか？2.サービスコードがリソースを解放することができなかったです。
測定
-XX：+ PrintGCTimeStamps -XX：+ PrintGCDateStamps -XX：+ PrintGCDetails -Xloggc：/データ/アプリケーション/サーバ/ ESを作っ1. ES重要なクエリは、ログ、印刷、プリント、スタートアップスクリプトはGCログコマンドは次の通りである追加しました-queryサーバ/ heapEs.log、並列実行-XXためのガベージコレクションアルゴリズムを調整：ConcGCThreads 2.さらに-Xms2048m -Xmx2048mにヒープメモリを拡張。
3.リアルタイムレポートクエリは、大規模な一時的なオフライン処理をした2つの軽量リストクエリを保持します。再び通常の緊急サービスバックを発行しました。
見つけて、問題を修復
次の日は、午後にエラーの問題が登場、我々は、対応するESによって引き起こされる問題を解消する、対数正規ESクエリのパフォーマンスは非常に良いですました。質問は、独自のサービスコードの脆弱性に発生し、以降の期間でFGCてきGCログgcviewerで分析して、ヒープが有効な回復されていません。カトン現象を説明する前に、FGCは、サービスを停止し、世界の出現につながりました。
取得するには133333コマンドdump_075.binライブ、ファイル=：jmapの-dumpことで
ダンプファイル.JDK jvisualvm監視ツールは、ダンプファイルを分析しています。
最大ダンプ・ファイル・オブジェクトがchar []配列であるが、対象リクエストであることに留意、決定するためのシナリオを使用することにより、非常に多くのオブジェクトが存在すべきではない、テスト環境の前にそうさらに無限ループが存在するか否かINFER、リアルタイム・データ・リカバリ大きなリストのクエリは、時間データのクエリリストページが表示されますを表示することができない状況が、無限ループにつながる不一致条件の自慢四半期自慢日付計算にはさらに背景エラー情報のログ、ナビゲートを参照してくださいことがわかりました。
概要
多くの場合、複雑なチューニングパフォーマンスの問題、根底にあるの広がりだけでなく、問題を解決するためにテストツールの使用における柔軟性に精通したテスト開発者の正確な位置決め。特に簡単に見逃しエラーのチャンスは、ヘルプのトラブルシューティング複雑な問題への根本的な原則を学び、より多く蓄積します。
