问题描述
将 OLAP 业务数据库从 x86 迁移到鲲鹏 920(64 核 / 256GB 内存 / 1TB NVMe SSD),PostgreSQL 14 大部分查询正常,但某些复杂聚合查询的响应时间波动很大——快的 2 秒完成,慢的要 8 秒以上。用 EXPLAIN ANALYZE 检查,执行计划相同,但每次实际耗时差异明显。
排查过程
进一步检查 PostgreSQL 是否使用了大页:
效果验证
对波动明显的聚合查询进行多次测试:
小结
鲲鹏上 PostgreSQL 查询性能波动的根因是 shared_buffers 默认值太小且未启用大页,内存访问走普通页表导致 TLB miss 不稳定。核心优化点:配置系统大页(nr_hugepages)、将 shared_buffers 设为物理内存的 25%-30%、启用 huge_pages = on、利用多核优势调大并行查询参数。建议用 pmap -x 验证大页是否生效,用 EXPLAIN ANALYZE 多次执行观察耗时波动。
问题描述
将 OLAP 业务数据库从 x86 迁移到鲲鹏 920(64 核 / 256GB 内存 / 1TB NVMe SSD),PostgreSQL 14 大部分查询正常,但某些复杂聚合查询的响应时间波动很大——快的 2 秒完成,慢的要 8 秒以上。用
EXPLAIN ANALYZE检查,执行计划相同,但每次实际耗时差异明显。排查过程
进一步检查 PostgreSQL 是否使用了大页:
效果验证
对波动明显的聚合查询进行多次测试:
-- 测试查询 EXPLAIN ANALYZE SELECT date_trunc('hour', created_at) AS hour, COUNT(*) AS cnt, AVG(amount) AS avg_amount FROM orders WHERE created_at >= '2024-01-01' GROUP BY date_trunc('hour', created_at) ORDER BY hour;小结
鲲鹏上 PostgreSQL 查询性能波动的根因是
shared_buffers默认值太小且未启用大页,内存访问走普通页表导致 TLB miss 不稳定。核心优化点:配置系统大页(nr_hugepages)、将shared_buffers设为物理内存的 25%-30%、启用huge_pages = on、利用多核优势调大并行查询参数。建议用pmap -x验证大页是否生效,用EXPLAIN ANALYZE多次执行观察耗时波动。