問題の説明
ApsaraDB RDS for MySQLインスタンスまたはApsaraDB RDS for MariaDBインスタンスを使用すると、CPU使用率が高すぎて100% に達します。
原因
アプリケーションがクエリまたは変更要求を送信すると、システムは多数の論理読み取り操作を実行します。これは、要求されたテーブルの多数の行に対する高い論理I/Oを示します。 その結果、システムは、ストレージからメモリに読み出されるデータの一貫性を維持するために、多数のCPUリソースを消費する。 このトピックでは、100% のCPU使用率が高い原因となる高クエリ /秒 (QPS) および低速SQLクエリの原因と解決策について説明します。 ほとんどの場合、要求されたテーブルに多数の行が含まれているため、低速SQLクエリはクエリ実行コストが高くなります。 その結果、CPU使用率が高くなる。
高いCPU使用率は、多数の行ロック競合、行ロック待機、またはバックエンドタスクによっても引き起こされる可能性があります。 このトピックでは、これらのケースは取り上げません。
原因1: 高いQPSによって示される重いアプリケーション負荷
パフォーマンス: インスタンスのQPSが高く、クエリ操作が簡単で、クエリの実行効率が高い。 これは、最適化の可能性を低くする。
特徴: 低速SQLクエリが発生しないか、低速SQLクエリが重い負荷の根本原因ではありません。 QPSとCPU使用率のカーブが一致します。
一般的なシナリオ: 注文システムなどの最適化されたオンライントランザクションシステム、読み取り率の高い一般的なwebアプリケーション、sysbenchなどのサードパーティのストレステストツール。
原因2: SQLクエリが遅いためにクエリ実行コストが高い
パフォーマンス: インスタンスのQPSが低く、クエリの実行効率が低く、クエリ中に大量のデータをスキャンする必要があります。 これは、最適化の高い可能性を残す。
特徴: 遅いSQLクエリが発生します。 QPSとCPU使用率のカーブが一致しません。
分析: SQLクエリは非効率的であるため、期待される結果を得るために大量のデータをスキャンする必要があります。 これは、高い平均論理I/Oをもたらす。 その結果、頻繁にアクセスされないWebサイトの場合のように、QPSが低くてもCPU使用率は高くなります。
解決策
ビジネス要件に基づいてソリューションを選択できます。
原因1の解決策
アプリケーションアーキテクチャを最適化するか、インスタンスタイプをアップグレードすることを推奨します。
RDSインスタンスのインスタンスタイプをアップグレードして、CPUリソースを増やします。 詳細は、「インスタンス仕様の変更」をご参照ください。
読み取り専用RDSインスタンスを追加して、プライマリRDSインスタンスからデータの一貫性に敏感でないクエリをオフロードします。 クエリの例は、商品タイプのクエリおよび列車番号のクエリを含む。 詳細については、「読み取り専用ApsaraDB RDS For MySQLインスタンスの作成」をご参照ください。
PolarDB-Xを使用して、データベースとテーブルの自動シャーディングを実装し、RDSインスタンスから複数のRDSインスタンスにクエリをオフロードします。
ApsaraDB for MemcacheまたはApsaraDB for Redisを使用して、RDSインスタンスからクエリをオフロードします。 この場合、頻繁に照会されるデータはキャッシュから読み取られます。
静的データをクエリし、同一のクエリを実行し、結果セットが1 MB未満の応答を受信するアプリケーションのクエリキャッシュを有効にします。
説明クエリキャッシュがクエリをオフロードするかどうかをテストする必要があります。 詳細については、「ApsaraDB RDS For MySQLのクエリキャッシュ機能を設定および使用する方法」をご参照ください。.
定期的に履歴データをアーカイブします。 クエリによってアクセスされるデータの量を減らすには、シャーディングまたはパーティショニングを使用します。 クエリを最適化して、クエリ実行コストを削減し、アプリケーションのスケーラビリティを向上させます。
原因2の解決策
非効率なクエリを特定して最適化し、実行効率を向上させ、実行コストを削減します。
非効率なクエリを特定します。
SQL文を実行して実行中のクエリを照会します。
ショーのPROCESSLIST; フルプロセッサリストを表示します。次の出力が返されます。
低速SQLクエリが発生し、Stateパラメーターの値がSending data、tmp tableへのコピー、tmp table on diskへのコピー、Sorting result、またはUsing filesortであるセッションでは、非効率的なクエリが発生する可能性があります。
高いCPU使用率が高いQPSによって引き起こされる場合、クエリは迅速に実行されます。
SHOW PROCESSLIST;ステートメントまたはセッションから実行中のクエリを表示することはできません。 この場合、次のステートメントを実行できます。explain [$SQL]説明[$SQL] は、非効率的なSQL文を示します。
kill [$ID];ステートメントを実行して、長時間のセッションを終了できます。 セッションを終了する方法の詳細については、「ApsaraDB RDS For MySQLインスタンスでセッションを終了する方法」をご参照ください。 長時間実行のセッションを管理する方法の詳細については、「ApsaraDB RDS For MySQLインスタンスで長時間実行のクエリを管理する方法」をご参照ください。説明[$ID] は、SQL文に対応するセッションIDを示します。
Database Autonomy Service (DAS) コンソールで実行中のクエリを照会します。
DAS コンソールにログインします。
必要なインスタンスを見つけ、[操作] 列で[インスタンスセッション] を選択します。
SQL列のクエリテキストをクリックして、完全なクエリ設定と実行計画を表示します。
最適化する必要があるクエリを決定したら、SQL Diagnosticsを使用して最適化の提案を取得します。 また、診断結果に基づいて、インスタンスで発生したCPU使用率の高い履歴問題をトラブルシューティングすることもできます。
データ管理 (DMS) コンソールでRDSインスタンスにログインします。 詳細については、「データベースインスタンスへのログイン」をご参照ください。
上部で、[SQLコンソール] をクリックし、データベースを選択します。
SQL文を [SQLConsole] タブに貼り付け、[SQL Diagnostics] をクリックします。 最適化の提案が表示されます。
最適化の提案に基づいて、SQL文を最適化できます。 たとえば、インデックスを追加して、クエリ実行コストを大幅に削減できます。
追加情報
パフォーマンス問題のトラブルシューティング
DMSは、インスタンスのパフォーマンスの問題をトラブルシューティングするさまざまな機能を提供します。 インスタンス診断レポート機能は、RDSインスタンスのパフォーマンスの問題のトラブルシューティングに最適です。 パフォーマンスの問題が発生した場合は、最初にインスタンス診断レポート、特にSQL最適化の提案、セッション、およびスロークエリログをレポートに表示することをお勧めします。 DMSは次の機能を提供します。
CPU使用率の100% を回避するためのガイドライン
次の方法を使用できます。
CPU使用率アラートを構成して、CPU使用率を監視し、ビジネス要件に基づいてワークロードを計画します。
アプリケーションの設計と開発中に、一般的なルールと手法に基づいてMySQLクエリを最適化し、クエリの論理I/Oを減らし、アプリケーションのスケーラビリティを向上させます。
新しい機能またはモジュールを起動する前に、本番データを使用して本番環境でストレステストを実行します。
新しい機能またはモジュールを起動する前に、本番データを使用して回帰テストを実行することを推奨します。
システムリソースのアルゴリズム
このセクションでは、簡略化されたモデルを使用して、システムリソース間の関係、SQL文のクエリ実行コスト、およびQPSを示します。
条件: アプリケーションの設定は変更されません。
avg_lgc_io: 各クエリの実行に必要な平均論理I/O。
total_lgc_io: インスタンスのCPUリソースを使用して単位時間あたりに処理できる論理I/Oの合計。
式:
total_lgc_io = avg_lgc_io × QPS単位時間あたりに消費されるCPUリソース=各クエリの平均実行コスト × 単位時間あたりのクエリ数
参考資料
CloudDBAを使用してApsaraDB RDS for MySQLインスタンスのCPU使用率を削減する方法を教えてください。
適用範囲
ApsaraDB RDS for MySQLおよびApsaraDB RDS for MariaDB