Pagoda パネルを使用して簡単な MySQL パフォーマンス チューニングを実現する方法

Pagoda の次のチュートリアル コラムでは、Pagoda パネルを通じて MySQL パフォーマンスの簡単なチューニングを実現する方法を紹介します。

PHP MYSQL アーキテクチャ Web サイトの運用中に、MySQL、PHP、CPU、ディスク IO、キャッシュなどのさまざまなパフォーマンスの問題が頻繁に発生しますが、その中には MySQLがボトルネックです。これは、Web サイトのパフォーマンスに影響を与える最も一般的かつ解決が難しい要因です。通常、コンテンツをキャッシュするには、redis や memcached などのキャッシュ ソフトウェアを使用します。これは確かに最良のソリューションの 1 つですが、ただし、最も一般的に使用されている Web サイト プログラムは、これらのキャッシュ ソフトウェアをサポートしていないか、完全にはサポートできません。今日は、MySQL のボトルネック問題を軽減するために、MySQL 独自の構成調整を通じて MySQL のパフォーマンスを最適化する方法について説明します。

準備:

1. Pagoda Linux パネル正式バージョン 5.2.0 (2017/09/20 リリース) ベータ版 5.2.4

2. MySQL 5.x

通常、MySQL のチューニングは次の部分に分かれています。

1. MySQL 構成パラメータのチューニング (Web サイトの動作条件に応じて調整する必要があります)

2. データ テーブル インデックスチューニング (効果 当然のことですが、通常、優れたオープン ソース プログラムは調整する必要がありません)

3. SQL ステートメントのチューニング (これはプログラマまたは DBA が行うことです)

今日は主に、次の方法について説明します。 Pagoda と協力する パネルの新しい機能を使用して MySQL 構成パラメータを調整するには、まず 2 つの図を見てみましょう:

(図 1)

(図 2)

##明らかに、(図 1) は MySQL の現在の実行ステータスを示し、(図 2) は MySQL の主な構成パラメータを示します。これら 2 つの図を解釈してみましょう:

1. アクティブ/ピーク接続の数

(図 1) 現在のアクティブな接続は 1 です。MySQL サービスが開始されて以来、最大の接続数はis 54; (図 2) の最大接続数が max_connections に近いか等しい場合、max_connections は適切に増加する必要があります。一度にあまり増加しないことに注意してください。毎回 50 ずつ増加することをお勧めします。一定期間観察して足りない場合は、さらに増やしてください。

2. スレッド キャッシュ ヒット率

(図 1) のスレッド キャッシュ ヒット率は 99.78% です。この値が 90% 未満の場合は、() の thread_cache_size を増やすことをお勧めします。図 2) を適宜変更し、毎回 8 ずつ増やすことをお勧めします。

3. インデックス ヒット率

(図 1) のインデックス ヒット率は 99.50% です。この値が 95% 未満の場合は、(図 2) の key_buffer_size を増やすことをお勧めします。データベースが Innodb エンジンを使用している場合、このオプション

4、Innodb インデックス ヒット率

(図) を無視できることに注意してください。 1) Innodb インデックスのヒット率 100%。この値が 95% 未満の場合は、(図 2) の innodb_buffer_pool_size を適切に増やすことをお勧めします。毎回 64 ずつ増やすことをお勧めします。データベースは Innodb エンジンを使用しないため、このオプションは無視できます

5. クエリ キャッシュ ヒット率

MySQL クエリ キャッシュは物議を醸す機能です。個人的には、次のようなキャッシュ ソフトウェアを使用する場合は、このことをお勧めします。 redis および memcached と同様に、query_cache_size を 0 に設定できます (図 2)。オフにします。キャッシュ ソフトウェアを使用していない場合、余分なメモリ使用量がある場合、およびデータベースのボトルネックが明らかな場合は、クエリ キャッシュをオンにしてみてください。データ テーブルの構造と SQL ステートメントの最適化に大きく依存する関数ですが、データ テーブルの構造と SQL ステートメントがクエリ キャッシュ用に最適化されており、その効果は依然として非常に優れています。

6. 一時テーブルをディスクに作成する

(図 1) 一時テーブルをディスクに作成する割合は 0.42% で、これは、ほとんどの一時テーブルがメモリ内ではなくメモリ内に作成されることを示しています。ディスク IO のコストを増加させるには、その割合が 2% を超える場合、(図 1) の tmp_cache_size を適切に増やすことをお勧めします (毎回 32 ずつ増やすことをお勧めします)。 60%、あきらめます。オープン ソース プログラムの中には、SQL ステートメントが特に最適化されていないものもあります。そのため、動作中に大量の一時テーブルが開かれ、どれだけキャッシュを追加しても十分ではありません。

7. オープン テーブル

(図 1) のオープン テーブルが (図 2) の table_open_cache に近いか等しい場合、table_open_cache を適切に増やすことができますが、これが設定されている場合は、プログラムが MySQL 接続を頻繁に中断する可能性があるため、値を 1024 以内にし、最大値が 2048 を超えないようにすることをお勧めします。

8. インデックスなしの JOIN の量とインデックスなしの JOIN の量

0 でない場合は、データ テーブルのインデックスを確認します。たとえば、1 日にどのくらい増加しますか? 数千という単位は通常は無視できますが、結局のところ、プログラマや DBA がインデックスを最適化する方が適切です。

9. ソート後のマージの数

この値がゆっくり増加している場合は、(図 2) の sort_buffer_size を適切に増やすことをお勧めします。毎回 512 ずつ増やすことをお勧めしますが、最大値は 8192 を超えないようにしてください。この値が増加し続ける場合は、増加します。 sort_buffer_size は役に立たないので諦めてください。これはオプションです。責任はプログラム開発者にあるはずです。

10. テーブル ロックの数

サーバーの CPU オーバーヘッドが低く、テーブルを異常にロックする場合は、すべてのデータ テーブルを innodb に変換し、変換前に必ずバックアップすることをお勧めします。

11. 最適化計画

これはメモリサイズに基づいた推奨最適化計画です. 基本的な参考値としてのみ使用することをお勧めします. 各設定項目は実際のメモリサイズに応じて調整する必要があります状況。 。

注: パラメータ設定を保存しても、すぐには有効になりません。忘れずに MySQL サービスを再起動してください。

以上がPagoda パネルを使用して簡単な MySQL パフォーマンス チューニングを実現する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。