パフォーマンスの問題パフォーマンステストの分析

開始パフォーマンステストをあなたが知る必要がある前に：

　　1、具体的には、プロジェクトの必要があります。

　　2、指標：未満の応答時間どのくらい、どのように多くの同時、どのように多くのTPS、どのように多くのトータルTPS、トランザクションを測定する取引、取引の成功率、トランザクションの変動範囲、安定した動作時間、リソース使用率の合計数、インタフェースの安定性そのシナリオのテスト。

　　3、環境：本番サーバーの数、リソースの比に応じてサーバーのテスト環境、テストの結果指標の数。

　　4、契約：システムの任意の合意と通信します。

　　図5は、プレスの数：同時ユーザーの数が多すぎる圧力が異なるプレスに送信する必要がある場合、プレスは、そうでない場合は、TPSの応答時間やジッタにつながる、ボトルネックがあるかもしれません。

　　6、トランザクション会計：TPSを来LiveJournalの会計分析。

　　図7に示すように、システムアーキテクチャ：要求圧力測定は、これらの領域を監視し、ストリームを介して部分、。

 

　　 テスト戦略：

　　1、標準：100回の繰り返し使用者、関心の応答時間、100％のトランザクションの成功率。

　　2、負荷：応答時間、100％のトランザクション成功率に10分とフォーカスを実行している10人のユーザ。

　　図3に示すように、容量：式と各トランザクションVUペーシング、最大処理能力収集システム（最適容量）に従って計算し、トータルTPSを推定し、次いで、アウター比較（以下、最適な容量より2、の三の測定勾配を作ります最適な容量よりも大きいのグループ）、四則VUの容量は、算術、実際の容量シェアを比較し、各試験（より近い現実世界のシナリオ）、関心の応答時間、トータルTPS、TPS、トランザクションの会計TPS成功率、APのCPU使用率、DBのCPU使用率、スレッドのデッドロック、 データベースの デッドロック。

　　応答時間がより少ない負荷試験よりもあるべきであり、合計は、推定合計のTPS TPSにほぼ等しくなければならない（10以下により正常である）、近接トランザクションTPSに、* 100％のトランザクション成功率、APの合計の割合のTPSを推定しなければなりませんCPU 60％未満、DB CPUの80％未満。ダンプスレッドスタックは、スレッドのデッドロックの検出を持っているかどうか、ログデータベースのデッドロックかどうかを確認するためにデータベースをチェック。

　　図4に示すように、安定性：長期実行、フォーカスの応答時間の24時間の連続操作として最適圧力の80％を取る能力、性能監視システム、TPS、トータルTPS、トランザクション成功率、取引の総数、メモリのオーバーフローがあるかどうかを確認（ヒープオーバーフロー、スタックオーバーフロー、持続的な世代のオーバーフロー）、ターゲットは、MEMは成長し続けていないかどうか、通常のトリガーfullgc、GC時間、GC周波数、fullgc時間、fullgc周波数（フォーカスするかどうか、JVMのチューニングを削減することであるかどうか、CPU使用率fullgc周波数）。

　 　

       モニタリング：

　　ときNMON能力試験や安定性試験は、監視を開始します。

 

遭遇したパフォーマンスの問題と解決策を測定する圧力：

まず、高すぎるテストプロセスのCPUの能力

　　1、vmstatのCPU使用率とのリアルタイム監視。AP CPUは80％以上、指標のない60％以上に小さい圧力を有します。

　　2、分析は、使用CPUのsys CPUが高すぎるか、高すぎる、それはハイに一般的な使用のCPUです。

　　3、高への使用のCPUは、第1のCPU消費量アップは、複数のスレッドが、スレッドはその後、16進に変換し、このスレッドが消費あまりにも多くのCPUを見つけるためのプロセス（topコマンド）を、見つけるためにあれば、その後、ダンプスレッドスタックへjstackコマンドは、このスレッドのスタックを見ては、あまりにも高い使用CPUにつながったものを呼び出します。

　

第二に、メモリ・オーバーフロー（ヒープオーバーフロー、スタックオーバーフロー、持続的な世代のオーバーフロー）

　　 1、ヒープメモリのオーバーフロー

