我们刚开始调查使用Postgres作为我们系统的后端，它将与OLTP类型的工作负载一起使用：＆gt; 95％（可能> 99％）的交易将1行插入4个单独的表中，或更新1行。我们的测试机器运行9.5.6（使用开箱即用的配置选项）在一个适度的云托管Windows VM上，配备4核i7处理器和传统的7200 RPM磁盘。这比我们的目标生产硬件慢很多，但现在用于找到我们基本设计的瓶颈。
我们的初步测试非常令人沮丧。尽管insert语句本身运行得相当快（组合执行时间大约为2ms），但由于commit语句需要38 ms，因此整个事务时间大约为40ms。此外，在一个简单的3分钟负载测试（5000个事务）中，我们每秒只能看到大约30个事务，pgbadger报告在“commit”（平均38毫秒）中花费了3分钟，而下一个最高的语句是分别在10（2ms）和3（0.6ms）处插入。在此测试期间，postgres实例上的cpu固定为100％
在提交中花费的时间等于测试的耗用时间这一事实告诉我，不仅提交序列化（不出意外，考虑到此系统上相对较慢的磁盘），但是它在消耗cpu期间那个持续时间让我感到惊讶。我会假设，如果我们受到i / o约束，我们会看到非常低的CPU使用率，而不是高使用率。
在进行一些阅读时，似乎使用Asynchronous Commits可以解决很多这些问题，但是在崩溃/立即关机时需要注意数据丢失。类似地，将事务一起分组到单个开始/提交块中，或者使用多行插入语法也可以提高吞吐量。
所有这些选项都可供我们使用，但在传统的OLTP应用程序中，它们都不是（您需要快速，原子，同步的事务）。对于运行在比这台测试机慢得多的硬件上的其他RDBM，4核盒上每秒35次交易将是不可接受的，这让我觉得我们做错了，因为我确信Postgres有能力处理更高的工作量。
我环顾四周但找不到一些常识配置选项，可以作为调整Postgres实例的起点。有什么建议吗？
答案 0 :(得分：0)
如果COMMIT是你的时间，那可能意味着：
您的系统尊重FlushFileBuffers系统调用，应该是这样。
你的I / O速度很慢。
您可以在fsync = off中设置postgresql.conf进行测试，但不要曾在生产系统上执行此操作。如果这可以大大提高性能，那么当您实际需要将数据写入磁盘时，您就会知道I / O系统非常慢。
在不牺牲数据持久性的情况下，PostgreSQL（或任何其他可靠的数据库）无需改进。
答案 1 :(得分：0)
虽然看到OLTP工作负载的一些良好的启动配置会很有趣，但我们已经解决了我们在提交过程中不合理的高CPU的神秘面纱。事实证明它根本不是Postgres，它是Windows Defender不断扫描Postgres数据文件。设置托管测试服务器的VM的团队并不了解我们需要后端配置而不是用户配置。