POSTGRESQL 压力测试结果与 POSTGRESQL CPU OR 内存 提升性能提升大

数据库与硬件之间的关系，是一个决定数据库性能，必要条件，即使你参数调整的漂亮，你的SQL 撰写的没有问题，但是硬件不行，那么上面说的这一切对于数据库的性能，只能是杯水车薪。

那么如何对一个数据库或者一个应用要使用的数据库，预先通过压测的方式来满足应用在正式运行后的需求，这一点就十分的重要了。我们对于应用上线都是基于严格的，数据库性能测试分析，以及基于应用端的数据库业务性能测试，合而为之一之后的结果，来驱动到底使用多大的配置来应承应用的需求。

本篇文字，是没有业务方面的测试对于POSTGRESQL 的压力测试，但作为一个正规的数据库部门，我们一定是有，不同硬件在同样配置下的POSTGRESQL 的跑分成绩的，并且还要有不同的

1  数据量

2  并发访问量

3  对数据的操作模式

4  不同的参数对于数据库的影响度

本篇中，就是基于4中配置，对POSTGRESQL 13 这个版本的数据库，在以上不同情况下的跑分结果，也是基于某个云跑分的结果。（什么云，那个云，不要问，此篇文字着重，怎么测，为什么这么测，测完怎么分析）

首先测试的硬件配置，一定是通用的，或者我们负担的起的硬件配置，我们不可能像数据库厂商，弄来512G ，256G ，96CORE, 128 CORE的主机来进行压力测试，然后提供一个很好看的分数。终究我们还是要较大实地的去用实际当中存在的主机来进行压力测试。

以下测试中我们通过如下的配置进行了压力测试

硬件配置

4C 8G

4C  16G

8C 64G

16C 32G

测试选项

测试数据形式

insert

delete

oltp

update

update without index

random select

point select

测试的总体数据量大小

单表大小

500万

1000万

5000万

1亿

测试表的数量

测试表的数

10个

20个

5个

测试的线程数

并发线程

10

30

50

70            100

通过不同的匹配项，进行顺序匹配，并且每个选项进行至少10次的测试，以及时间超过5分钟的单次测试。我们总结出如下的一些在POSTGRESQL 13上表现得性能状态。

1   CPU 的核心数的增加，对比内存的增加，在同种压力的情况下，CPU 添加后对系统的性能帮助大。

这点在8C 64G 和 16C 32G 的相关的测试中，对比测试数据的结果很明显，图1是 16C 32G  图2是 8C 64G ，操作的选择项是数据插入，在疯狂的数据插入的过程中线程越多，插入数据之间的行数的差距越大。

所以我们得出一个结论，在数据插入多的系统中，CPU 添加比内存添加要对提升性能更有利，进程越多，越明显。

图 1

图 2 

2  在数据的删除的操作中，下面图3️⃣为 16C 32G 图4️⃣为 8C 32G，从删除的操作角度来看，实际上无论是内存大还是CPU多，对于删除的操作的差别不是很大，CPU 多的状态略好于 内存多的状态。

图3 

图4

3  OLTP ，在OLTP 的操作中，CPU 多的情况下，访问线程多的情况下对于POSTGRESQL 的影响就有不同了，在表的行数多的情况下，部分测试结果中内存大的POSTGRESQL 占有小部分优势，而在线程低，表数量小的情况下二者的差别并不大。

这里我们找出规律是，当表的数据量越来越大的情况下，添加内存和添加CPU 要看访问的频度有多大，如果访问的频度并发大，则还是要添加CPU 优先，而不是内存，但如果访问的频度不大，则优先添加内存。

图5

图6

4  在查询中还有两种查询的方式，如random 查询，也就是我们查询的数据在页面中可能是不关联的，另一种是 range查询，也就是我们搜寻的数据很可能在一个页面或连续的页面中。

这里先说说，这两者查询在在同种配置的查询中，POSTGRESQL 更喜欢的是random point 的查询方式，因为这样的查询方式本身比range的查询的方式在TPS QPS 均有优势。

另外还是在线程的更多需求的状态下，CPU 更多的情况下 random 查询的差距并不是太明显，而在range 查询的状态中，CPU 多比内存多，要多个40%--45%的速度。图7为8C 64G 图8 为 16C 32G

图7

图8

通过这个查询，我们明确了一个问题，在进行范围查询的过程中，CPU 对于数据的提取的速度有明显的提高。

5  那么我们是否就可以得出POSTGRESQL 在数据处理中对于数据的操作应该给更多的CPU 要有利于给更多的内存，----下面的结果就给出了明确的结果

不是

下面的测试中，主要对于数据的UPDATE 有明显差异，尤其是带有索引的数

据在数据更新中。与之前CPU 对所有的数据库操作都有利相反，随着数据量和进程的量的增大的情况下内存更大的情况下，处理的速度更快这点我们在图9 8C 64G 和图10 16C 32G 的测试中可以看出，所以对于大量UPDATE 的操作中，并且你的表有大量的索引的情况下，这样的操作，内存是一个有利提升你操作速度的点。

图9

图10

当然我们还应该针对这些数据，在更多的层面上进行分析，如索引的数量，以及表行数的增长对于计算处理的衰减等等之类更细致的分析。基于时间的因素，我们可能后面在进行更详细的分析。

最后我们得出的结论，如果你的系统不是大量的UPDATE 的数据库系统，则CPU 对于你的大部分操作都有利，大于内存的添加，但如果你的操作中堆表有大量的UPDATE with index的操作，则内存是你需要考虑的提高性能的部分。

同时，数据库方面以上的测试结果是在未进行大幅度优化的情况下，其中我们发现如果将PG 中的与事务刷新有关的参数的值调整后，整体的性能会提高10-30%，但在实际的工作场景中我们并不能因为性能而放弃数据库的安全性。