断続的なKVMパフォーマンスの問題を引き起こすパフォーマンスの問題
私たちは現在、KVMを使用して複数の仮想マシンをセットアップできるホスティングプロバイダーでホストされています。各仮想マシンは、専用の物理ボックスで実行されます（つまり、ハイパーバイザー1つ、VMすべてのメモリとCPUを搭載）割り当てられます）。最近、診断する必要のある厄介な問題が発生しました（スタックオーバーフローであることが判明しました-笑）。その過程で、すべてのサーバーを監視するようにDataDogをセットアップしました。これにより、原因を絞り込み、最終的に修正することができました。しかし、すべてを有効にしたままにしておくと、非常に便利であることがわかりました。ツールを習得する過程で、日中はWebサイトの応答時間が遅くなっています。 APMトレースを有効にすると、MySQLクラスターからの応答時間を短くすることができます。 MySQLの接続が作成されるまでに900ミリ秒以上かかる場合もあれば、接続の照合やタイムゾーンの設定などの単純なクエリが600ミリ秒以上かかる場合もあります。通常800マイクロ秒未満で実行されるクエリ。
問題を診断するために、クラスター内の複数のエンドポイントにpingをセットアップし、2つのpingを定期的に実行します（時々4-5秒！）。これは、単に文字列（PHP/Apacheバージョン）を返すか、クライアントIPを返すだけです。情報（.netおよびIISバージョン）。 LinuxまたはIISで問題が発生するかどうかを確認するためにこれらを設定しました。奇妙なことに、これらの停止が発生する時間帯には、マシンのCPUが非常に低く、MySQLクラスターと同じです。クエリの実行速度が遅い場合、これらのボックスは通常、ほとんどの場合5〜6％のCPUを占めるため、CPUは非常に低くなります。
これがネットワークの問題であるかどうかを確認するために、WindowsでWiresharkを使用してキャプチャを設定し、クエリに装飾を加えながらパケットをダンプして、パケットダンプで簡単に見つけることができるようにしました（基本的にMySQL変数をmicroecondsでの現在のUTCタイムスタンプのエンコードされたバージョンであるクエリ）。これを使用して、DataDog APMの長いMySQLスパンをTCPダンプのパケットと正しく一致させることができました。 Windows/IIS側を見ると、結果がMySQLサーバーからネットワーク経由で返されるのを待つのにすべての時間が費やされていることがわかります。そのため、MySQLクエリのDataDogで報告される時間は、データダンプの時間と正確に一致しました。
2つのスクリーンショットからわかるように、これらは正確に一致しています。 MySQL側でネットワークの問題が発生したかどうかを判断するために、Linuxマシンで同じキャプチャダンプを再度実行し、まったく同じことを確認しました。 MySQLは要求を受け取り、膨大なミリ秒後に応答を送信しました。したがって、問題は明らかにネットワークではなく、MySQL自体の速度を低下させる原因です。
本当に奇妙なのは、MySQL自体がブロックされていないということです。これらのクエリを実行した特定のボックスは、Windows仮想マシンの1つからの読み取りクエリを読み取りスレーブとして実行するだけだったためです。したがって、負荷はそれほど大きくなく、クエリの時間中のCPU負荷はおそらく3％でした（デュアル8C Xeon CPUを搭載した16個のCPU物理コア、およびVMに32個のvCoreが割り当てられています）。したがって、MySQLサーバーの負荷の問題ではなく、さらに重要なのはTCPダンプから、関心のあるクエリの実行に長い時間がかかっていたにもかかわらず、他の接続からの他のクエリがたくさん来たことは明らかです。と遅延なしで処理されました。
さらに、ログを見ると、MySQLスレーブが定期的にマスターから30〜40秒遅れていることがわかりました。マシンの負荷が最大110秒遅れたケースを見てきました。これは、マシンの負荷が低く、マスターデータベース（およびWebサーバー）がオンになっているのと同じローカルプライベートネットワーク上にあるため、まったく意味がありません。スレーブでのこれらの遅延は、スローダウンが発生するのとほぼ同時に発生する場合もあれば、発生しない場合もあります。
これがネットワークの問題ではないと最終的に判断したので、これがKVM自体のある種のスレッドのデッドロックの問題であると考え始めていますか？特に、すべての仮想マシンで非常に奇妙なスローダウンが見られるため、MySQLとは何の関係もない（静的PHP helloファイルなど）。 KVMレイヤーを制御できないため、現在どのバージョンで実行されているのかがわかりません。しかし、この複雑な問題を詳しく調べれば調べるほど、その根本的な原因としてKVMを指で指し示すようになりますが、解決方法はわかりません。
問題を説明するために、ここにPHPページのpingを示します。このページは、「こんにちは」とエコーし、他には何もしません。また、3つのAWSサーバーからのping時間です。明らかに、ときどき大きなスパイクが見られます。
今、あなたは単に議論するかもしれませんが、それはネットワーキングです！もちろん、日中にAWSがそのサーバーと通信する際に問題が発生する可能性があります。確かに真実ですが、今回は、同じミリ秒単位で測定された、Apacheの静的ページへの正確な同じAWSサーバーからの正確な同じ期間のpingを示します（PHPを実行する必要はありません。ページ）：
ご覧のとおり、静的ファイルのpingが遅くなることはなかったため、外部ネットワークでもありません。まったく問題ありません。実際には、そのボックスのApacheの2番目のインスタンスに対して実行する静的ファイルpingを設定して、ベースラインを取得するために負荷がゼロであることを確認します。 pingの最後に、物事が少しおかしくなり始め、pingの時間はあちこちにあります。これは、そのインスタンスでPHPを有効にして、2番目のApacheインスタンスから同じhello.phpファイルを提供し、それがどのように異なるかを確認したためです。主な理由は、最初のインスタンスがwordpressブログおよび広告サーバーへの実際のライブトラフィックも提供しているためです（トラフィックは少ないですが、トラフィックはゼロではありません）。明らかに、CPUをより多く使用するものをミックスに追加すると、不安定になり始めます。
だから私の質問は、KVMでこれまでにこの種の問題を経験した人はいますか？そうであれば、どのようにそれを解決しますか？このKVMソリューションを廃止し、再び専用マシン（10年前に廃止しました）に移行するか、プライベートVMwareクラウドに移行するか、GoogleまたはAzure（どちらも）への移行を検討していますより多くの費用がかかります）。しかし、同様の問題が発生する可能性がある場合、GoogleやAzureなどの別のクラウドアーキテクチャやプライベートVMwareクラウドに移行するポイントを理解できませんか？
助言がありますか？
1秒あたりのレート= RPS
My.cnfを検討するための提案[mysqld]
read_rnd_buffer_size=128K # from 256K to reduce handler_read_rnd_next RPS of 262756
innodb_lru_scan_depth=100 # from 1024 to conserve 90% of CPU cycles used for function
innodb_flush_neighbors=2 # from 0 to speed reduction of innodb_buffer_pool_pages_dirty of 148,465
sort_buffer_size=512K # from 256K to reduce sort_merge_passes RPhr of 1370
innodb_io_capacity=1900 # from 200 to use more of available SSD IOPS capacity
これは、最初の5つのパフォーマンス改善提案にすぎません。考慮すべきことは他にもたくさんあります。プロファイル、連絡先情報のネットワークプロファイル、およびパフォーマンスチューニングに役立つ無料のダウンロード可能なユーティリティスクリプトを表示してください。