托马斯·冯德拉：基准测试很困难，有时……
💡
原文英文，约4000词，阅读约需15分钟。
📝
内容提要
基准测试中发现，使用pgbench进行只读操作时，客户端数量增加到22时吞吐量骤降，100个客户端时又恢复。分析排除了锁、CPU资源竞争和NUMA等因素，怀疑与内核任务调度有关。将进程固定到同一核心后，吞吐量显著提升，表明任务调度对性能影响显著。
🎯
关键要点
- 基准测试中发现，使用pgbench进行只读操作时，客户端数量增加到22时吞吐量骤降，100个客户端时又恢复。
- 分析排除了锁、CPU资源竞争和NUMA等因素，怀疑与内核任务调度有关。
- 将进程固定到同一核心后，吞吐量显著提升，表明任务调度对性能影响显著。
- 在22个客户端时，吞吐量从500k tps骤降至350k tps，随后在100个客户端时恢复至20k tps。
- 怀疑内核任务调度可能导致后端进程和pgbench线程在不同核心上运行，影响性能。
- 通过固定进程到同一核心，吞吐量显著改善，表明任务调度位置的重要性。
- 在不同的系统配置和内核版本下，问题依然存在，表明不是特定于某个内核版本。
- 在FreeBSD上测试时，发现问题依然存在，说明不是Linux特有的行为。
- 通过TCP/IP连接而非Unix套接字时，问题仍然存在，但影响较小。
- 在系统繁忙时，基准测试的吞吐量意外提高，表明核心闲置可能导致性能下降。
- 通过管道化多个查询，可以提高后端的活跃度，减少性能问题的出现。
- 在不同硬件上进行测试时，发现类似的吞吐量下降现象，表明问题具有普遍性。
❓
延伸问答
在基准测试中，客户端数量增加到多少时吞吐量骤降？
当客户端数量增加到22时，吞吐量骤降。
吞吐量在100个客户端时有什么变化？
在100个客户端时，吞吐量恢复至每个客户端约20k tps。
分析中排除了哪些因素导致吞吐量下降？
分析排除了锁、CPU资源竞争和NUMA等因素。
将进程固定到同一核心后，吞吐量有什么变化？
将进程固定到同一核心后，吞吐量显著提升。
在不同系统配置和内核版本下，问题是否依然存在？
在不同的系统配置和内核版本下，问题依然存在，表明不是特定于某个内核版本。
在FreeBSD上测试时，吞吐量表现如何？
在FreeBSD上测试时，发现问题依然存在，说明不是Linux特有的行为。
➡️
