MySQL Threads_runningの急騰と遅いクエリの関連問題は解決します。
3106 ワード
背景
一年前の仕事と最後の段階を振り返ってみるべきですが、どうやっていろいろな販売促進やイベントが春節を待っていますか？それで、いろいろな問題がありました。最近あった問題を振り返ってみたら、いくつかの問題が似ています。表现はすべてデータベースの死で、応答がなくて、発生のシーンはわりに高い业务の圧力が来ます时があって、业务が正常に运行する时もあって、突然问题が现れました。
問題の説明
テンセントクラウドのデータベースMySQL自体は故障検出と高利用のメカニズムがあるため、このいくつかの問題が発生した時、ユーザーからフィードバックされた問題が発生した時点から実際に調査に介入した時まではすでに何分間ありましたが、高利用可能な切り替えをトリガしていません。この問題はデータベース自体の故障ではないかもしれません。いくつかの外部の原因ではなく、データベースが使えなくなります。
データベースの状態を確認してみます。異常な指標が見つかりました。
問題の時点の近くで、接続数の合計数とthreads_runningの数は短期間で上昇し始め、半分間近くで監視プラグインにもデータが採取されなくなりました。同じ時間帯にCPUの使用率（100%に達する）、遅い照会数も上昇しています。基本的にCPUの使用率を確認し、ゆっくり調べ、接続数の指標という三つのものは関連しているはずです。この三つのものから今回の問題の原因を分析することができます。
原因分析
99%の場合、ゆっくりとした検索数が急騰している限り、この問題はゆっくりと調べても関係がないが、判例分析はそんなに簡単に結論を下すことはできない。つまり、目標が三つの指標に縮小されている以上、この三つの指標の意味をそれぞれ考えてみてください。これらの指標の異常がどのような問題をもたらすかを見てください。
CPU
CPUはMySQLの計算能力がいっぱいで、MySQLの計算リソースを占有できるのはユーザスレッドとMySQL自身のシステムスレッドだけで、今回の問題は明らかにMySQLシステムスレッドとは関係がないと説明しています。ユーザスレッドはCPUの計算リソースを大量に占有しています。しかも、使用率は100%に達しています。本来の効率の高いクエリは、CPUリソースが得られないために非常に遅くなり、効率の高いクエリから効果のない遅いクエリに変わり、データベースのデッドまたはハングの死が発生する可能性があります。
ゆっくりと検索
遅い照会は古くからの問題です。クエリの効率が低いため、CPU、IO、メモリなどの資源を過剰に占用し、他の正常なクエリに影響を与えます。監視指標から言えば、CPUの使用率、IOの使用状況、メモリの使用率は様々なレベルで上昇する可能性があります。データベース全体の応答が遅い結果となりました。
接続数
接続数は通常、「実際の故障」を引き起こす指標であり、例えば接続数がmax_に達する。connectionsの上限により、データベース全体が新規に接続できなくなり、プログラム側は直接にエラーを報告します。応答なしではありません。threads_runningという指標は、公式文書の説明を参照してください。
The number of threads that are not sleepping.
この指標の急騰は、MySQLの例に多くのアクティブなユーザが接続されていることを表している。また、このケースの監視図からは、急成長の傾向であり、短期間に大量のアクティブな接続が発生したことを示しています。
分析
この3つの指標の単純な分析を達成すると、この3つの指標は互いに影響し合うことが分かります。スロークエリが蓄積されると、CPUの使用率が高すぎる。 CPUが高すぎると、全体のクエリ効率が低くなり、効率的なクエリが遅くなります。 スロークエリの実行効率が低く、長時間アクティブな状態が維持されるので、Threads_runningという指標は必ず上昇します。 高すぎる合併が突然訪れた時、大量のクエリがアクティブな状態にあると、Threads_runningという指標は急腾していますが、この锐いトゲ型のピークはCPUを満たしやすいです。
この3つの指標が上昇しているように見えるのは、自己交渉のためであり、この3つの指標だけでは問題の原因が本当に判断できないからです。このいくつかの指標が上昇している理由を詳しく考えてみます。なぜ交渉が始まったのですか？核心的な現象があることを発見します。あるいは共通性があります。もし:で積み上げられたクエリはもともと効率が高くないです。この問題の原因は基本的に遅いです。 に蓄積されたクエリの効率が高いと、この問題の誘因は、瞬間的な同時進行が高すぎたり、他の原因でCPUの使用率が暴騰したりして、逆にこれらの効率の高いクエリに影響を与えます。
だから、積み上げられたクエリを確認すると、比較的にはっきりと問題が分かります。上の図に示されたこの例では、積み上げられたクエリはgroup byとorder byを大量に使用しています。検索の効率が比較的低いので、根因はまだ遅く調べられます。
広く開拓してください
冒頭で述べたように、最近発生した問題は多く起きており、原因は類似している。この急騰の事例以外に、次のような現象があります。
threads_runningは比較的穏やかな数値を維持しています。前の文の分析を参考にして、この現象は普段の時間に約10個のクエリが長時間アクティブな状態にあることを表しています。故障シーンを予測できます。業務量が引き続き上昇し、活発なクエリが多くなり、効率的なクエリが影響され、効率が一定の程度に低下すると、フロントエンド・プログラム/ユーザはタイムアウトや応答が遅いため、再試行を開始し、クエリの効率が低下したため、この再試行が繰り返しトリガされ、雪崩の効果を引き起こし、徐々にデータベースを崩壊させます。
幸いにも多くの類似現象の実例が一つだけ問題が発生しました。予測のこのシーンです。他のものは全部適時に最適化されました。
まとめてみます
まだ遅い照会の問題ですが、このケースからもう一つのMySQL指標が見つかりました。runningの用途：活発な接続を監視して、事前にいくつかの合併量が高すぎることと異常な調査を発見して、データベースが検索を積み上げることを防止して、仮死の現象を生みます。
以上がMySQL Threads_です。runningの急騰と遅いクエリの問題解決の詳細は、MySQL Threadsrunningの高騰と遅い照会の資料について、他の関連記事に注目してください。
一年前の仕事と最後の段階を振り返ってみるべきですが、どうやっていろいろな販売促進やイベントが春節を待っていますか？それで、いろいろな問題がありました。最近あった問題を振り返ってみたら、いくつかの問題が似ています。表现はすべてデータベースの死で、応答がなくて、発生のシーンはわりに高い业务の圧力が来ます时があって、业务が正常に运行する时もあって、突然问题が现れました。
問題の説明
テンセントクラウドのデータベースMySQL自体は故障検出と高利用のメカニズムがあるため、このいくつかの問題が発生した時、ユーザーからフィードバックされた問題が発生した時点から実際に調査に介入した時まではすでに何分間ありましたが、高利用可能な切り替えをトリガしていません。この問題はデータベース自体の故障ではないかもしれません。いくつかの外部の原因ではなく、データベースが使えなくなります。
データベースの状態を確認してみます。異常な指標が見つかりました。
問題の時点の近くで、接続数の合計数とthreads_runningの数は短期間で上昇し始め、半分間近くで監視プラグインにもデータが採取されなくなりました。同じ時間帯にCPUの使用率（100%に達する）、遅い照会数も上昇しています。基本的にCPUの使用率を確認し、ゆっくり調べ、接続数の指標という三つのものは関連しているはずです。この三つのものから今回の問題の原因を分析することができます。
原因分析
99%の場合、ゆっくりとした検索数が急騰している限り、この問題はゆっくりと調べても関係がないが、判例分析はそんなに簡単に結論を下すことはできない。つまり、目標が三つの指標に縮小されている以上、この三つの指標の意味をそれぞれ考えてみてください。これらの指標の異常がどのような問題をもたらすかを見てください。
CPU
CPUはMySQLの計算能力がいっぱいで、MySQLの計算リソースを占有できるのはユーザスレッドとMySQL自身のシステムスレッドだけで、今回の問題は明らかにMySQLシステムスレッドとは関係がないと説明しています。ユーザスレッドはCPUの計算リソースを大量に占有しています。しかも、使用率は100%に達しています。本来の効率の高いクエリは、CPUリソースが得られないために非常に遅くなり、効率の高いクエリから効果のない遅いクエリに変わり、データベースのデッドまたはハングの死が発生する可能性があります。
ゆっくりと検索
遅い照会は古くからの問題です。クエリの効率が低いため、CPU、IO、メモリなどの資源を過剰に占用し、他の正常なクエリに影響を与えます。監視指標から言えば、CPUの使用率、IOの使用状況、メモリの使用率は様々なレベルで上昇する可能性があります。データベース全体の応答が遅い結果となりました。
接続数
接続数は通常、「実際の故障」を引き起こす指標であり、例えば接続数がmax_に達する。connectionsの上限により、データベース全体が新規に接続できなくなり、プログラム側は直接にエラーを報告します。応答なしではありません。threads_runningという指標は、公式文書の説明を参照してください。
The number of threads that are not sleepping.
この指標の急騰は、MySQLの例に多くのアクティブなユーザが接続されていることを表している。また、このケースの監視図からは、急成長の傾向であり、短期間に大量のアクティブな接続が発生したことを示しています。
分析
この3つの指標の単純な分析を達成すると、この3つの指標は互いに影響し合うことが分かります。
広く開拓してください
冒頭で述べたように、最近発生した問題は多く起きており、原因は類似している。この急騰の事例以外に、次のような現象があります。
threads_runningは比較的穏やかな数値を維持しています。前の文の分析を参考にして、この現象は普段の時間に約10個のクエリが長時間アクティブな状態にあることを表しています。故障シーンを予測できます。業務量が引き続き上昇し、活発なクエリが多くなり、効率的なクエリが影響され、効率が一定の程度に低下すると、フロントエンド・プログラム/ユーザはタイムアウトや応答が遅いため、再試行を開始し、クエリの効率が低下したため、この再試行が繰り返しトリガされ、雪崩の効果を引き起こし、徐々にデータベースを崩壊させます。
幸いにも多くの類似現象の実例が一つだけ問題が発生しました。予測のこのシーンです。他のものは全部適時に最適化されました。
まとめてみます
まだ遅い照会の問題ですが、このケースからもう一つのMySQL指標が見つかりました。runningの用途：活発な接続を監視して、事前にいくつかの合併量が高すぎることと異常な調査を発見して、データベースが検索を積み上げることを防止して、仮死の現象を生みます。
以上がMySQL Threads_です。runningの急騰と遅いクエリの問題解決の詳細は、MySQL Threadsrunningの高騰と遅い照会の資料について、他の関連記事に注目してください。