1 週間問題なく動作していましたが、月曜日に突然 APP の動作が遅くなり、一部のユーザーがウェルカム ページでスタックしました。このニュースを受け取ったとき、私の心臓はドキドキしました。これは、並行性によって引き起こされたパフォーマンスの問題である可能性が高いです。そこで、DBA に最初にアプリケーション サーバーとデータベース サーバーのリソース使用量を確認してもらいましたが、アプリケーション サーバーとデータベース サーバーのリソース使用量は正常範囲内であり、非常に奇妙です。その後、アプリケーション自体からのみ開始できます。
ログを追跡したところ、異常な情報が点滅していることがわかりました: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:100; busy:100; idle:0; lastwait:30000]. 例外を見ると、Tomcat の接続プールが使い果たされていることがわかります.最初の反応は、接続プールを増やすことです: spring.datasource.tomcat.max-active=200. データベースへの接続数を 500 に調整します。結果は予想どおりですが、しばらくすると 200 が使い果たされます: 原因: org.apache.tomcat.jdbc.pool.PoolExhaustedException: [http-nio-7001-exec- 11] タイムアウト: プールが空です. 6 秒以内に接続をフェッチできません, 利用可能なものはありません [サイズ:200; ビジー:199; アイドル:0; 最終待機:6000].
前回との違いは、データベースが User sltapp already has more than 'max_user_connections' active connections. をスローすることです。つまり、今回はデータベースへの接続の最大数が十分ではありません。アプリケーションサーバーとデータベースサーバーのリソース使用量を確認するとき。アプリケーションサーバーのリソースは正常で、拡大された接続回線がそれに耐えられることを示していますが、データベースのリソースは 85% 以上に達しています。データベース サーバーにすでに負荷がかかっていることを示します。
次に、データベースを分析し、SHOW FULL PROCESSLIST スナップショットを使用して 5 秒ごとにプロセス リストを更新したところ、リスト内の 2 つのステートメントが長時間 (最長で 80 秒以上) 実行されていることがわかりました。殺す直前にまた出てきた。これら 2 つのステートメントの長時間のクエリにより、接続数がいっぱいであると判断できます。
理由を見つけた後、私はこの SQL を攻撃し始めました。分析後、このステートメントはサブテーブルの異なる順序ステータスを取得するために 4 つの自己関連付けを実行しましたが、まだ大きなテーブルであり、他の大きなテーブルにも関連付けられているため、問題は比較的大きくなります。最終的な解決策は、SQL がメイン テーブルのみをチェックすることです. メイン テーブルでプッシュ オーダーのステータスが検出された後、対応するサブテーブルの情報がメイン テーブルの主キーを介して検出され、ステータスがマークされます。つまり、複雑なステートメントを段階的に単純化してから、JAVA で論理的な処理を行うということです。いくつかの処理の後、パフォーマンスは 0 に改善されます。結果全体を数秒でクエリできます。
処理後、テストインクリメントがオンラインになりました.1日実行した後、結果は非常に明白です.システムは停止しなくなり、以前よりもはるかに高速になりました. このアクシデントの主な理由は 2 つあります。1 つは同時実行数の増加、もう 1 つはビジネス データの増加により、元の SQL 実行の効率が低下することです。最初のポイントについては、ハードウェア リソースと接続数を増やすことを検討できますが、これは本質的な問題ではなく、遅い SQL から始める必要があります。