mysql预加载数据_PostgreSQL: 使用 Pgfincore 预加载数据优化一列

最近有个新项目业务上升较快,数据库的压力也是直线上升,日最高负载上升到 100 左右,日平均负载上升到 25 左右,这个负载已经相当的高了,出现这种情况通常是由于少数 SQL 语句性能较差,需要从 SQL 调优着手,目前这个应用需要优化的地方很多,比如有些走索引的 count 语句并没有做到前台应用缓存,以及部分 SQL 需要从业务角度进行逻辑优化,但下一个应用版本业务方没有这么快能够上线,所以针对这种情况,只能从数据库端进行优化,寻找解决问题的方法。

前面已经说过这个业务近期数据量增长比较快,数据库内存已经不够缓存业务数据了,数据库内存 24 GB,核心业心业务表数据( 24 GB) 左右,核心数据索引 30 GB 左右,数据库内存已经没有能力完全缓存这部分数据和索引,但是目压力最大的一个 SQL 为新注册用户发起,新用户注册上线即会触发这个 SQL,而新用户查找的数据从前台缓存( memcache ) 无法命中,所以这部分查询落到数据库中实时查询,故数据库压力会很大,频繁出现数据库负载的超过 100 的尴尬局面。

经过分析,根据 iostat 命令输出,发现其中一块盘,读非常频繁,远远大于写,而数据库的数据大部分落在这个盘,此时也说明内存已经不够了,这时应该给数据库内存扩容了。

最后,给数据库内存扩容到 64 GB,之后并且用 pgfincore 缓存技术将核心业务表和常用索引预先加载到数据库缓存,这样可以大大提高新用户注册后查询数据库时 cache 的命中率(由于新用户注册时发出的 SQL ,并不能命中 memcache 前台缓存),关于 pgfincore 的使用可以参考之前的 blog :

https://postgres.fun/20100805161611.html , 数据库内存扩容后,日最高负载大辐下降,日平均负载大大下降,如下图:

扩容前后日最高负载图

530b4fccc44d9cad114b9a4680fc6c4c.png

备注:扩容日期 7-19,数据库扩容后,日最高负载由 100 降到 20 左右。

扩容前后日平均负载图

9805caa15e9f87d9bac2ba65d80e714d.png

备注:扩容日期 7-19, 数据库扩容后,日平均负载由 25 降到 2 左右。

扩容前的数据库负载

8c5b1a7d9f836381f55d4cfad5f4a5aa.png

备注:扩容前07-16 数据库的负载,上图的负载够猛的!

扩容后的数据库负载

4951371e4fbed975183b0ba605654ff6.png

备注:上图为扩容后 7-20 号的数据库负载。

后续优化工作

通过增加内存增加数据库性带来的效果确实不错,但这并不是解决问题的最优方法,目前这个项目需要优化的地方还很多,例如走索引的 count 语句做到前台memcache 中,以及应用逻辑的优化等,但通过增加内存并且利用 pgfincore 技术将业务数据提前缓存到 OS cache 中的做法确实能对特定场合产生极大的效应,例如当数据库的压力大部分由应用系统新用户注册发起时。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值