あなたは本当にまだデータベース接続プールのサイズを設定する方法を知っています

原因を確認するための全体のプロセスログ後の外観は、データベースを初期化するために接続されていた、ゆっくりと死を開始、ダボサービス：古いプロジェクトでいくつかの時間前には、問題を経験しました。1024：データベース接続パラメータ、接続プールのサイズを参照してください。

多くの後半エントリの学生が経験豊富な人生手書きのJDBCコネクションを持っていません。その時にデータベース接続プールの概念、ネイティブコードミール出ている、と後でのiBATISは徐々に減少した後に、Javaの複雑度と、また、データベース接続プールC3P0の事その基礎から派生。ローマは一日にして成らなかったが、インターネットは、研究開発への強制強制ミドルウェア技術圧力の様々な環境下で、あまりにも速く発展している、我々は背の高い足場の様々な出すために残業するだけでなく、多くの成果偉人。

接続を解除するための接続ニーズを確立するために、3ウェイハンドシェイクをTCPの方法を使用して、データベース接続がインターネット利用のこの周波数で今日手を振って4時間を必要としますが、データベース接続にアクセスするたびに再確立されている場合、私はあなたが十分な企業が800回を閉鎖していないと思います。

1.プロセスは、データベース接続のようなものです

Javaの創始Sun MicrosystemsがAPIのセットは、世界を統一したいと考えているが、各データベースサーバは力の統一にすぎないので、ベンダー。動揺は統一されたインタフェース、提案段階の統一されたアクセス、各ベンダーが実装するインタフェースの作成で、独自のデータベースをロードする手順に従ってください。だから今のプログラムは4つのトリックです：

登録車は、 Class.forName()知られています：;
接続、データベースへの接続が成功の即ち確立を取得します。
Statementオブジェクト、データベースのCRUD操作を取得します。
結果のResultSetを返すようにデータベースを取得します。

我々は、すべてのデータベース自体が唯一の接続を開始し、クライアントプログラムであることを知っている必要があります。私たちは、インストールされ、サービス・マシン、コマンドライン入力に開始し、たとえば、MYSQLを取る：mysql -uroot -p現在のデータベースを接続します。

MYSQLの接続がUnixとWindowsシステムと共通の接続を区別する多くの方法は、ある2つだけの方法、ここで言った：1であるunix domain socket他は、に基づいてtcp/ip合意、我々は一般的にデータベースへのリモートアクセスは、に基づいていなければならない場合にはtcp/ip、しかし、私たちがソケットまたはTCPにを使用する場合は/にログインするマシンをIP。

socket：mysql -uroot -p
tcp/ip：mysql -h127.0.0.1 -uroot -p

データベースサーバとアプリケーションサーバが異なるホスト上にある場合、TCP / IPの方法を使用して接続を確立する必要があります。各接続は維持するために、オペレーティング・システム内の1つのスレッドを占めます。短期および長期の接続接続：それはまた、2つのカテゴリに分類された接続を確立します。

ショート接続

いわゆるショート接続する接続は、通信及びデータベースアプリケーションが終了した後に閉じられることをいいます。この接続は、すべての操作のためにあります：

发出请求--->建立连接--->操作数据--->释放连接

これに伴う問題は、次のとおりです。

データベースへの頻繁な確立/解放接続は、システムの負担を増加させ、
各演算処理データベースアプリケーションが非常に遅くなります。
ポート、頻繁確立/解放を占有しなければならない接続を確立するために、すべてのアプリケーションは、それぞれの接続がすぐに確認段階までFIN待ちを経なければならない解放要求を発行した後に実行解放されません。だから、ときに、第2のデータベースあたりの要求の数千人は、アプリケーション・サーバーのポートが消費される可能性が高いです。

ロング接続

接続が確立された後、アプリケーションをリリースする前にクローズされるまで、その接続は、長いオープンとなっています。長い接続を使用する利点は、接続のオーバーヘッドを作成する各時間を短縮することです。

アプリケーションサーバは、長い接続の利点を維持するために自分自身のために話すが、データベース・サーバのために、接続が長すぎるの災害です。

MYSQL TCP接続は、すべてのデータベース操作が完了したので、あなたは直接接続をオフにすることはできませんが、これに関連して、次の使用を待っている間に多重化し、長い接続をサポートしています。すべてのロングソケット接続が接続を維持するように、TCPビルトインのpingのハートビート（TCPがキープアライブ）によって維持されている、と我々は精通しているwebsocket、また、ハートビートによって中断されていないTCPコネクションを維持するために使用されます。

接続プーリング

ビッグ限り接続の利点は、当然我々はすべての長い接続を使用します。データベース接続プール - ゆっくりと長い接続を維持するためのツールのセットを思い付きます。

