|
上一篇讲述了由于redis服务器cpu100%导致网站502的问题，今天延续上一篇的内容，说明一下原因和分析过程。 首先引起cpu100%可能的几大原因： 1.redis连接数过高 2.数据持久化导致的阻塞 3.主从存在频繁全量同步 4.value值过大 5.redis慢查询 为了模拟redis服务器cpu100%，临时买了一台阿里云ecs，并把那天清空前的redis备份还原到服务器上。下面我们按照顺序逐个排查， redis连接数过高?redis的默认链接数是10000，我们并没有更改这个值，前面提到了web的承载量是1600左右，所有可以排除 数据持久化导致的阻塞？大家知道redis是可以持久化的，而redis持久化会采取LZF算法进行压缩，这种方式会减少磁盘的存储大小，而通过这种方式是需要消耗cpu的，我们看下redis的配置 rdbcompression yes 表示压缩算法是打开的 还有3个关键的参数，这里解释一下： save 900 1 //表示每15分钟且至少有1个key改变，就触发一次持久化 save 300 10 //表示每5分钟且至少有10个key改变，就触发一次持久化 save 60 10000 //表示每60秒至少有10000个key改变，就触发一次持久化 因为redis持久化的动作会记录日志，我们首先找出出问题的时间段里的持久化内容大小 也才75M，看起来不会是它了，为了确保，我批量的高频次写入redis进行验证(这里代码就不贴了)，直接看实验结果，数据量大概是上面的4倍 写入的过程我实时的观察cpu运作情况(实验的服务器是单核的，所有直接看阿里云的监控页)： 得出结论：毫无压力，所有这项也排除 主从存在频繁全量同步因为我们是单服务器，没有做主从所以直接排除 value值过大先看一下当时cpu时redis的key和存储量情况 462万多的key才使用900MB左右的内容，平均一个key才0.2kb左右，基本不可能，但是抱着严谨的态度还是决定模拟写入大的value值，测试之前现进行清空，然后写了一个数据读写脚本(这里就不展示代码了)： 使单个key平均300KB左右提升了100多倍，cpu毫无压力，所有这个问题也可以排除。 redis慢查询相信大家看到这里已经知道结论了，就是慢查询的问题。
一个高频访问的网页程序请求redis使用keys命令，导致每次访问接近2秒，当2秒内访问超过服务器的最高承载量时,后面请求全部需要排队，导致大量的超时(504)... 看了一下官方对keys命令的说明，已经进行警告生产环境要慎用，会产生性能问题： |
|
|
来自： liang1234_ > 《redis》
