优化 Lakebase Postgres 计算缓存
内容提要
Databricks 为 Lakebase Postgres 优化计算节点缓存：在固定规格计算上停用本地文件缓存，将共享缓冲区设为内存的75%，并启用2MB大页以减少页表和TLB开销。实测吞吐翻倍、延迟下降、CPU占用降低，存储读取请求大减。下一步将把大共享缓冲区扩展至自动伸缩计算。
延伸解读
缓存架构调整的实际影响
Lakebase Postgres 在固定规格计算上停用本地文件缓存（LFC），将共享缓冲区设为内存的75%，并启用2MB大页。这一调整消除了原先约1GB的共享缓冲区上限，使热数据保留在最快的内存层，避免级联到本地文件存储。同时，由于缓存完全位于Postgres内部，消除了双重缓冲，1GB缓存数据仅消耗1GB内存，而非之前的2GB。
大页机制的性能收益与实现要点
Postgres每个后端进程需独立映射共享缓冲区，默认4KB页会导致大量页表项和TLB未命中。改用2MB大页后，页表大小减少512倍，显著降低TLB未命中率。实测显示，尾读延迟降低约40%，CPU利用率下降约30%。Lakebase在虚拟机层面通过显式HugeTLB页提供支持，确保从宿主机到客户机内核的一致性，避免因某一层缺失而削弱收益。
生产环境实测效果
在大型生产端点上，启用新配置后吞吐量翻倍，p50和p99延迟降低，存储GetPage/s从约8K/秒降至约1.5K/秒。另一端点吞吐量提升约43%，计算缓存命中率接近100%，CPU使用从20核降至4核。这些改进已在固定规格计算（CU>=80）上生效，用户可通过show shared_buffers验证，80 CU端点应返回20971520。
未来方向与自动伸缩挑战
当前优化仅适用于固定规格计算，因为共享缓冲区尚不能动态调整。下一步是将大共享缓冲区扩展至自动伸缩计算，这需要动态扩展和收缩共享缓冲区，并精确分配所需的大页数量。Databricks已开发协议，使大页随动态共享缓冲区同步伸缩，以在高并发和大内存下保持高效地址转换。后续文章将深入技术细节及对开源Postgres的贡献。
Q&A
Lakebase Postgres 在计算缓存方面做了哪些优化？
Lakebase Postgres 在固定规格计算上停用了本地文件缓存（LFC），将共享缓冲区设置为内存的75%，并启用了2MB大页以减少页表和TLB开销。
为什么 Lakebase Postgres 要停用本地文件缓存？
因为本地文件缓存（LFC）作为共享缓冲区的补充，在较大工作集下，共享缓冲区被限制在1GB，导致大多数缓存命中经过较慢的LFC层。停用LFC并扩大共享缓冲区可以将热数据保留在最快的内存层。
启用大页对 Lakebase Postgres 性能有什么影响？
启用2MB大页减少了页表大小和TLB未命中率，基准测试显示尾部读延迟降低高达40%，CPU利用率降低高达30%。
Lakebase Postgres 优化后吞吐量和延迟有何变化？
优化后吞吐量翻倍，延迟下降，CPU占用降低，存储读取请求大减。例如，一个端点吞吐量增加约43%，CPU使用从20核降至4核。
如何检查 Lakebase Postgres 是否启用了大共享缓冲区？
可以在 Postgres 连接中运行 show shared_buffers 命令。例如，一个80 CU的端点应看到值20971520。
Lakebase Postgres 下一步计划是什么？
下一步是将大共享缓冲区扩展到自动伸缩计算，需要动态扩展和收缩共享缓冲区，并同步调整大页分配。
