数据库连接池配置技巧

配置连接池是开发人员经常会遇到的事情。本文讲述配置连接池时需要了解的原则,其中几个可能违反直觉。

如何应对一万个前端并发访问

想象一下,如果你有这样一个网站,它虽没有达到Facebook的规模,但仍有每秒10000个用户同时发出数据库请求 - 每秒约有20000笔交易。你的连接池应该设为多大?可能会让感到惊讶的是,问题不是应该设为多大,而是多小!

首先请观看Oracle Real-World Performance小组发布的这段短视频

从视频中可以看到,你可以看到只需减少连接池大小,在没有任何其他变化的情况下,应用程序的响应时间就从约100ms减少到约2ms - 约50倍的性能提升。

为什么?

在计算的其他领域我们似乎已经熟知“少即是多”。但为什么只有4线程的nginx的性能可以大大超过拥有100个进程的Apache服务器?如果回想一下计算机科学基础,原因不是很明显吗?

即使是只有一个CPU核心的计算机也可以“同时”支持数十或数百个线程。但是我们应该知道这只是操作系统的一个障眼法,背后只是时间切片的魔法。实际上,这个单核一次只能执行一个线程,操作系统通过切换上下文,让该内核再为另一个线程执行代码,依此类推,给人以多线程同时执行的感觉。密集计算的基本法则是:给定一个CPU资源,按顺序执行A和B总是比通过时间片“同时”执行A和B要快。一旦线程数量超过了CPU核心的数量,通过添加更多的线程就会变慢,而不是更快。

但万事总有例外......

有限的资源

现实的情况并不像上面所说的那么简单,还有其他一些因素需要考虑。让我们看看数据库的主要瓶颈有哪些,它们可以归纳为三个基本类别:CPU,磁盘,网络。内存也可以算作是瓶颈的一种,但你应该知道与磁盘和网络相比,它的性能有几个数量级的差异。

如果我们忽略磁盘和网络,问题就会很简单。在具有8个核心的服务器上,将连接数设置为8会提供最佳性能。由于上下文切换的开销,超出此范围的任何设置都会导致性能下降。

但我们不能忽视磁盘和网络。数据库通常将数据存储在磁盘上。而传统磁盘由金属旋转板组成,读写头安装在步进电机驱动臂上。读写头一次只能在一个地方读写,并且必须寻找新的磁道以读写不同的数据。所以即有寻道时间的成本,也有轮转时间成本。也就是说我们需要等待磁盘转到正确的位置,以便再次读取或写入数据。硬盘缓存虽然有帮助,但这个原则仍然适用。

在此期间(即IO等待期),连接或查询线程只能阻塞在那里等待磁盘。在这个时间段,操作系统可以通过为另一个线程执行代码来更好地使用CPU资源。所以,正是由于线程在IO上被阻塞,我们才可以通过创建大于CPU核心数的连接线程来完成更多的工作。

但应该创建多少线程呢?下面我们继续讨论。具体多少还取决于磁盘子系统,较新的SSD驱动器没有“寻道时间”成本。但不要盲目地以为,“SSD更快,因此我就应该创建更多线程”。事实恰恰相反在:更快的读写速度,无寻道成本,没有机械旋转的延迟,意味着更少的阻塞,因此更少的线程(即更接近内核数)会比更多的线程效果更好。

网络与磁盘类似。通过以太网接口读写数据时,也会在它接口的发送/接收缓冲区填满时引入阻塞。 万兆网卡优于千兆网卡,千兆网上优于百兆网卡。由于在资源阻塞方面,网络处于最后一位,有些人经常在计算中忽略它。

下图是另一份连接数与性能关系图表:

连接池大小与性能

可以从上图的PostgreSQL基准测试表现里看出,从大约50个连接时,TPS开始变平。前面的Oracle视频展示了将连接数从2048降到96。我们会说即使是96也极有能可能太在,除非你用的是16或32核的CPU。

公式

下面的公式是从PostgreSQL文档里摘录的,但我们相信它也适用于大部分其它数据库。你应该以此为出发点,测试你的应用,模拟预期负载,并据此尝试不同的连接池设置:

连接数 =((CPU核心数 * 2)+ 有效的转轴数)

如何理解此公式呢?以带有一个硬盘的4核i7服务器为例,连接池大小就为9,即((4 * 2)+ 1)。取整数为10也行。看来是不是太小?试试看,我打赌用此设置,你可以轻松处理3000个前端用户在6000 TPS下运行简单查询。在测试中你可能会发现,将连接数从10逐渐增大时,TPS开始下降,并且前端响应时间开始攀升。

你需要一个尽量小的连接池,所有线程均处于等待连接状态。

如果你拥有10000个前端用户,那么将连接池大小设为10000就是疯狂;设为1000就是可怕,设为100仍然过大。你需要尽量小的连接池,最多几十,应用的其它线程阻塞应该在等待连接池的连接上。一个调整适当连接池,应设置在数据库能并发查询的极限处 - 这很少超过上面提到的(CPU内核* 2)。

在我的内部项目中,我总能发现一些令人惊讶的Web应用,它们通常只有几十个前端用户,执行周期性操作,却配有上百个连接的连接池。请不要过度配置你的数据库。

池死锁

对于同时获取许多连接的单个请求者,确实存在“池死锁”的问题。这在很大程度上是应用级别的问题。增加池大小的确可以缓解这种情况下的锁定问题,但你在增加连接池大小之前应首先检查在应用级别可以执行的操作。

为避免死锁,连接池大小可通过一个相当简单的公式估算:

连接池大小 = Tn×(Cm-1)+ 1

其中Tn是线程的最大数量,Cm是单个线程持有的最大并发连接数。

例如,有三个线程(Tn = 3),每个线程需要4个连接来执行某个任务(Cm = 4)。能确保无死锁的连接池大小最小为:3 x(4 - 1)+ 1 = 10

再例如,对于最多8个线程(Tn = 8),每个线程需要3个连接来执行一些任务(Cm = 3)。能确保无死锁的连接池大小最小为:8×(3-1)+ 1 = 17

上述大小不一定是连接池的最佳大小,但是它是避免死锁所需的最小值。

在某些环境中,使用JTA(Java事务管理器)可以显著减少从同一线程的getConnection()请求的连接数。

友好提示

连接线程池的大小的设置非常依赖于具体的部署场景。

例如,同时存在长时间和短时间的事务的系统通常最难调优。在这些情况下,创建两个连接池实例或许可以很好地工作(一个用于长时间运行的事务,另一个用于实时查询)。

在以长时间事务为主的系统中,所需连接数大小通常由外部因素限制 - 例如只允许一定数量的任务队列。在这些情况下,任务队列大小应该是与连接池大小匹配。


本文译自About-Pool-Sizing

留言