Linux磁盘占用问题排查
这几天生产服务器硬盘空间满了，服务老是挂掉。问了下老同事，一直有这个问题。
基本上生产服务器不会有什么别的东西，一般就是Nginx日志文件默认配置，长期用会吃掉一些空间，但是是可以手动配置最大日志占用空间的；然后可疑的地方大致就是docker。
快速定位问题并暂时修复
所以，总之先df -h看下磁盘占用，果然某overlay占用上天了。赶紧先docker rm掉一些旧的image，虽然只空出来2g左右的空间，但是还是能先把生产服务稳定了。
大体上，这边CICD是配合自建gitlab+自建docker registry，通过swarm来管理的，每一份image都会在生产环境下拉取，再写个定时任务、清理掉2天前的image。
看起来问题不大（除非2天内疯狂发几百个版）（遗憾的是，按照这里的开发规范，这种事情理论上的可行的），所以这里暂时不管了。如果后续要改进，就要考虑权限管理问题，然而讲道理gitlab本身就是有权限控制的啊，所以这本质上……
回来再看看磁盘占用还有什么可以改的
1 | docker system df -v |
通过命令查看image、container和volume的具体占用情况。
image占用异常的情况，可能就是上述的，不打tag而选择定时任务清理，配合开发流程上的缺陷，这些事件共同促成的。
contanier非常轻量化，很多都是以b为单位的，基本不会出现问题。
volume常见的也是日志文件，或者使用容器时不指定卷名，导致群魔乱舞，又或者甚至是数据库文件（茶）。
没错我看到了一个19gb的volume，明晃晃写着prod_redis……自建redis，开了aof持久化，然而并没有写自动重建，所以aof稳定上升，直到今天。（今天又学到了一种超隐蔽的延时bug了呢！以后接外包不结尾款……）
话不多说，直接讲解决方案：
首先
1 | docker system prune -a |
清理掉无用的image和container
然后ssh或者docker attach进到redis服务里面
1 | redis-cli bgaofrewrite |
重建aof文件，整个重建过程会先生成新的aof文件，再删除旧的，因此如果本身一点空间都没有了，是没法重建的，就只能先加硬盘了。手动跑一遍的意义在于确认剩余空间是否足够，并且重置自动重建的阈值。自动重建是根据上一次重建的文件大小的比例来确认重建时机的，因此像现在这么大的aof文件，即使打开自动重建也会达不到阈值无法生效。
最后修改redis启动命令
redis-server
–appendonly
yes
–auto-aof-rewrite-percentage
200
–auto-aof-rewrite-min-size
5gb
设置合适的重建时机。这个本身volume没有命名，问题不大，毕竟redis也不太会更新。