最近有个新项目业务上升较快，数据库的压力也是直线上升，日最高负载上升到 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 ， 数据库内存扩容后，日最高负载大辐下降，日平均负载大大下降，如下图：

扩容前后日最高负载图

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

扩容前后日平均负载图

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

扩容前的数据库负载

备注：扩容前07-16 数据库的负载，上图的负载够猛的！

扩容后的数据库负载

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

后续优化工作

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