系统缓存带来的性能问题

昨天一直有用户反馈系统里产品的价格查询有问题,很多时候根本没法刷出产品列表,就算刷出来也是很慢。

自己试了几下,都能刷出来,但是确实很慢。


回想了下这两天的更新,最大的可能就是和同事做的对接第三方接口的更新有关了。

因为周四和周五时有看过服务器的资源使用情况,API 的应用程序池的资源使用率明显增多。

CPU 占用率暴涨,占据了大部分的使用时间,内存的使用也比之前明显高很多。


昨晚检查服务器,同样是 API 对系统资源的使用比例奇高。

把前两天的更新回滚,问题依然存在。

看来问题还是在代码里。


检查了相关的代码,发现这块的数据全部是使用系统缓存来进行处理,联想到这两天系统更新后调用第三方接口导入的数据比以前多了还很多,所以服务器的 API 内存使用比例增高很多就不是什么奇怪的事了。


既然有了可能的原因,就立马着手调试。

把代码的逻辑进行整理,确认了几处关键的数据查询点,把这几个地方由读取缓存改为读取数据库。

测试后发布更新,系统的资源使用率暴降,之前用户反馈的模块查询问题也顺利解决。


在问题反馈的时候,数据查询用时在 50s 左右,问题解决后用时大概在 450ms

吐血了~~~


这块的逻辑代码是比较早的时候写的,由于系统当时刚引入缓存,所以基本上每张表的数据都做了缓存。

当系统运行或重启后,系统 API 会先把整个数据库的数据缓存到内存,然后再由后续操作决定如何对缓存数据进行增/删/改/查,这样做的后果就是每次系统 API 更新/重启后的第一次运行速度极其慢。

后续进行了一次调整,把数据表的第一次缓存放到第一次操作时进行这样也只是分散了 API 的第一次集中缓存速度,当数据最终全部缓存完后,其后果是完全一样的。


这样子的缓存使用,问题就是随着数据的不断增多,API 所消耗的系统内存就越多。

当一些批量处理操作需要频繁读取、比较和写入数据时,内存也会被频繁操作,于是服务器也会很卡。

本来是想通过缓存得到较好的查询效率,在这种情况下随着数据的不断增多反而变成了性能问题。


出现这种情况的原因,其实还是因为对缓存的了解不够从而造成使用不当引起的。


接下来需要对业务代码进行全面的优化,尝试只缓存诸如配置表之类的不变动或少变动的基础表数据,频繁读写的业务表通过数据优化来解决,看效果是否会好一些。


惨痛~~~