32丨当Postgres磁盘读引起I/O高的时候，应该怎么办？

分享下自己学习体会： 为什么缓存可以加速I/O的访问速度？ 老师说的缓存应该有两个：操作系统的缓存和PostgreSQL的缓存。它俩作用都是为了把经常访问的数据（也就是热点数据），提前读入到内存中。这样，下次访问时就可以直接从内存读取数据，而不需要经过硬盘，从而加速I/O 的访问速度。 因为没接触过PostgreSQL,在做思考题时找了些资料，下面是延伸的学习。 PostgreSQL缓存跟操作系统的缓存有啥联系？ 1.在访问数据时，数据会先加载到操作系统缓存，然后再加载到shared_buffers，这个加载过程可能是一些查询，也可以使用pg_prewarm预热缓存。 2.当然也可能同时存在操作系统和shared_buffers两份一样的缓存（双缓存）。 3.查找到的时候会先在shared_buffers查找是否有缓存，如果没有再到操作系统缓存查找，最后再从磁盘获取。 4.操作系统缓存使用简单的LRU（移除最近最久未使用的缓存），而PostgreSQL采用的优化的时钟扫描，即缓存使用频率高的会被保存，低的被移除。 PostgreSQL缓存读顺序share_buffers -> 操作系统缓存 -> 硬盘。那么也可能是操作系统缓存不足，而不定是share_buffers。通过文章中vmstat命令看到cache有260G，free值也很稳定，所以应该检查PostgreSQL的缓存。（老师执行vmstat是不是埋了个伏笔）。 参考资料 https://www.cnblogs.com/zhangfx01/p/postgresql_shared_buffer.html https://blog.csdn.net/kwame211/article/details/78665999

bi 是指每秒读磁盘的块数。所以要先看一下，一块有多大。 [root@7dgroup1 ~]# tune2fs -l /dev/vda1 | grep "Block size" Block size: 4096 [root@7dgroup1 ~]# (300000∗1024)/1024/1024≈293M ===================================================== ===================================================== 上面为原文 这里指的是块。但是老师这样算也错了吧，一块是4096byte,那300000块的大小应该是300000*4096/1024/1024=1172M

bi 是指每秒读磁盘的块数。所以要先看一下，一块有多大。 [root@7dgroup1 ~]# tune2fs -l /dev/vda1 | grep "Block size" Block size: 4096 [root@7dgroup1 ~]# (300000∗1024)/1024/1024≈293M ===================================================== ===================================================== 上面为原文 问题一： 老师，这里是不是有问题？ bi表示从块设备读入数据的总量（即读磁盘）（kb/s），而不是每秒读磁盘的块数 其实，这样算就可以了：300000/1024≈293M 问题二：查询Block size的目的是？我看这个4096和iostat图中r/s列的值差不多， 而r/s表示每秒完成读IO设备的次数

老师假如一条SQL语句执行100毫秒，我们一般觉得需要去优化SQL语句，但是也可能是等到磁盘读取消耗了大部分时间，我们如何区分这种情况？

CPU的处理速度与磁盘的处理速度不同，Buffer能起到协调和缓冲的作用，增加Buffer增加了缓冲的空间，故磁盘I/O的压力就会减少。

原文:这个 bi 挺高，能达到 30 万以上。那这个值说明了什么呢？我们来算一算。 bi 是指每秒读磁盘的块数。 ------------------------------------------- 老师这里，30万是指有30万块数，还是30万kb的数据， 如果是kb那没有必要查一块是多大的呀？

继续打卡

一块是4096个字节，读每秒到了300000次 为啥是： （300000*1024）/1024/1024？ 不应该是： （300000*4096）/1024？

确实没有看明白，怎么等于300M的

老师，看了一下午太困惑了，后面一下子就写到优化的动作，看 shared_buffers 最后一下子是20g, 没看到调优前这些值是多大的？ 难道调优前是特别小吗？