情况是这样的,因为数据库和服务都在同一个服务器(这样不好),服务有个自动更新切片,从数据库中拉取数据,服务同时支持瓦片的访问,但是在进行瓦片更新的时候服务器磁盘IO扛不住,这时访问瓦片就会大量PENDING。为了解决此问题(在不加硬件资源的情况下),有了如下文章
postgresql查看配置文件位置(因为不是本人装的,所以需要先查看相关的配置)
postgres=# selectname,setting from pg_settings where category='File Locations';
name | setting
-------------------+-----------------------------------------
config_file |/var/lib/pgsql/9.6/data/postgresql.conf
data_directory | /var/lib/pgsql/9.6/data
external_pid_file |
hba_file | /var/lib/pgsql/9.6/data/pg_hba.conf
ident_file | /var/lib/pgsql/9.6/data/pg_ident.conf
由于本人更喜欢使用navicat操作数据库,所以在navicat中查看现有配置,所以看到配置文件位置有毛用(不要慌,毛真的有用)。
可以大致看到现有的配置,那么本人又不是专业DBA,这么多参数眼都花了,没有办法,老板说你可以的。这里参考德哥的文章,收获很多,这里我们目标是磁盘,德哥的文章不是针对磁盘,再参考另外一篇文章
由于数据不需要非常高的实时性,所以可以调整一些参数,增加shared_buffers,max_wal_size,把fsync改为off等,这里注意有些参数可以在不重启数据库服务的情况下更改,比如这个fsync,但是前面的两个都是要重启服务器才能生效的,我没有直接操作配置文件,而是在navicat中更改的,语句如下
ALTER SYSTEM SET max_wal_size = 4096;
注意单位,可以通过
TABLE pg_settings ;
查看数值单位
我这里单位是8kb,所以我要改成2GB的话,就是2×1024×1024/8=262144。改完之后重启数据库就可以测试效果了,我这里还有点小插曲,因为数据库在docker容器中,所以之前看到的配置文件位置并不对,这里我用了全局搜索才看到在docker中。
我们是怎么发现磁盘IO问题的,这里交代一下,其实就是两个工具,iotop查看io高的进程,iostat查看io整体情况,具体可以参考监视I/O子系统,还有这篇博文centos 7 查看磁盘io ,找出占用io读写很高的进程,关于修改postgresql参数,可以参考官方文档