postgresql 日志出现: “using stale statistics instead of current ones b ecause stats collector is not responding”

1 postgresql 日志出现: “using stale statistics instead of current ones b ecause stats collector is not responding” postgresql 检查日志发现如下信息，基本都出现在凌晨 3 点到 5 点： 2016-01-07 04:45:10 CST LOG: using stale statistics instead of current ones because stats collector is not responding 数据库版本 VERSION = EnterpriseDB 9.4.1.3 不清楚什么原因引起？是否与 进程 stats collector process 有关？ 这是否会导致查询结果出错？ 关系型数据库 数据库 PostgreSQL • 可能是 checkpointer 调用 fsync, 阻塞的其他进程的 IO 操作造成的(包括 stat collector process 的 write 操作). 建议尝试调整系统的 dirty_expire_centisecs, 缺省为 30 秒, 可以调整为 15 秒看看. 另外, 尝试调整 checkpoint 的间隔, 不用太频繁. 如果是 ext4 的文件系统, 查看 mount 的选项. 如果使用了缺省的 mount 选项或指定了 ordered 模式, 则可以考虑改为 writeback 模式 (只在存储有电池保护并开启 fullpagewrite 的时候考虑) 还有可能是, 确实存储的带宽不够用, 建议升级存储带宽(容量) pg9.6 单纯写性能探索 nmon 资源情况如下： 2 disk 使用情况： 分析测试结果，发现测试过程中，CPU 利用率最高才 20%，性能瓶颈还是在磁盘 IO 能力。 并发在 128 达到峰值，随着并发提高总体写的 TPS 开始降低。 用 fio 工具跑了下本台 x86 的随机写 iops：1207 fio-2.1.10 Starting 10 threads LOG: using stale statistics instead of current ones because stats collector is not responding Jobs: 10 (f=10): [wwwwwwwwww] [100.0% done] [0KB/21568KB/0KB /s] [0/1348/0 iops] [eta 00m:00s] mytest: (groupid=0, jobs=10): err= 0: pid=5470: Fri Jun 8 17:26:48 2018 write: io=1136.6MB, bw=19323KB/s, iops=1207, runt= 60228msec 3 再看看别人家的测试环境,果然硬件是硬伤。 fio-2.2.5 Starting 10 threads Jobs: 10 (f=10): [w(10)] [100.0% done] [0KB/331.6MB/0KB /s] [0/42.5K/0 iops] [eta 00m:00s] mytest: (groupid=0, jobs=10): err= 0: pid=148520: Fri Jun 8 17:33:29 2018 write: io=10240MB, bw=333464KB/s, iops=41682, runt= 31445msec