记一次redis导致core文件剧增，服务器磁盘爆表

   工作的某一天，由于项目时间久远，代码量急剧增加，在进行make的时候总是在ld进行连接过程中被系统 signal 9 杀死了当前进程，众所周知ld 进行连接时候最消耗系统的cpu和内存的，于是在多次ld 不成功之后，我们意识到，应该是内网服务器的内存出了问题。

下面是服务器的相关信息：

[root@localhost /]# lsb_release -a

No LSB modules are available.

Distributor ID:    Debian

Description:    Debian GNU/Linux 5.0.1

Release:    5.0.1

[root@localhost /]# uname -a

Linux debian 3.5.7 #2 SMP Tue Jan 29 17:30:27 CST 2013 x86_64 GNU/Linux

[root@localhost /]# cat /proc/cpuinfo

processor    : 3

vendor_id    : GenuineIntel

cpu family    : 6

model        : 2

model name    : Intel Core 2 Duo P9xxx (Penryn Class Core 2)

stepping    : 3

microcode    : 0x1

cpu MHz        : 1995.020

       于是在查看 free -m 时候发现swap 可以使用的空间是0，于是分析得出：在Linux系统下，我们一般不需要去释放内存，因为系统已经将内存管理的很好。但是凡事也有例外，有的时候内存会被缓存占用掉，导致系统使用SWAP空间影响性能，此时就需要执行释放内存（清理缓存）的操作了。Linux系统的缓存机制是相当先进的，他会针对dentry（用于VFS，加速文件路径名到inode的转换）、Buffer Cache（针对磁盘块的读写）和Page Cache（针对文件inode的读写）进行缓存操作。但是在进行了大量文件操作之后，缓存会把内存资源基本用光。但实际上我们文件操作已经完成，这部分缓存已经用不到了。

     由于项目中有很多操作是读取文件到内存中，所以会导致linux进行缓存，从而使用到swap机制，具体swap机制，读者可以自行查阅。因此我们想到了两个方案：

     1.扩展swap分区      2.直接重启服务器

     因为是内网服务器，对业务没有很大的影响，于是就采取了简单粗暴的重启服务器。重启之后，swap分区可以使用了。编译完毕。

     然而，在过去一周后，在某一天，突然出现，在拉取svn代码到本地时候，报磁盘不够的错误，起初，我们以为是内网log过多，所以删除了很多不用的log。很显然，清理出来了10G内存，解决了问题，由于赶业务进度，我也就没有再细看，只是感觉磁盘使用率稍微有些高而已 80%。

  然而过了几天后，再次出现磁盘已满的错误，此时，我们意识到了，出了问题。

  于是，开始检查各个服务器的代码，终于在一个使用redis 的排名服务器中发现了很多的core文件，因为后台5个人，同用一个开发机，所以每个人的排名服务器中都有一大堆core文件。再加上，我们再ulimit -c 中设置的值比较大，所以导致磁盘迅速被占领爆满。

  遇到了core文件，作为程序员，肯定要看一看到底错到了哪里。于是gdb查看core文件。

于是我们发现原来是redis不能写入了，于是去redis命令行下试了一下

真的是报错 再次查看了redis:> info

奥，原来问题出在了这里：

这个错误的意思是：Redis被配置为保存数据库快照，但它目前不能持久化到硬盘。用来修改集合数据的命令不能用。请查看Redis日志的详细错误信息。
原因：强制关闭Redis快照导致不能持久化。

解决方案：在redis客户端中运行config set stop-writes-on-bgsave-error no　命令后，关闭配置项stop-writes-on-bgsave-error解决该问题。或者在redis.conf 中修改重启redis就可以了。

根本原因在于：redis的设计者，默认情况下，如果 redis 最后一次的后台保存失败，redis 将停止接受写操作，
这样以一种强硬的方式让用户知道数据不能正确的持久化到磁盘， 否则就会没人注意到灾难的发生。 如果后台保存进程重新启动工作了，redis 也将自动的允许写操作。 然而你要是安装了靠谱的监控，你可能不希望 redis 这样做，那你就改成 no 好了。stop-writes-on-bgsave-error yes 是默认的。

所以就是我们再关机的时候，没有关闭redis，导致无法写入的错误。 至此，又是一个教训。