深度剖析：Web 应用的数据库链接池大小如何设置.docxVIP

深度剖析：Web 应用的数据库链接池大小如何设置 2021-09-07 点击上方 关注,?星标或置顶一起成长 免费送 1024GB 精品学习资源? 来源：/bBq9 我在争辩 HikariCP（一个数据库连接池）时无意间在 HikariCP 的 Github wiki 上看到了一篇文章，这篇文章有力地衰退了我一直以来的疑虑，看完之后感觉神清气爽。 本文内容 95% 译自这篇文章： /brettwooldridge/HikariCP/wiki/About-Pool-Sizing 数据库连接池的配置是开发者们经常搞出坑的地方，在配置数据库连接池时，有几个可以说是和直觉背道而驰的准绳需要明确。 1 万并发用户访问 想象你有一个网站，压力虽然还没到 Facebook 那个级别，但也有个 1 万上下的并发访问，也就是说差不多 2 万左右的 TPS。 那么这个网站的数据库连接池应当设置成多大呢？结果可能会让你惊异，由于这个问题的正确问法是：“这个网站的数据库连接池应当设置成多小呢？” 下面这个视频是 Oracle Real World Performance Group 发布的，请先看完： /video/x2s8uec 由于这视频是英文解说且没有字幕，我替大家做一下简约的概括：视频中对 Oracle 数据库进行压力测试，9600 并发线程进行数据库操作，每两次访问数据库的操作之间 sleep 550ms，一开头设置的两头件线程池大小为 2048： 初始的配置 压测跑起来之后是这个样子的： 2048 连接时的功能数据 每个恳求要在连接池队列里等待 33ms，获得连接后执行 SQL 需要 77ms，此时数据库的等待大事是这个熊样的： 各种 buffer busy waits 各种 buffer busy waits，数据库 CPU 在 95% 左右（这张图里没截到 CPU）。 接下来，把两头件连接池减到 1024（并发什么的都不变），功能数据变成了这样： 连接池降到 1024 后 猎取链接等待时长没怎样变，但是执行 SQL 的耗时削减了。 下面这张图，上半部分是 wait，下半部分是吞吐量： wait 和吞吐量 能看到，两头件连接池从 2048 减半之后，吐吞量没变，但 wait 大事削减了一半。 接下来，把数据库连接池减到 96，并发线程数仍旧是 9600 不变。 96 个连接时的功能数据 队列平均等待 1ms，执行 SQL 平均耗时 2ms。 wait 大事几乎没了，吞吐量上升。没有调整任何其他东西，仅仅只是缩小了两头件层的数据库连接池，就把恳求响应时间从 100ms 左右缩短到了 3ms。 But Why？ 为什么 Nginx 只用 4 个线程发挥出的功能就大大超越了 100 个进程的 Apache HTTPD？回想一下计算机科学的基础学问，答案其实是很明显的。 即便是单核 CPU 的计算机也能“同时”运转数百个线程。但我们都[应当]晓得这只不过是操作系统用时间分片玩的一个小把戏。 一颗 CPU 核心同一时辰只能执行一个线程，然后操作系统切换上下文，核心开头执行另一个线程的代码，以此类推。 给定一颗 CPU 核心，其挨次执行 A 和 B 永久比通过时间分片“同时”执行 A 和 B 要快，这是一条计算机科学的基本法则。 一旦线程的数量超过了 CPU 核心的数量，再添加线程数系统就只会更慢，而不是更快。这几乎就是真理了…… 有限的资源 上面的说法只能说是接近真理，但还并没有这么简约，有一些其他的因素需要加入。 当我们查找数据库的功能瓶颈时，总是可以将其归为三类：CPU、磁盘、网络。 把内存加进来也没有错，但比起磁盘和网络，内存的带宽要高出好几个数量级，所以就先不加了。 假如我们无视磁盘和网络，那么结论就格外简约。在一个 8 核的服务器上，设定连接/线程数为 8 能够供应最优的功能，再添加连接数就会因上下文切换的损耗导致功能下降。 数据库通常把数据存储在磁盘上，磁盘又通常是由一些旋转着的金属碟片和一个装在步进马达上的读写头组成的。 读/写头同一时辰只能消灭在一个地方，然后它必需“寻址”到另外一个位置来执行另一次读写操作。 所以就有了寻址的耗时，此外还有旋回耗时，读写头需要等待碟片上的目标数据“旋转到位”才能进行操作。使用缓存当然是能够提升功能的，但上述原理仍旧成立。 在这一时间段（即I/O 等待）内，线程是在“堵塞”着等待磁盘，此时操作系统可以将那个空闲的 CPU 核心用于服务其他线程。 所以，由于线程总是在 I/O 上堵塞，我们可以让线程/连接数比 CPU 核心多一些，这样能够在同样的时间内完成更多的工作。 那么应当多多少呢？这要取决于磁盘。较新型的 SSD 不需要寻址，也没有旋转的碟片。 可别想当然地认为“SSD 速