主要观点：作者进行大量基准测试，其中遇到在 176 核系统上运行只读 pgbench 时出现吞吐量异常的问题，虽进行多种推测但仍未完全理解原因，包括锁定、CPU 资源、CPU 功率/热管理、NUMA 等方面，同时探讨了内核任务调度、调度器统计、锁定、内核版本、FreeBSD、TCP/IP、系统繁忙程度、流水线等可能的原因，并在不同系统上进行测试，最后总结并提供相关更新。

关键信息：

• 在 176 核系统上运行只读 pgbench 时，22 个客户端时吞吐量约 500k tps，22 个之后突然下降到约 350k tps，100 个客户端时问题消失，吞吐量约 20k tps。
• 推测锁定不是原因，因只读 pgbench 只需共享锁，且锁未在相关地方显示；CPU 资源竞争也不像，CPU 缓存与总内存相比较小，但突然增加的 100 个客户端与该理论矛盾；CPU 功率/热管理似乎也不是，系统状态未显示该情况且问题在 100 个客户端时消失；NUMA 也不太可能，Postgres 对 NUMA 不敏感，且忙碌核心的选择看似随机。
• 内核任务调度可能相关，通过补丁将后端和 pgbench 线程显式固定到核心，“共置”策略效果好，“随机”策略有问题，说明任务放置很重要；调度器统计显示一些相关性，但仍不理解吞吐量变化的原因；锁定虽有热点锁，但相关补丁未解决问题；不同内核版本（6.11 和 6.15）测试结果相似，FreeBSD 上也有该问题，切换到 TCP/IP 影响较小；系统繁忙程度很重要，让核心空闲会显著降低吞吐量，流水线可使后端更忙碌从而解决问题；在其他系统（96 核 EPYC 和 44/88 核 Xeon）上测试也有类似但不同的行为。

重要细节：

• 各种测试的图表及数据，如不同客户端数量下的吞吐量图表、各种策略下的 pgbench 结果图表、perf 统计的相关事件图表等。
• 测试的具体环境和步骤，包括使用的数据库配置、测试脚本等。
• 后续更新内容，如在 mastodon 上的讨论、测试细节分享、相关脚本和结果的存档等。