今天上班遇到一个非常奇怪的事情,公司监控服务器之前都是在正常运行,使用nginx+php-fpm,并且监控服务器上部署这其他部门在使用的几个站点,从早上上班开始发现监控显示页面打不开,各种查找原因,最后发现只有在重启php-fpm后,监控页面才能正常访问,访问正常后,由于最近事情比较多,所以没太多关注。下午的时候我又打开看了下,发现又和上午一样,浏览器报504错误,并且重启php-fpm之后又能正常访问了;发现这个问题有点过分了,我想肯定起来不久又会重新报504错误的;过了两分钟,果然,继续访问不了,504错误。这次重新登上服务器,查看了下php-fpm的error日志:
按照它给的建议,找php-fpm配置文件。修改了
pm.max_children = 50
pm.start_servers = 15
pm.min_spare_servers = 10
pm.max_spare_servers = 30
的值,这个值是修改之前的,修改之后分别为:
pm.max_children = 100
pm.start_servers = 60
pm.min_spare_servers = 50
pm.max_spare_servers = 75
这个值的跨度还是比较大的,这是在我几次尝试之后不报错的情况下修改的;但是修改完之后,监控页面时可以访问了,出现的问题却让我们很郁闷,数据库的所有监控全部报警,后来赶紧查看了下访问日志,发现来自全国各地的公网IP在不停的访问,这个问题让我第一印象就是被攻击了,立马查看了下系统的访问日志,发现的确有很多的访问进来,但是作为一台独立的线上服务器,即使有不断的访问进来也不至于导致所有的数据库连接报警的,尝试着减少访问,看看能不能消除数据库报警,但是加了各种措施之后,数据库报警依然存在,我又将php-fpm的配置参数还原,尝试着重启登入数据库,但是发现登入数据库时提示缺少sock文件,登不进去;找到配置文件,按照配置文件中的sock路径看了下,是没有这个sock文件;到网上搜了许多,并没有好的解决方法,便向MySQL的相关QQ群里面询问,后来,有人说重启之后会自动生成sock文件,我便试着重启了下,结果又发现了问题:
这个问题我就郁闷了,根本停不掉啊;最后各种方法之后,决定kill掉。但是,问题又来了,kill关闭之后,呵呵。。。起不来,报
最后的原因我想大家谁也想不到,群里的人告诉我Errcode 28一般都是磁盘空间不够导致,我赶紧看了下,使用率百分之百,顿时,心中。。。。。清理完备份文件,过几分钟,数据库可以正常启用,监控也正常了。
这个问题真的不算是什么问题,可是正因为运维人员的疏忽,导致这种事情发生,还好服务器暂时没有接入用户,要不然问题可就大了,做了定期备份,竟然没做定期清理,这种错误真的不应该犯,当然,我也进行检讨,查了所有的问题,就是没有查看磁盘空间,导致走了那么大的弯路,希望各位运维人员也能以此为戒!!