　　 現象は： 安定性の圧力測定、LRのエラーの期間の後、ログが報告された Javaの .lang.OutOfMemoryError.Javaヒープスペースを。

　     ツールのトラブルシューティング：

       PIDダンプヒープメモリ使用量-histo 1）コマンドjmapは、トップ20のランキングヒープメモリは、アプリケーションが独自の方法を持っている場合の方法はどのような原因のヒープメモリによって引き起こされている場合、上のチェックして、最高から、チェックを参照するオブジェクトを見ますオーバーフロー。

　　2）独自の方法なしで最初の20年間の場合は、MATのヒープメモリとダウンダンプの分析では、輸出のメモリオーバーフロー分析をヒープメモリをダンプするためにjmapの-dumpを使用します。

　　 解決策： アプリケーションの方法は全く問題がない場合は、あなたは、JVMパラメータを変更XMS、Xmxのを修正し、一般的にヒープメモリを増やす、ヒープメモリのパラメータを調整する必要があります。

　　 図2に示すように、スタックメモリのオーバーフロー

　　 理由： 時間をかけて測定された圧力の安定性は、LRのエラーログはjava.lang.StackOverflowErrorを報告しました。

　    ソリューション： 変更JVMパラメータ、スタックメモリ内のパラメータの変更XSS大幅に増加。

                          バルク操作によって引き起こされるスタックオーバーフローは、バッチデータの量を減らすために行われなければなりません。

　　 3、持続的な世代のオーバーフロー

　　 現象： 加圧試験後の一定時間の安定性、ログがJava.Lang.OutOfMenoryError.PermGenスペースを報告しました。

        ソリューション：

　　1）この理由は、永久的な生成フィル永久生成オーバーフローをもたらす、クラス、メソッドの記述、記述フィールド、少なすぎる定数プール、このような静的変数としてアクセス修飾子によるものです。

　　2）修正のJVM設定、XX：MaxPermSizeを= 256の主要なパラメータ。静的変数を最小限に抑えます。

 

第三には、スレッドがデッドロック
　　 の原因を： マルチスレッドプログラムを書くには、同期メカニズムの不適切な使用は、それがデッドロックプログラム、プログラムは通常、一時停止、またはユーザの要求にもはや応答を引き起こす可能性があります。

        現象をプロデュース ：

　　図1は、容量の試験期間を測定する圧力は、LRは、接続タイムアウトを報告しました。

　　この現象の2の理由は、帯域幅として、多くは、スレッドプールが十分ミドルウェアない十分ではない、データベース接続のプールが不十分であるので接続の数になり、接続タイムアウトエラーが報告されていない充填。

        ツールのトラブルシューティング：

　　1、jstackスレッドのスタックダンプコマンド、スレッド・スタックを検索し、何もブロックが存在しない、いずれかの場合は、スレッドのデッドロック、デッドロックは、スレッド、対応するコードの分析を見つけています。

　　 jstack -F PID> jts.log（JavaのプロセスID、あなたはJPSまたはPS補助を使用することができます|行くためにはgrep javaの）、jts.logファイルへのスレッドの出力状態

     　　懸念のスレッドの状態は以下のとおりです。
     　　デッドロック、デッドロック（フォーカス）
     　　の実装、Runnableを  
     　　資源待ち、条件（フォーカス）の待機
     　　モニターを得るために待って、待っているが、モニタエントリ（フォーカス）に
     　　一時停止、一時停止
     　　オブジェクトが待っている、オブジェクト.WAIT（）またはTIMED_WAITINGは
     　　、ブロックされた（焦点）がブロック 
     　　停止は、パーク

       後処理：生成されたファイル、ビジネス・ロジック・コードは、いくつかの重要な状態の調査に開発中であるので、

 

第四に、データベースのデッドロック

　　 現象： 試験期間後に測定した圧力の容量、LRは、接続タイムアウトを報告しました。

　　 ツールのトラブルシューティング： データベースログ検索ブロックを、ブロックが存在することが判明することができ、その後、データベースはデッドロックされ、対応するSQL、デッドロックに結果のSQLの最適化を参照してください。

 

第五に、データベース接続プールは解放されません。

　　 現象： 試験期間後に測定した圧力の容量、LRは、接続タイムアウトを報告しました。

