Redis后端连接丢失及磁盘空间不足问题排查与解决指南

网页出现welostredis!!是怎么会事

好吧，我们进入主题吧。
情况是这样的：我负责在后端写Redis，然后其他人负责获取，然后突然获取不到。
这是怎么回事？我立即检查日志：[ERROR][2016-04-2313:16:37]cn.com.ctsi.auth.redis.SharedJedisSentinelPool[387]-LostconnectiontoSentinel10.128.12.15:26379.Sleeping5000msandretrying发生错误。
这不会影响Redis的读写。
然后我检查了所有程序日志，没有发现错误信息。
我立即认为这是一个磁盘问题，直到我看到以下内容：错误：MICONFErrorswritingtotheAOFfile：Nospaceleftondevice。
因为之前的日志文件每秒都在不停地写日志，这引起了我的注意，但我并没有太当回事，但我的直觉告诉我，会出问题。
于是我直接找到了输出日志文件，放心地删除了该文件，然后重新开始思考就可以解决了。
但是，redis-cli无法工作（错误）MISCONFERdisisconfiguredtosaveRDBsnapshots,butiscurrentlynotabletoppersistondisk.Commandsthatmaymodifythedatasetaredisabled.PleasecheckRedislogsforddetailsabouttheerror，问题是什么？按照网上说的，修改了一些内核，还是不行。
然后我到应用程序目录下发现了nohup.out，我果断删除了，然后重新启动应用程序，将日志放入黑洞nohupJava-jar0.0.1-SNAPSHOT.jar>/dev/null2>&1&然后测试了一下，还好，然后我好奇硬盘大小，于是一看，发现应用程序所在的目录只有2g的磁盘空间。

redisserverwentaway，上传显示这个怎么回事

1.redisserverwentaway表示服务器出现错误或者没有启动。
2.原因应该是运营商进行系统升级或维护。
3.您可以查看相关广告。
了解具体的冷却时间。

解决Redis保存后无法写入问题

今天开发人员突然告诉我redis不可写。
进入redis后发现确实是这样，命令集无法执行。
错误报告如下：172.31.18.90:6379gt;set?testtest1(error)MISCONFIRMATIONDisconfiguredtosaveRDBsnapshots,but当前不可用于磁盘。
请在重新详细说明之前重新检查Dislogsforetails。
不是权限问题引起的，也不是内存耗尽引起的通过查看日志，发现报错信息fork:CannotallocateMemoryPerformsaforkonaprocesswithsmallmemory并不需要太多的资源，但是当内存空间不足时这个过程的长度是用G来衡量的，Forking就变成了一个非常可怕的操作。
更何况，在16G内存的主机上砍掉一个14G内存的进程怎么样？肯定会报内存无法分配。
更烦人的是，主机更换的次数越多，fork的次数就越多，fork本身的运行成本可能并不比假死更好。
找到原因后，直接修改内核参数vm.overcommit_memory=1和sysctl-p，使内核参数生效：Linux内核会根据vm.overcommit_memory参数的设置来决定是否释放。
如果vm.overcommit_memory=1，则直接释放vm.overcommit_memory=0：然后将本次请求分配的虚拟内存大小与系统当前空闲物理内存加上swap进行比较，决定是否释放。
vm.overcommit_memory=2：为该进程分配的所有虚拟内存以及本次请求分配的虚拟内存，在系统加swap时都会与空闲物理内存进行比较，以决定是否释放。
这里我重新贴一下redis的写回机制Redis的数据写回机制分为两种：同步和异步写回就是SAVE命令，主要过程是将数据直接写回磁盘。
在数据量较大的情况下，会导致系统长时间卡顿，所以通常不建议这样做。
异步写回就是BGSAVE命令，主进程fork后，复制自身，通过这个新进程写回磁盘，写回完成后，新进程自行关闭。
由于这不需要主进程阻塞，因此系统不会冻结，通常默认使用这种方法。
这里注意：在redis中运行configsetstop-writes-on-bgsave-errorno命令只能暂时修复问题。
如果发生错误，仍应检查默认日志配置stop-writes-on-bgsave-erroryes当发生bgsave错误时，无法修改数据。