服务器的一次故障解决

　　今早还在路上，接到值班电话，说一台服务器报警，报警信息为根分区磁盘空间满了，我直觉就是nginx的日志占用了空间，让其上服务器确认，好容易等他登陆到服务器上，查看，结果正常了。然后看到领导在微信群里说他清理了磁盘空间。

　　到了公司以后，登陆上该服务器发现空间释放了，但还是占用了80%，还是不正常，先用df命令查看磁盘情况，占用80%，后面用du去核对实际大小，发现跟df的结果对不上，差很多，然后用lsof |grep deleted发现很多nginx的进程还在调用已经删除的文件，看来领导只删了文件，但nginx的引用并未启用新的，还在用老的文件描述符，导致系统并未真正释放空间。然后为了不中断服务使用命令lsof | grep deleted|awk '{print $2}'|xargs kill杀掉了那些子进程，不过过一会儿还是有新的生成，空间还是释放不彻底。

　　同时经过追踪发现，nginx的error log在疯狂的增长，进去一看，有很多的too many open files的错误，这是文件句柄用光了的意思啊，ulimit -a，open files是65535，不小了，查看了同时链接，1w+，看来这个数字已经不能满足nginx需要了，cat /proc/sys/fs/file-max,系统最大300多w，于是再次调高了/etc/security/limit.conf里面的限制，重启了nginx以后，一切恢复正常(包括文件描述符占用，不知道nginx的reload能不能释放，回头做个试验吧)，error log已经没有了，其他地方的访问也已经正常，目前服务器同时连接数保持在1w零几百左右。见图：

ps：刚去试验了一下，删除nginx的日志文件以后，使用reload命令能够释放并重新生成日志文件.

2015年2月12日再次ps:

经过这几天回想发现，上面提到的空间不释放，不是领导删的问题，我跟他确认过，他只删除了以前压缩的gz日志文件，经过分析发现，我们的分发程序都是长连接，那么当每天凌晨lograted进程进行日志分割的时候，虽然向nginx发送了信号，nginx也重新reload了，但因为没有断开连接，所以日志文件的句柄并没有释放，而导致nginx继续向昨天的日志文件中写入，而那些因为异常退出的长连接，重新连接后则向新日志文件中写入，就出现了上面的现象。

转载于:https://www.cnblogs.com/skynass/p/4285485.html