爱站程序员基地阿里云SLB健康检测后端服务器组产生百万级别的php的0k大小session文件
今天早上在登录公司一台阿里云的服务器上vim修改配置文件以及touch文件时报错：no space left on device
df -h 查看了磁盘空间，发现磁盘空间还很充足
df -i 发现indoes已经爆满了，当时忘记了截图，解决问题后的截图，当时IUse%已经到了100%
这台实例是属于应用服务器组，由阿里云的SLB均衡负载到后端应用服务器组，这时候还没上线只是部署测试阶段，那么INodes怎么会爆呢。网上查阅了资料，说这是因为路径下有太多的小文件导致indoes用光导致爆粗，究竟是哪里产生了这么多小文件。
于是我find /目录 | wc -l 统计了一下根下各个目录下的文件个数，发现/home的文件个数达到了300多万个，这个正是我们部署应用的目录，于是
find /home -xdev -printf ‘%h\\n’ | sort | uniq -c | sort -k 1 -n
这个目录文件数量排第一，正是存放php的session的路径，一统计这个session目录，好家伙300w个文件，占满INodes的罪魁祸首就是他。但是为什么会产生这么多session，这套环境还没上线测试的也还不多哪来那么多session。仔细想了想，现在直接连接这实例的只有阿里云的SLB，问题会不会出现在SLB上？
我查看了一下这些session，发现几乎都是0K的session，也就是无用session，于是
find php-session/ -type f -size 0 | wc -l
统计结果300多万的文件就是这些0k大小的session，为了验证是不是SLB的问题我需要把SLB的后端服务器权重关了
find php-session/ -type f -size 0 -exec rm {} ; #删除0k的session
当删除成功后df -i的结果如第一张图所示，vim编辑文件或touch文件也成功了
find php-session/ -type f -size 0 | wc -l
这时候的session统计还是在一个不停增长的趋势，于是我到阿里云的slb控制台强权重改为0
再到服务器上find统计，此时session不再增加了，那么可以确定SLB健康检测后端服务器不停的触发产生空的session。至于为什么会产生空session，这是代码那么的老坑了，之前有发现这个bug后面做了修改但是不能根本解决，下面是产生session的代码
因为session牵扯到后面的太多文件，代码那边是没有办法改动了，跟php同事协调了下想抓一下php的log，但是并没有抓到。于是我把nginx的access.log开启，看到了解决问题的眉目，以下是抓到SLB监控检查的logs
同时发现nginx也有报错
可以看到SLB的URL请求都是HEAD的，而且返回值为200SLB就会认为后端服务器还活着。那么我们只要将带有HEAD的请求匹配掐断，返回200给SLB，就不会再有访问不停的触发生成session，于是修改nginx配置文件
重启nginx，将SLB的权重打开
问题解决
