早上刚到办公室，客户电话就进来了。做婚纱摄影的，网站主要是展示客片和接受预约，地点在浙江杭州市西湖区。
客户说昨天还能正常上传照片，今天一上传就报错，前台看不出问题，后台提示”无法写入文件，请检查目录权限”。第一反应是权限被改了，但登录服务器一查，权限没问题。
用df -h看了下磁盘，/dev/vda1可用空间是0，100%占满。怪不得传不了东西，磁盘都没空间了，别说图片，日志都写不进去了。
哪些东西占满了磁盘
先找到根目录下最大的文件夹：
du -sh /* | sort -rh | head -10
发现/www/wwwlogs这个目录占了将近40G，里面全是nginx和php-fpm的访问日志和错误日志。有些日志文件单个就2个多G，而且最早的日志能追溯到半年前。这么长时间从来没清理过，日志一直往里面写，再大的磁盘也扛不住。
打开其中一个nginx访问日志看了下，里面大部分是正常的GET请求，也有少量404错误。还有几个IP段在扫某个后台路径，目测是有人尝试渗透，频率不高，但每天都有。这些记录按理说保留一两个月就够了，没必要攒半年。
临时清理
先把日志目录里一个月以前的文件移走：
cd /www/wwwlogs find . -name "*.log" -mtime +30 -delete
清理完释放了大概20G空间，上传功能恢复正常。
但这只是治标不治本，再过几个月日志又会把磁盘填满。真正需要的是配置日志轮转，让系统自动管理日志文件的大小和保留周期。
配置日志轮转
宝塔面板自带的计划任务里有一个”日志切割”功能，设置成每周执行一次，自动把当前日志文件归档压缩，只保留最近四周的日志。操作很简单，在宝塔面板里点几下就行了。
除了宝塔自带的功能，也可以用Linux系统自带的logrotate来处理。在/etc/logrotate.d/nginx里配置一下，可以更精细地控制：
/var/log/nginx/*.log {
daily
rotate 30
compress
delaycompress
notifempty
create 644 nginx nginx
postrotate
/etc/init.d/nginx reload
endscript
}
这段配置的意思是每天轮转一次，保留最近30天的日志，超过30天的自动删除，旧日志自动压缩节省空间。
检查一下还有什么占空间
清理完日志之后，顺便检查了其他目录。发现网站根目录下有个/cache文件夹，里面存了不少临时文件。这是之前客户测试一个缓存插件时留下的，后来插件关了，但这些缓存文件还留着没删。看了一下大概有3G左右，直接清掉了。
数据库目录也看了下，mysql的binlog日志攒了一堆，开启了binlog但没开自动清理，最早的binlog文件已经有几个月了。在mysql配置里加了expire_logs_days = 7，设置只保留最近7天的binlog，多余的会在重启或者刷新时自动删除。
客户那边的情况
客户在杭州市西湖区的摄影工作室里，平时主要拍婚纱照和个人写真，上传原片到网站上用于选片。照片文件本身就比较大，一张精修过的原图能有十几兆，所以磁盘空间本来就紧张，再被日志一占满，问题就暴露得更快。
电话跟客户说明了情况，他问了一句”以后会不会又满了”，我说这次配置好轮转之后，日志会定期自动清理，不会再像之前那样无限制增长。他听完就放心了。
还发现了一个问题
在排查日志的时候，看到nginx错误日志里反复出现一条记录：
PHP Warning: opcache_get_status(): opcache is disabled
这个客户的服务器上跑着WordPress，opcache没开。打开php.ini，启用opcache，配置了几个基本参数：
opcache.enable=1 opcache.memory_consumption=128 opcache.max_accelerated_files=4000
配置完重启php-fpm之后再观察，页面加载速度提升了不少，原来2秒多才能打开的页面现在不到1秒。这个属于意外收获。
半个月后
半个月后客户在微信上主动发消息说，服务器一直挺稳定，没有再出现无法上传的问题。还问了一句”到时候备用的图片空间怎么办”，我说可以加一块云存储挂载上去，或者把老照片定期归档到冷存储里，目前空间够用，等快满了再考虑扩容也行。
磁盘满了这种问题，看着不大，但影响很直接。网站一不能上传东西，前台功能就不完整了。提前做好日志轮转和空间监控，不至于等到塞满了再手忙脚乱地清理。
如果你也遇到类似的磁盘满了或者网站上传报错的问题，可以自己检查一下日志目录大小。如果不清楚怎么配置轮转，或者想顺便给服务器做一次全面检查，随时联系我们。
