Mysql接続数の設定と取得方法

接続数を取得する

--- 最大接続数を取得します。SHOW VARIABLES LIKE '%max_connections%'; 

--- 接続リストを取得します。SHOW PROCESSLIST; 
--- 接続リストを取得します。SHOW FULL PROCESSLIST; 

--- 現在の接続情報を取得します。Threads_connected は現在の接続数です。SHOW STATUS LIKE 'Threads%';

--- 履歴接続の最大数や最大接続期間などの接続統計を取得します。 SHOW STATUS LIKE '%Connection%';

mysql> SHOW STATUS LIKE 'Threads%';
+-------------------+------+
| 変数名 | 値 |
+-------------------+------+
| スレッドキャッシュ | 58 |
| Threads_connected | 57 | --- この値は開いている接続の数を示します | Threads_created | 3676 |
| Threads_running | 4 | ---この値はアクティブな接続の数を示し、通常は接続された値よりもはるかに低くなります+-------------------+-------+

Threads_connected は show processlist の結果と同じで、現在の接続数を示します。正確に言うと、Threads_runningは現在同時実行しているスレッドの数を表します。

接続数の設定

一時設定

mysql>show variables like 'max_connections'; --- 現在の最大接続数を確認しますmsyql>set global max_connections=1000; --- 最大接続数を 1000 に設定し、設定が成功したかどうかを再度確認しますmysql>exit --- 終了します

永続的な設定では、/etc/my.cnfでデータベース接続の最大数を設定できます。

[mysqld]
最大接続数 = 1000

プロジェクト内の接続プール設定

次の式は PostgreSQL によって提供されていますが、基本的な原理は変更されておらず、市場のほとんどのデータベース製品に適用できます。また、想定されるトラフィックをシミュレートし、以下の式を使用して適切な値を設定する必要があります。その後、実際のテストで値を微調整し、最も適切な接続サイズを見つけます。

接続数 = ((コア数 * 2) + 使用可能なディスク数)

ハイパースレッディングがオンになっている場合でも、コア数にはハイパースレッディングを含めないでください。すべてのホット データがキャッシュされている場合、実際の有効なディスク数は 0 です。キャッシュ ヒット率が低下すると、有効なディスク数は徐々に実際のディスク数に近づきます。また、この式が SSD 上でどの程度機能するかは明らかではないことにも注意してください。
さて、この式によれば、サーバーの CPU が 4 コアの i7 の場合、接続プールのサイズは ((4*2)+1)=9 になります。

10 に切り上げましょう。これでよろしいでしょうか？ 10は小さすぎます!

動作していないと思われる場合は、パフォーマンス テストを実行できます。6,000 TPS の速度で 3,000 人のユーザーが同時に単純なクエリを実行することを容易にサポートできることを保証します。接続プールのサイズを 10 以上に増やすこともできますが、その時点で応答時間が長くなり、TPS が低下し始めます。

必要なのは、小さな接続プールと、接続を待つスレッドのキューです。

同時アクセスが 10,000 件あり、接続プールのサイズを 10,000 に設定すると、おそらく時間の無駄になります。

1000 に変更します。高すぎますか? 100に変更しますか?まだ多すぎます。

必要なのはサイズ 10 のデータベース接続プールのみで、残りのビジネス スレッドはキューで待機させます。

接続プール内の接続数は、データベースが同時に効果的に実行できるクエリ タスクの数に設定する必要があります (通常は CPU コア数の 2 倍以下)。

ユーザー数がそれほど多くない Web アプリケーションでは、約 10 人の同時ユーザーに対応するために、データベース接続プールが 100 または 200 に設定されていることがよくあります。データベース接続プールのサイズを大きくしすぎないようにしてください。

近ければ近いほど良いというのは本当ですか？

9600 個の同時スレッドをシミュレートしてデータベースを操作し、各データベース操作の間に 550 ミリ秒スリープします。ビデオの冒頭で設定されているスレッド プール サイズは 2048 であることに注意してください。

データベース接続プールのサイズが 2048 の場合のパフォーマンス テスト結果を見てみましょう。

各リクエストは接続プール キューで 33 ミリ秒待機する必要があります。接続を取得した後、SQL を実行するのに 77 ミリ秒かかり、CPU 消費量は約 95% に維持されます。

次に、接続プールのサイズを 1024 に減らし、他のテスト パラメータは変更しません。結果はどうでしょうか?

「ここでは、接続取得の待機時間は基本的に変わりませんが、SQL 実行時間は短縮されます。」

おお、進歩がありましたね！

次に、設定を小さくし、接続プールのサイズを 96 に減らし、同時接続数などの他のパラメータを変更せずに、結果を確認します。

接続プール キュー内の各リクエストの平均待機時間は 1 ミリ秒、SQL 実行時間は 2 ミリ秒です。

何てことだ！なんてこった？

何も調整せず、データベース接続プールのサイズを縮小しただけで、平均応答時間が 100 ミリ秒から 3 ミリ秒に短縮されました。スループットが飛躍的に向上します。

君は本当に素晴らしいよ！

なぜこのようなことが起こるのでしょうか?

考えてみましょう。Nginx は内部で 4 つのスレッドしか使用しないのに、そのパフォーマンスは 100 プロセスを持つ Apache HTTPD をはるかに上回るのはなぜでしょうか?その理由について考えてみると、コンピュータサイエンスの基礎に立ち返って考えれば答えは明らかです。

シングルコア CPU を搭載したコンピューターでも、数百のスレッドを「同時に」実行できることを知っておく必要があります。しかし、これはオペレーティング システムがタイム スライスをすばやく切り替えるというトリックにすぎないことは誰もが知っています。

CPU コアは一度に 1 つのスレッドしか実行できません。その後、オペレーティング システムがコンテキストを切り替え、CPU コアは別のスレッドのコードを実行するようにすぐにスケジュールされ、このプロセスが何度も繰り返されるため、すべてのプロセスが同時に実行されているように見えます。

実際、シングルコア CPU を搭載したマシンでは、A と B を順番に実行する方が、タイム スライス切り替えによって A と B を「同時に」実行するよりも常に高速です。オペレーティング システム コースを学習したことがある人なら、その理由がよくわかるはずです。スレッド数が CPU コア数を超えると、コンテキスト切り替えに伴うパフォーマンスの増加により、スレッドを追加してもシステムは高速化されるのではなく、低速化されるだけです。

この時点で、明らかなはずです...

以上がMysql接続数の設定と取得方法の詳しい内容です。Mysql接続数の設定と取得の詳細については、123WORDPRESS.COMの他の関連記事に注目してください！