Postgres 10.3：SELECT 查询挂了几个小时答案

【问题标题】：Postgres 10.3: SELECT queries hang for hoursPostgres 10.3：SELECT 查询挂了几个小时
【发布时间】：2018-12-14 17:37:19
【问题描述】：

我的应用程序使用 Postgres 作为 DBMS，我使用的 Postgres 版本是 10.3，安装了扩展 Postgis。

我偶尔注意到，在随机的时间间隔内，dbms 变慢并卡在几个 SELECT 查询上。

从pg_stat_activity我注意到这些查询的wait_event_type和wait_event如下：

 select wait_event_type, wait_event from pg_stat_activity where state='active'; 
 wait_event_type |  wait_event  
-----------------+--------------
 IO              | DataFileRead
 IO              | DataFileRead
 IO              | DataFileRead
 IO              | DataFileRead
 LWLock          | buffer_io
 LWLock          | buffer_io
 IO              | DataFileRead
 LWLock          | buffer_io
 LWLock          | buffer_io
 IO              | DataFileRead
 IO              | DataFileRead
 LWLock          | buffer_io
 LWLock          | buffer_io
 IO              | DataFileRead
 LWLock          | buffer_io
 IO              | DataFileRead
 LWLock          | buffer_io
 LWLock          | buffer_io
 LWLock          | buffer_io
 LWLock          | buffer_io
 LWLock          | buffer_io
 LWLock          | buffer_io
 LWLock          | buffer_io
 LWLock          | buffer_io
 LWLock          | buffer_io
 LWLock          | buffer_io
 LWLock          | buffer_io
 IO              | DataFileRead
 IO              | DataFileRead
                 | 
 IO              | DataFileRead
 LWLock          | buffer_io
 LWLock          | buffer_io
(33 rows)

在检查docs 之后，我的假设是下面的硬件存在一些问题，然后我面临的问题与应用程序或查询类型无关，而是与硬件本身有关。

有人遇到过这种问题吗？

【问题讨论】：

我同意。您使用的是什么文件系统？
dbms 安装在 Kubernetes pod 上，卷安装在网络存储上。 .
在这种情况下很可能是网络问题。
这仍然可能是应用程序/查询的问题。您提到要使用 PostGIS，例如，您是否正确索引列以防止顺序读取？当长时间观察那些等待事件 DataFileRead 时，可能意味着情况就是这样。我的建议是捕获其中一个长时间运行的查询并运行“EXPLAIN (ANALYZE,BUFFERS,TIMING) query”。参数 log_min_duration_statement 和扩展名 auto_explain 是你的朋友。
观察到的间歇性可能与以下事实有关：有时您使用的谓词/过滤器需要比其他时间段通常处理的行多得多。当然，这仍然可能是资源限制问题，例如网络或存储、内存甚至 CPU。

标签： postgresql postgresql-10

【解决方案1】：

一般故障排除建议：

开始收集服务器的运行时统计信息 - 有多种工具可供选择 - https://munin-monitoring.org/、https://grafana.com/ + influx db + telegraf 等等。无论采用何种解决方案，您都应保留以下历史统计数据：
- 每秒完成的磁盘操作量
- 磁盘存储的延迟 [无论是旋转 rust、ssd、nvme 还是网络连接]
- 服务器 CPU 使用率、负载、内存使用率
获取有关 postgresql 的统计信息 - https://www.percona.com/downloads/pmm2 在这里可能会有所帮助

根据这些统计数据 - 在有问题的查询发生之前查看是否有任何堆积。

偶尔减速可能是由以下原因引起的：

存储子系统性能不均匀 [ssd 寿命结束，RAID 阵列上的巡读，由于坏扇区导致硬盘重新分配数据]
不正确的索引统计导致查询计划不理想
传入查询导致系统过载
运行在同一硬件上的其他工作负载导致系统过载，如果您在虚拟化环境中运行，邻居会产生噪音

【讨论】：