Kubernetes集群使用NFS共享存储时PostgreSQL性能变慢问题咨询

性能变慢与NFS存储的关联性 #

可以明确的是，NFS存储极大概率是PostgreSQL性能持续下降的核心诱因，原因如下：

• PostgreSQL作为事务型关系数据库，对IO延迟、fsync刷盘一致性、随机IOPS有极高要求，而NFS天生是网络文件存储，IO路径比本地块设备多了网络传输链路开销，基础延迟就远高于本地存储
• NFS的fsync实现需要客户端等待服务端刷盘确认后才返回结果，比本地文件系统的fsync操作慢数倍到数十倍，而PostgreSQL每次事务提交都会触发WAL日志的fsync调用，该环节会直接成为性能瓶颈
• 多PostgreSQL实例共享同一块NFS存储时，会出现明显的IO资源争抢，导致整体IOPS被摊薄、IO延迟进一步升高
• 部分低版本NFS服务端对POSIX文件锁语义支持不完善，PostgreSQL依赖文件锁实现实例互斥，锁实现异常时不仅会拖慢性能，还存在数据损坏的风险

适配K8s PostgreSQL场景的存储方案推荐 #

本地存储（性能最优） #

使用K8s原生Local PersistentVolume，直接绑定节点的本地SSD/NVMe盘，完全规避网络IO开销，IO性能和物理机部署数据库无差异，适配对性能要求极高的核心业务场景。使用时配合StatefulSet的节点亲和性调度规则，保证Pod重建后能够调度回原节点挂载对应本地盘即可。

分布式块存储（平衡性能与高可用） #

• Ceph RBD：成熟的开源分布式块存储方案，三副本机制保证数据可靠性，支持快照、在线扩容，IO性能比NFS高3~10倍，K8s CSI驱动适配成熟，是生产环境数据库场景的主流选型
• Longhorn：轻量级K8s原生分布式存储，运维复杂度远低于Ceph，支持实时备份、跨节点数据同步，适合中小规模K8s集群的数据库存储场景
• OpenEBS：云原生开源存储方案，支持本地PV、分布式块存储多种部署模式，可根据业务需求灵活选择，性能损耗低，适配性好

公有云托管块存储（云场景最优） #

如果K8s集群部署在公有云环境，直接使用公有云提供的SSD云盘/极速SSD云盘对应的官方CSI驱动即可，云厂商原生优化的块存储可靠性和性能都有保障，运维成本最低。

临时优化建议：若暂时无法更换存储，可先调整NFS挂载参数为rw,sync,hard,noatime,nodiratime,rsize=1048576,wsize=1048576，同时保证NFS服务端与K8s节点之间使用万兆以上网络互联，将PostgreSQL的WAL日志目录和数据目录分开挂载到不同的NFS共享路径减少IO争抢。该方案仅为临时缓解，核心业务场景建议尽快更换存储方案。

内容的提问来源于stack exchange，提问作者Lee