今天,群里面有人@我服务挂了,群里都是公司那些老资格的大佬,心里一揪,还好是开发环境。我故作镇定的说,我看看,我打开Linux服务器,shell里面敲了服务状态命令,的确是挂了。于是我先重启,报错提示no space left on device。看这意思是没有空间了,不知道是内存没有空间了还是磁盘没有空间了,英语不好,于是只能轮流试一下
[root@storm bin] free -m
total used free shared buffers cached
Mem: 7983 4943 3039 0 132 183
-/+ buffers/cache: 4628 3354
Swap: 2015 1409 606
可见内存还剩3G。排除了内存,十有八九是磁盘了。于是敲下命令
[root@storm bin] df -h
Filesystem Size Used Avail Use% Mounted on
/ttt/pda1 47G 47G 0M 100% /
的确是磁盘满了,那么是哪里的文件占用了大量的磁盘空间呢?估计是应用日志。还是敲命令定位一下,因/为我们服务放在/opt/app下,所以从这个目录找起
[root@storm bin] du -sh /opt/app |grep G
38G /opt/app
[root@storm bin] du -sh /opt/app/* |grep G
20G /opt/app/message_plateform
11G /opt/app/question-h-cache
到此,占据内存的罪魁祸首找到了。磁盘总共47G,message_plateform,question-h-cache这2个服务就占据了31G。联系系统owner解决掉。那么问题来了,如何防止此类问题?
第一个就是运维写个脚步本,定期清理过期日志文件;
第二个logback提供自动压缩归档日志文件,自动清除旧的日志归档文件。
另外,可能出现磁盘空间足够,导致文件生成失败还有另一个原因,就是文件索引节点inode已满
[root@storm bin] df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/dev01-root 4964352 4964352 0 100% /
udev 503779 440 503339 1% /dev
tmpfs 506183 353 505830 1% /run
none 506183 5 506178 1% /run/lock
none 506183 2 506181 1% /run/shm
/dev/sda1 124496 255 124241 1% /boot
inodes 占用100%