NOR、一般的なステップは、どのように複雑なデザインの接続プールにあります：

接続を開始します。
サービス接続を削除します。
トラフィックの送信要求。
接続を交換してください。

上記の基本的な機能に加えて、だけでなく、並行性の問題、マルチサーバとマルチユーザ・データベース、トランザクション処理、プールの接続設定およびメンテナンスに対処します。おそらく、これらの機能。あなたがプールを持って、そして維持するための転送プールとは無関係のリリースとのビジネスの接続を確立したら。

2. MySQLは接続数をサポートすることができます

接続のMYSQLデフォルトの最大数は、バージョン5.7 151であり、16,384（2 ^ 14）までとすることができます。次のようにどのようにMYSQLの接続番号情報コマンドを参照してください、あなたのサーバーのパフォーマンスという接続の最大数を設定するには次のとおりです。

mysql> show variables like '%max_connections%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 5050  |
+-----------------+-------+
1 row in set (0.00 sec)

接続の当社の生産環境MYSQLの最大数は5050に設定され、注意が結果が原因の接続障害には小さすぎる、あまりにも小さく設定することができません：エラー：「あまりにも多くの接続クエリがエラー1040失敗しました」。大きすぎるとき、マシンがデータベースに接続されている現在のMYSQLパフォーマンスへの影響をよりあろう。

MYSQL公式サイトショー接続の最大数を設定する勧告の割合：

Max_used_connections / max_connections * 100% ≈ 85%

接続の数、および現在の比率を使用して接続の最大数は非常にその設定を解除され、それの10％未満である場合に接続の総数が既に多すぎる、セントキャップあたり約85使用します。

クエリ現在のデータベース接続が確立します：

mysql> show status like 'Threads_connected';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 89    |
+-------------------+-------+
1 row in set (0.00 sec)

MySQLのクエリおよび設定がグローバル変数に設定することができ、主に関連する構成は以下これらを照会することができます：

コンフィギュレーション	意味
接続	接続試行のMySQLの数、接続が成功したか否か、値が+1であろう
Threads_connected	接続の数は、単一のノードは、接続プールは、接続の最大数の最大値よりも一般的に小さく、確立しています
MAX_CONNECTIONS	接続の最大数は、MySQL制限することができます
WAIT_TIMEOUT	（非対話型）長寿命MYSQL接続の最大期間は、デフォルトでは8時間です
interactive_timeout	最大の健康の長時間接続（インタラクティブ）、デフォルトは8時間です

3.どのように多くの接続、接続プールの設定が適切です

設定された接続プールのサイズは確かに大きくなっ良くないが、あなたは考慮する必要があり、現在のマシンのサービスのパフォーマンス、ネットワークの状態、データベース・マシンのパフォーマンス、データベース機能などです。しかし、また、システムリソース、メモリ、ポート、およびその同期信号の量を無駄にしないでください。

例えば、200の値を設定するTomcatの最大スレッドプールのデフォルトのアプリケーション・サーバーは、最大値は、各スレッドは、スレッドプールのサイズは200以上でなければならないデータベース接続を使用することを想定しています。

別の考慮事項は、長い接続用の各アプリケーションは長いプロセスの保守のための物理的なネットワーク接続上に構築され、物理マシンで実行するためのCPUコアの数は、関連するプロセスということです。理論的にはコア8に接続されたサーバは、各コアが同時に一つのスレッドを処理し、8最高のプールに設定されている、個以上の同時スレッドコンテキストスイッチのオーバーヘッドがあります。

：ここではOracleのパフォーマンスチームが発表し、短い動画だ、コネクションプーリングテストは二つの部分に分かれていたテスト映像1、テスト・ビデオ2。ビデオは144に戻って調整急激な減少は、復元された2048のデータベース・パフォーマンスのスレッドプールのサイズを調整します。PostgreSQLは、式の予想されるサイズを設定するスレッドプールを提供します。

connections = ((core_count * 2) + effective_spindle_count)

：式がから来ているhttps://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing。

その中でも、core_countCPUコア、effective_spindle_countご使用のサーバは、その後、ディスクにRAID 16を使用する場合、スピンドルの有効数の意味valid_spindle_count=16。それは本質的に、サーバが管理できるパラレルI / O要求の数の尺度です。ハードディスクの回転（通常は）唯一のあなたは16を持っている場合、システム16は、同時にI / O要求を処理することができ、1つのI / O要求を処理します。

私は、この式が受け入れられる提案、最も優れた1データベース接続プールとひかりにしたいと思います。本番環境では、（私は問題を見つけることができません）試してみたいと思うかもしれません。