缥帙各舒散,前后互相逾。这篇文章主要讲述PostgreSQL 如何“霸占”系统OS cache 提升查询性能相关的知识,希望能为你提供帮助。
【PostgreSQL 如何“霸占”系统OS cache 提升查询性能】(最近有一个疑问,不知道发生了什么,一周2天 mysql
2天 PG,之前 PG的阅读量基本上只能达到 MYSQL 的一半,而最近的两周,基本上处于 1比1 的状况,整体的阅读量也提升了30%)
上期回答了关于PG数据库缓存和系统的缓存之间的一些关系,其中可能有有一些可以在讨论的问题,既然数据库可以“黏住”常用的数据,那系统的缓存我们还是否可以继续利用,还是仅仅拿他当一个所谓的“二级缓存”(这个词可能不严谨)来使用。
今天我们就来说说一个PG的扩展 pgfincore 让这个扩展来为我们更完善相关的服务和缓存状态的展示,pgfincore是2ndQuadrant 公司,一家专门为的开源插件。
安装的过程就不说了,非常的简单,make&
make install , create extension pgfincore
下面其他的先不讲,先看这个插件能帮助我们做些什么,在讲其他的。
下图很清楚的显示了,一个300万行的表在系统中经历了2次 count的操作大致使用的时间,按照一般的数据库系统来说,我第一次查询和第二次查询如果查询语句是一致的,那第二次的速度应该比第一次快,因为我缓存了查询的语句和结果之间的对应关系(当然这里也有其他的情况,不在展开)。
图中我们使用pgfincore插件中的一个,将表或索引预装入到OS 缓存层面的功能,我们再次查询,发现比第二次的速度还快,仅仅300万的数据使用82毫秒。这说明我们将表或索引提升至OS的缓存中,对查询的加速是有效的吗,即使我们用不上什么索引,或没有所以的情况下。
select * from pgsysconf();
通过pgsyusconf() 可以查看当前系统的OS 控制的页面有多少,剩余多少。在通过这个插件可以很清晰的指导,当然我们缺少不缺少系统OS层面的缓存。(缺不缺 OS 系统缓存的问题我们可以解决了)
当然我们通过
select * from pgfincore(test);
可以看到一个表的DISK 与OS PAGE 之间的对应的关系,
下面做一个实验来证明,加载和不加载OS 内存的情况下,到底有什么区别,下图中包含了15次频繁的对一个表的 select * from 表 limit 10;的操作
总体的数据在0.6986秒
我们在加载了OS 系统缓存后,我们在做15次
显示总体30次的查询事假在0.9625秒,那加载后查询的15次的时间是
0.9625 - 0.6986 = 0.2639 秒 也就是说大致节省了 3分之二2 强的时间。
另外在前几期中讲了pg_rewarm 插件,可以在系统重启之后进行类似MYSQL的 将系统重启动之前的数据灌入到INNODB BUFFER POOL中,但我们忽略了另一个问题,就是MYSQL 以及其他数据库是没有OS 缓存利用这么一说的,所以POSTGRESQL 如果你在重启后还可以考虑对部分数据,怎么快速的缓冲到 OS 的缓冲的事情。实际上在做了几个测试后,让我打消了使用pgfadvise_loader的想法,因为提升到速度只在第一次有效,另外如果是生产机有多少机会会经常重启,如果是测试机,有必要劳心劳力的作这个事情。
当然如果你感兴趣可以看一下官方的文档,关注一下 pgfadvise_loader可以满足你嫉妒优化的想法。
下面整理了一下相关的一些命令
1 select * from pgsysconf_pretty();
得到你系统的OS层面的缓冲信息
2 select * from pgfadvise_willneed(表名);
加载索引或表到OS CACHE 层面
3 select * from pgfadvise_dontneed(p表名);
卸载表的内容从OS CACHE 层面
另外还是,如果有问题的同学可以私信我,我们可以一起研究,共同提高。
推荐阅读
- 如何设计出一个比较合理的数据归档系统
- 看电影也可以学点什么
- gitlab安装与使用
- MYSQL怎么发现处理没有commit 留下的“大”麻烦()
- PostgreSQL 一个可以调整查询代价的数据库
- 可曾听闻大话二字—统计学R语言
- MYSQL performance_schema 监控系统更容易与慢查询DUMP SLOW LOG
- Zookeeper - 数据处理/存储
- SQL SERVER时间换空间,空间换时间 以及什么是好SQL