データベース接続プールとHikariCPの数を構成する方法

HikariCP接続プール

HikariCP接続プールは高性能のJDBC接続プールであり、公式Webサイトに、高速、シンプル、信頼性の3つの特性が示されています。また、そのパフォーマンスは他の接続プールよりも優れています。

公式ウェブサイトでは、HikariCPによって行われたいくつかの最適化について詳しく説明しています。これらは次のように要約されます。

  • バイトコードの合理化:コンパイルされたバイトコードが最小になるまでコードを最適化し(継承階層をフラット化し、メンバー変数を隠し、強制的な型変換を排除し)、CPUキャッシュがより多くのプログラムコードをロードできるようにします。
  • プロキシとインターセプターの最適化:コードを削減します。たとえば、HikariCPのStatementプロキシには100行のコードしかなく、これはBoneCPの10分の1にすぎません。
  • ArrayListの代わりにカスタム配列タイプ(FastStatementList):get()が呼び出されるたびに範囲チェックを回避し、remove()を呼び出すときに最初から最後までスキャンすることを回避します。
  • カスタムロックフリーコレクションタイプ(ConcurrentBag):同時読み取りと書き込みの効率を向上させます。

HikariCPの使用

SpringBoot2はデフォルトでHikariCPを統合しているため、依存関係を再度導入する必要があります。主にプロジェクトmysqlとspringbootmybatisに依存します。

Yaml構成

# 配置数据源信息
spring:
  datasource:                                           # 数据源的相关配置
    type: com.zaxxer.hikari.HikariDataSource          # 数据源类型:HikariCP
    driver-class-name: com.mysql.jdbc.Driver          # mysql驱动
    url: jdbc:mysql://localhost:3306/foodie-dev?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true
    username: root
    password: 123456
    hikari:
      connection-timeout: 30000        # 等待连接池分配连接的最大时长(毫秒),超过这个时长还没可用的连接则发生SQLException, 默认:30秒
      minimum-idle: 5                  # 最小连接数
      maximum-pool-size: 20            # 最大连接数
      auto-commit: true                # 事务自动提交
      idle-timeout: 600000             # 连接超时的最大时长(毫秒),超时则被释放(retired),默认:10分钟
      pool-name: DateSourceHikariCP     # 连接池名字
      max-lifetime: 1800000             # 连接的生命时长(毫秒),超时而且没被使用则被释放(retired),默认:30分钟 1800000ms
      connection-test-query: SELECT 1  # 连接测试语句

# mybatis配置
mybatis:
  type-aliases-package: com.lzp.pojo          # 所有POJO类所在包路径
  mapper-locations: classpath:mapper/*.xml      # mapper映射文件

接続プール内の接続数の設定

データベース接続プールを導入する

データベース接続は限られた高価なリソースです。データベース接続オブジェクトは物理データベースへの接続に対応します。データベース操作ごとに新しい接続が作成され、使用後に解放されると、システムパフォーマンスが低下し、接続プールが発生します。概念。

データベース接続プールは、データベース接続の割り当て、管理、および解放を担当します。これにより、アプリケーションは既存のデータベース接続を再利用でき、データベース接続を格納するためのコンテナと見なすことができます。

データベース接続プールは、リソース共有にリソースプール設計モードを採用し、頻繁なリソース割り当てとリリースの問題を回避します。同時に、統合管理にも便利です。接続プールを制御することで、システムとデータベース間の接続を制限したり、接続数やデータベースの使用状況を監視したりできます。

接続プールの必要性

1.接続プールプロセスを使用しないでください

SQLコマンドを実行する例としてMySQLにアクセスしてみましょう。接続プールが使用されていない場合は、どのプロセスを通過する必要があります。

データベース接続プールを使用しない手順:

  1. TCP接続確立のためのスリーウェイハンドシェイク
  2. MySQL認証のためのスリーウェイハンドシェイク
  3. 実際のSQL実行
  4. MySQLのシャットダウン
  5. TCPの4ウェイハンドシェイクは閉じられています

SQLの一部を実行するために、多くのネットワーク相互作用があることがわかります。
長所:実装が簡単
短所:

  • より多くのネットワークIO
  • データベースの負荷が高い
  • 長い応答時間と低いQPS
  • アプリケーションは頻繁に接続を作成して閉じ、その結果、より一時的なオブジェクトと頻繁なGCが発生します
  • 接続を閉じた後、多くのTIME_WAIT TCPステータスがあります(2 MSL後に閉じられます)

2.接続プールプロセスを使用します

データベース接続プールを使用する手順:

初めてアクセスするときは、接続を確立する必要があります。ただし、その後のアクセスでは、以前に作成された接続が再利用され、SQLステートメントが直接実行されます。
利点:

  • ネットワークオーバーヘッドの削減
  • システムのパフォーマンスが大幅に向上します
  • 問題ありませんTIME_WAIT状態

データベース接続番号の設定

システムは、接続の最小数や接続の最大数などのパラメータを設定することにより、接続プール内の接続を制御できます。接続の最小数は、システムの起動時に作成されるデータベース接続の数です。接続の最小数は少なく、起動は速く、応答は遅いです。通常、設定は大きくなります。接続の最小数は5〜10に設定できます。接続の最大数は、ハードウェア構成に応じて設定されます。4コアマシンは10に設定でき、8コアマシンは20に設定できます。

HikariCPのデフォルトの最大接続数と最小接続数は10です。著者の提案は、接続の最大数と最小数を同じ値に設定し、高性能の接続プールを維持することです。

接続プールの数ができるだけ多くないのはなぜですか?

最初のポイントは、まず第一に、シングルコアCPUが複数のスレッドを「同時に」実行することを知る必要があります。これは単なる幻想です。シングルコアCPUは一度に1つのスレッドしか実行できません。その後、オペレーティングシステムがコンテキストを切り替え、CPUコアは別のスレッドのコードをすばやくスケジュールして実行します。これには、コンテキストの切り替えによって引き起こされる多くの余分なパフォーマンスの低下が伴います。

2つ目のポイントは、上記のNコアサーバーは、データベース接続の数をNに設定することで、最適なパフォーマンスを提供できることです。ただし、実際の状況はディスクIOとネットワークIOの影響を受けます。IO待機時間中、スレッドはブロックされて待機し、CPUはアイドル状態になります。したがって、スレッドがI / Oを多用するビジネス操作を処理している場合、スループットを向上させるために、スレッド/接続の数をCPUの数よりも多く設定する必要があります。

接続数の計算式

连接数 = ((核心数 * 2) + 有效磁盘数)

サーバーのCPUは4コアi7であり、接続プールのサイズは((4 * 2)+ 1)= 9〜10である必要があります。具体的には、実際のビジネスシナリオに応じて調整する必要があります。

ビジネスシーン

  • 同時アクセスの場合は、小さなデータベース接続プールを使用して、残りのビジネススレッドをキューに入れて待機することができます。
  • システム内で長いトランザクションと短いトランザクションが混在している場合、正しいアプローチは、2つの接続プールを作成することです。1つは長いトランザクション用で、もう1つは「リアルタイム」クエリ(短いトランザクション)用です。

参考文献

  1. https://www.jianshu.com/p/15b846107a7c
  2. https://www.cnblogs.com/cocoxu1992/p/11031908.html
  3. https://blog.csdn.net/weiwosuoai/article/details/89955003

おすすめ

転載: blog.csdn.net/LIZHONGPING00/article/details/106985493