原文链接： http://akorotkov.github.io/blog/2016/05/09/scalability-towards-millions-tps/
在很久以前，多内核和多网络套接字的服务器被广泛使用后，PostgreSQL的可伸缩性在这些服务器上的优化已成为一个研究课题。这有一篇[博客]显示了在8.0版本和8.4版本之间进行垂直扩展的简要历史。PostgreSQL 9.2版本在可伸缩性方面有了显著的提高。得益于快速路径锁定功能和其他优化方法，在仅SELECT查询的pgbench性能测试中，单实例TPS已可达35万。最新稳定的PostgreSQL 9.5版本也包含了大量重要的可伸缩性功能优化，包括LWLock功能的优化，在仅SELECT查询的pgbench性能测试中，大约可达到40万TPS。
Postgres的专业服务公司也加入了可伸缩性的优化工作。在与IBM的合作中，我们研究了PostgreSQL的可伸缩性在现代的Power8服务器上的优化。 研究结果发布在很流行的俄罗斯博客网站habrahabr . 我们主要使用到了两种方式来提高PostgreSQL在Power8服务器上的可伸缩性:
- 实现Pin/UnpinBuffer() ，使用CAS 操作来代替缓存头的spinlock；
- 优化LWLockAttemptLock() 在装配线的处理，减少改变lwlock 状态的循环次数。
在上图中，我们比较了以下的PostgreSQL版本的表现：
- 9.5.2 版本 – 峰值出现在60用户时达54万TPS；
- 9.6 主版本 – 峰值出现在100用户时达106万TPS；
- 9.6 主版本，配置为所有PGXACT全部使用缓存流水线队列 – 峰值出现在200用户时达172万TPS。
队列问题有必要解释一下。开始，因为发现性能的衰减问题，我提交了5364b357补丁，但它会增加clog缓冲的数值，这本身是有点奇怪的，因为只读测试是不应该查询clog缓冲的。我们期望的结果是clog缓存不会真正直接地影响只读类性能，5364b357补丁只是修改的共享内存结构的布局。
测试结果显示只读类测试对共享内存的结构非常敏感。因此，测试性能的结果会因共享内存大小(share_Buffers)、最大连接数(max_connections)和其它影响共享内存分配的参数的变化而发生较大变化。当我给了Andres一台很强大的服务器时，他很快就找到一种方法来处理性能的不正常情况：将所有活动事务(PGXACT)进行缓存排队。当没有打补丁时，SnapshotResetXmin() 中脏的处理器缓存包含多个PGXACTs。 打了补丁后，SnapshotResetXmin() 中脏的处理器缓存仅包含一个活动事务。这样GetSnapshotData()中缓存大部分都可以命中。 我对这个结果很吃惊，也算是给了我一个教训。我知道队列会影响性能，但没想到影响有这么大。活动事务的缓存流水线队列问题是在9.6版本的特性冻结之后发现的，这也意味着这个补丁只会出现在9.7版本的开发中了。然而，9.6版本还是有非常显著的可伸缩性提升的。
因此，PostgreSQL单实例可以实现超一百万的TPS，也可以说PostgreSQL开创了百万TPS的新时代。
在此我也要感谢以下朋友们：
- Andres Freund，是这个补丁包的共同开发者和审核者；
- 我在PostgresPro公司的同事，Dmitry Vasilyev帮助做了很多的性能测试，YUriy Zhuravlev 帮助对这个补丁的原理作了第一版的证明；
- Dilip Kumar和Robert Haas他们帮助进行了这项测试。
jjjj