redis节点CPU内存故障

---

一、Redis异常记录

如果无法继续返回、无法获取连接重置、读取次数、内存无法分配等情况，可以按照以下一些提示进行排查；键数过多或长度不足。按理说，触发运行缓慢、内存不足等的指令较多。

无法分配内存

从池中获取资源

JedisConnectionException:TimeoutException:ReadTimeout

Readingfromclient:Connectionresetbypeer
Errorwritingtoclient:Connectionresetbypeer

参考
几个字段值的含义及关系Redisinfocpu
官方INFO介绍
美团追踪Redis经历过的坑内存使用飞快
详细解释clientlist

Redis性能问题排查及手动解决

使用Redis的slowlogget[n]慢查询日志，彻底解决生产问题！

---

二、redis查询和mysql查询那个占用cup高Redis通常只是存储在内存中的缓存。
MySQL大部分时间都花在磁盘IO上；这意味着大部分性能瓶颈都在磁盘上。因为mysql中的写操作一般是在这意味着CPU会一直等待mysql的写操作。在那之后，内存读取速度基本上是几百甚至几万倍。。
另一方面，redis有比较简单、清晰的数据结构；mysql作为一个关系型数据库，可以包含事务、锁等复杂的数据结构，这些数据结构会消耗大量的CPU。表现。
所以肯定是因为mysql比redis占用更多的CPU和时间。这是基于读取和写入量相同的条件。如果主要使用redis读取数据而mysql只是一个备份。mysql对性能的要求并不高。

---

三、Redis可能会阻塞的情况如果一个值的大小非常大，那么发送时写入和复制数据时分配内存的开销就会非常大。
从业务角度来看，建议拆分较大的密钥。
对于某些数据结构操作，时间复杂度为O(N)，如果不加以控制，可能会导致瓶颈。
比如key命令，因为没有range参数，会扫描整个表，非常耗时。您可以考虑使用扫描代替。
虽然采用了IO复用技术，但是读写副本以及UserMode和KernelMode之间的切换都会比较耗时。
虽然RDB在fork之后是在一个独立的进程中完成的，但是fork系统调用大约需要700ms。
建议避免在高峰时段执行SAVE或BGASAVE命令。
由于AOF需要修改磁盘上的日志文件，修改文件及其iNode需要两次随机读写IO，大约需要20ms，这就是always-on模式在业务中很少启用的原因。
常用的是每隔一秒模式。
因为Redis的过期键删除策略之一是主动删除：会随机选择100个过期键，如果发现超过25个过期键，则删除过期键，那么这个过程就会发生。被重复。因此，如果大量key同时过期，触发主动删除时，会断地检索和删除key，造成拥塞。
建议在设置过期时间时使用expire而不是expire或者在使用expire时输入一个随机的金额，使过期时间不同。
当Redis可用的内存空间不足时，会执行内存释放操作。尽管可以配置策略，但CPU将在移除时挂起。
建议监控内存使用情况，及时扩容，或者进行其他手动干预操作。