　　 調査及び溶液： コンフィギュレーションデータベース接続内のアプリケーションが30である場合、（フルPROCESSLISTを示す）の数のデータベースへのアプリケーションの接続を表示するために、データベースに行くは、データベースへのアプリケーションの接続がデータベース30、接続プールされたビュー満たされました。90は、データベース90への接続が、データベース接続プールは、原因を解放しないと判断することができるかどうかを確認するために、試しに設定されます。コードを見ては、データベース接続は、接続を作成するために、ケースの一部ではなく、接続を閉じません。このような状況の基本的な原因は、コードを変更することができ、あります。

 

六、TPSが上がることができません

　　 現象： 時間の圧力はしばしば停滞トータルTPSその結果、振盪TPS。（|フルgrepするgc_mSrv1.log -f尾がfullgcがあれば参照してください ）。

        ツールのトラブルシューティング：

　　。1は、ペーシング間隔は間隔が減少するペーシング、停滞TPSにつながる大きすぎる設定されています。

　　2、単一の圧力ジッタ大したことは、それを安定した、その後、容疑者は、あまりにも多くの圧力を引き起こすので、髪他のプレスに割り当てられた最大の鳥のトランザクションの圧力容量、その後、TPSは振らないで見つかりません。注：複数のプレスは、CPUのみサーバに影響を与えないだろう、TPSジッタに影響を与えます。

　　図3は、応答時間がタイムアウトしていない、ユーザーの数を見ては十分ではありません、インデックス内の両方、あなたは利用者の数を追加することができます参照してください。

 

七、サーバ不均一応力（しかし1％-2通常の％の差）

　　1は、4つのAPPだけつのCPUの60％以上は、他の三つの60％未満である場合、最適な容量を実行します。

　　2、サーバは、時限タスクを持っているかどうかを確認します。

　　3、ボトルネックプレスがあるかどうかを確認するために。

　　4、帯域幅のボトルネックがあるかどうか（LANは、この問題を持っていません）。

　　5、コンフィギュレーションの展開バージョンが同じである見ます。

　　同じ物理マシン上で多数の仮想マシンがあるので、最初持つ人々は、他の誰の前にリソースが計上されているので、6、他の人にも、これらのAPPを使用することができます。

       7、プリコミットメントサーバ負荷の派遣（nginxの、LVS）割り当てポリシーの問題

 

八、fullgc長すぎます

       原因とトラブルシューティング方法：

　　1、容量と走行安定性、LR報告要求タイムアウトエラーをそこに持っています

       2、バックログがfullgcあるいくつかの新聞のLRの間違ったを見て見るとfullgc時間対応を記録、fullgcは、フロントLRにつながる、アプリケーション全体を一時停止します応答、そうエラーではありませんでした、あなたはそう、メモリの古い発生を低減することができますfullgc、時間を短縮LRにエラーがユーザーがほとんどのアプリケーションが停止していると感じていないことができませんfullgc時間を短縮します。

　　 ：ソリューション 4 APPフルGC回し（の一部の サーバ  fullgcタスクは、サービスを再起動したときに書き込みタイミングを、他のサーバはfullgcますが）、あなたは、このような夜間以下取引など、さまざまなサーバーが同じ時間をfullgcしないようにする戦略を開発することができます。

 

九、LRは、接続タイムアウトを報告しました

       図1に示すように、この現象の理由は、データベースのデッドロックのように、多くは、データベース接続のプールが長すぎるfullgc、解放、ヒープオーバーフロー、スタックメモリのオーバーフロー、オーバーフロー永久世代、帯域幅が十分ではないない、ミドルウェアスレッドプールは、十分なデータベース接続ではありませんプールが十分ではない、ので、接続数になり、接続タイムアウトエラーが報告されていないいっぱい。

 

　 　注意：

　　次のテスト用のサーバーのエラーログ。

　　サービスは圧力が大きな圧力になります作ら分以内に開始された後、サービスが圧力を実行し始めた後、それは二十から三分を開始するのがベストです。

 

 パフォーマンス分析のプロセス

1は、サーバ等のCPU、メモリ、負荷表示、
健康状態データベースビュー、2を
（特に現象を見ていない）3を、プロジェクトのログを参照してください
4は、JVM GCなど参照
5、バージョンのロールバック（通常は最後の手段）