由 John Doe 十月 13, 2026
Postgres 作为一个重要的开源数据库系统，在 Linux 平台上的运行表现备受关注。经过多年演进与优化，其与 Linux 内核的互动也逐渐深刻。
目录
来自微软的 Postgres 资深工程师 Andres 分享了多年积累的经验与思考，既涵盖了技术细节，也探讨了社区互动的现实障碍与未来可能的合作方向。
本文深入总结了他的观点，揭示 Postgres 在 Linux 上的技术痛点、与内核社区的协作成果，以及如何进一步推动双方更好地合作，带来性能提升与稳定性保障。
Postgres 与 Linux 内核：18 年的交织故事
Andres 在 Postgres 项目已经工作了将近 18 年，目前在微软专注于开源 Postgres 的工作。他从多个角度回顾了过去 Postgres 在 Linux 平台遇到的关键问题，以及与内核社区的合作经验。
过去影响深远的内核问题
- Fsync Gate 事件：Postgres 在使用 fsync 保证数据持久性时，曾经遇到 Linux 以及其它操作系统中关于设备错误处理不当，导致缓存页中“脏”数据被丢弃，最终引发数据可靠性风险。这个问题的解决成了 Postgres 社区较早主动介入 Linux 内核交流的标志。
- io_uring 的兼容性问题：Postgres 2018 年开始尝试使用 io_uring 来提升 IO 性能，但发现在多进程环境下存在不兼容问题，这促使社区持续改进内核的 io_uring 实现。
- 其他包括性能倒退、内核补丁评估偏差等现象，涉及 Postgres 真实场景下的性能表现，有时因测试覆盖不充分导致误判。
内核社区交流的挑战
虽然 Postgres 团队与内核维护者有一定深度的交流，但实际内部参与者相对有限。Andres 个人常因兴趣和岗位职责成为桥梁，但这并非理想的“可扩展”状态。主要原因包括：
- Postgres 开发者多数对 Linux 内核了解不足，难以有效判别何时、如何向哪个内核子系统反馈问题。
- Linux 内核社区的沟通风格曾让部分开发者感到害怕和排斥，虽然近年有所改善，但依然存在一定的门槛。
- 大量且复杂的内核开发活动难以跟踪和消化，缺乏专门关注数据库类应用的沟通与协作平台。
Postgres 在 Linux 上持续优化的技术热点
Postgres 对 Linux 的依赖深入且细致。从 Andres 的分享中，可以梳理出近年来及当前几个核心技术趋势：
1. 多线程模型的转型
Postgres 传统的多进程模型固然稳定，但不利于实现某些长期目标，例如在同一线程内处理多个连接的状态切换。
转向多线程模型：
- 降低上下文切换开销，提升 TLB（翻译后备缓冲区）利用率
- 使文件描述符空间统一，简化资源调配和复用
这并非受内核压力驱动，而是源自可维护性和部分性能需求。
2. 利用 io_uring 加速异步 IO
Postgres 从 2018 年起积极推动基于 io_uring 的异步 IO 支持，用于降低 IO 延迟。
采用多工作进程并行同步 IO 的方式，反而在某些场景下性能胜过单进程利用 io_uring 异步 IO，反映 kernel 和应用层优化还存在调整空间。
正在探索更灵活的 io_uring 机制支持（如跨多个已注册缓冲区写入）以适配 Postgres 缓冲池的复杂性。
利用 Atomic Writes（原子写）减少日志抖动、优化故障恢复机制，但内核当前只支持单次小幅原子写，限制了效果。
3. 缓存和写入策略调整
不太可能全面启用 O_DIRECT（直接 IO）作为默认，因为大部分 Postgres 运行环境无法独占主机，必须在内核缓冲与页面缓存之间平衡。
利用**同步文件范围（sync_file_range）**配合延迟写回策略，避免写入高峰期的 I/O 延迟爆发。
关注透明大页（THP）使用的不稳定性，以及对指令纹理映射（ITLB）缺页率的性能影响。
探索巨页配置（2MB、1GB 巨页）对 IO 密集负载的影响，发现超大巨页（1GB）在高并发时反而引发内核锁竞争，反而降低性能。
4. Futex 与调度器的瓶颈
Postgres 大量依赖锁（latch、futex）同步，futex 查找过程（哈希表访问）消耗显著 CPU。
Futex 机制本身缺乏对持锁线程的调度优先支持，导致锁竞争严重时尾延迟显著增长。
Priority Inheritance futex 虽然解决部分调度问题，但性能开销过大，不适合 Postgres 典型负载。
时间片扩展（time slice extensions）虽然理论上能提升调度效率，但由于 Postgres 在持锁时需执行不允许的系统调用，实用性有限。
5. 内存过载与 cgroup 限制
生产中 Postgres 常运行于 cgroup／容器环境，需要配置 overcommit_memory=2 规避内存不足导致的 OOM 杀进程。
cgroup 内对内存压力的反馈机制尚不支持返回失败，Postgres 难以在容器内正确感知和响应内存紧张状态，影响稳定性。
6. 文件系统分配策略问题
为保证 checkpoint 期间预留足够磁盘空间，Postgres 采用 fallocate 预分配。
该做法导致文件系统碎片化加剧，覆写预分配区块时频繁产生日志写入，影响性能。
某些文件系统已开始支持基于锁定写零（flock write zeros）避免该问题，但仍未全面成熟。
复制写（copy-on-write）文件系统基本无法支持有效空间预留，生产场景面临风险。
运行中的奇怪现象：CPU 迁移与性能“浴缸曲线”
在对 Postgres 并发负载的性能测试中，经常观察到某些怪异的现象：
- 性能随着并发客户端数增加，先快速提升，随后出现长时间平台期（“浴缸底”），性能停滞不前，再突然迅速反弹上升。
- 部分案例发现禁用 CPU 空闲状态，能改善准确性和性能稳定性。
- 观察 CPU 迁移活动显著增加，意味着线程/进程在不同 CPU 核心间频繁切换，严重影响缓存命中和调度效率。
这是一个复杂且多源的性能陷阱，涉及 CPU 电源管理、调度器策略、硬件差异等多重因素，且在不同 Linux 版本与硬件设备之间表现差异较大。
Linux 内核互动的现状与未来展望
现阶段社区互动的难点
Postgres 与 Linux 内核开发者间存在信任和理解鸿沟，新的性能问题不易获得快速响应。
用户空间开发者通常缺乏必要的 Linux 内核知识，很难精准、高效地交流需求。
内核开发文档繁杂，信息更新快，学习曲线陡峭，缺少针对数据库开发者的定制化培训。
何以建立更有效的桥梁？
组织专门的工作坊或培训，帮助 Postgres 和类似项目的开发者理解 Linux 内核架构、子系统功能及调试流程。
促进双向交流机制，如邀请内核开发者赴 Postgres 会议分享经验，反之亦然。
共同优化评测基准，使其更贴近真实数据库负载，提升内核补丁测试的参考价值。
更广泛地吸引社区更多成员参与，不只依赖少数核心开发者，打造多点协作模式。
实用建议与思考总结
对 Postgres 和其它数据库开发者
加深 Linux 内核知识学习，不仅提升问题诊断能力，也增强社区发声的自信和专业度。
定期关注内核更新和相关子系统动态，如 IO、调度器、内存管理等，与内核社区形成良好信息反馈链。
增强测试覆盖，尽可能在多平台、不同硬件及配置下复现性能和稳定性问题。
对 Linux 内核社区和维护者
理解用户空间应用（尤其是数据库）的特殊需求及复杂场景，尽量提供针对性支持。
对待新用户报名保持耐心和包容，积极扶持其快速融入社区。
促进跨项目互动，建立更开放友好的技术传播机制。
结语
Postgres 作为重要的数据库系统，与 Linux 内核的深度融合是持续优化性能和可靠性的关键。虽然当前在技术细节与社区协作上还面临诸多挑战，但随着双方不断加深理解和合作，未来值得期待。
提升数据库与内核的契合度，不仅能带来性能飞跃，更能促进开源生态的繁荣共赢。希望这次分享能为更多开发者打开通往协作之路的大门。
常见问答
Postgres 是否支持其它操作系统？
Postgres 支持多平台编译，包括 Linux、MacOS 等，但 MacOS 的文件系统和上下文切换性能较慢，因此不适合用来做高性能数据库基准测试。
如何改善 Futex 锁竞争带来的性能问题？
尽管 Priority Inheritance 技术能在一定程度上减少尾延迟，但其开销较大不适用于高频锁场景。未来希望有更高效的锁调度机制，或支持“定向唤醒”优化。
io_uring 在 Postgres 中的应用成果如何？
已实现了基本的异步读写支持，但性能表现受到进程并发数、内存带宽及硬件限制影响，仍需进一步内核与应用层协同优化。
Linux CPU 电源管理对数据库性能影响大吗？
在虚拟机和某些硬件上，相当明显。禁用深度空闲状态可以提升性能一致性，但会增加功耗，需要根据实际场景权衡。
感谢阅读！欢迎继续关注 Postgres 和 Linux 性能调优的最新进展。
参考
Andres Freund: Kernel Recipes 2026 Postgres on, vs, with Linux