update: 20141118 今天登录又尼玛满了,上次那样做看来还是没有解决问题。 使用df -i 只能查看整个分区的inode的占用情况 Google之后找到find-where-inodes-are-being-used 用这个脚本

find / -xdev -printf ‘%h\n’ | sort | uniq -c | sort -k 1 -n

#注意-xdev 这个参数,它是将说Don’t descend directories on other filesystems.

最好是>>到一个文本文件. _1051 /usr/src/kernels/2.6.32-431.20.3.el6.x86_64/include/linux 1051 /usr/src/kernels/2.6.32-431.23.3.el6.x86_64/include/linux 1051 /usr/src/kernels/2.6.32-431.29.2.el6.x86_64/include/linux 1063 /root/lnmp1.1-full/php-5.3.28/Zend/tests 1450 /usr/local/mariadb/data/locoyplatform 1450 /usr/local/mariadb/var/locoyplatform 3603 /usr/share/man/man3 3141137 /var/log/mysql_ 这里很容易就会发现是mysql日志的问题。 这时问题又来了300w+文件的删除,肯定是不能使用rm 会报错 -bash: /bin/rm: Argument list too 只能使用xarg或者rsync 来做删除,前者是统统传递参数,通过把文件名当参数传给xarg来删除。后者则可以通过同步一个空文件夹到目标文件夹来实现删除。

mkdir /tmp/emypy_dir_for_remove_all_files
rsync –delete-before -d -a -H -v –progress –stats /tmp/emypy_dir_for_remove_all_files /var/log/mysql/

这样就删除百万级别的文件了。 删除的过程中可以看到删除了哪些文件,因为使用了-v –progress –stats参数。 其中观察到很多类似的文件例如: deleting mysql.err-20140709-20140716.gz-20140718.gz-20140720.gz-20140722.gz-20140724.gz-20140726.gz 很明显就是logrotate中关于mysql部分的问题了。 vim 之

vim /etc/logrotate.d/mysql

#擦! 第一行写成了
/var/log/mysql/mysql*

#这样文件不就成指数级增长了… 当时估计是抽风了我.
/var/log/mysql/mysql*.log

#wq退出
logrotate -f /etc/logrotate.d/mysql #测试一下

OK 打完收工 — — — 今天登陆服务器上发现个奇怪的事情,明明用df查看磁盘上还有很多空间,但就是无法pull远程的文件过来一直给我说No space left on device 卡了一会儿经查看原来inode位100%了。 这里非常的奇怪,这台server为backup。所以应该和生产环境中差不多的文件数。看inode居然3.2M了。我勒个大去,哪来的尼玛这么多文件。 master上也就380k.还有2.8M+剩余,太奇怪了。最后在删了backup log之后终于挤出3 inodes.然后yum clean all了一下,哇啦 我擦 瞬间空出来2.8m个inodes. 这里我估计是yum的更新文件出问题了。开来不怎么用的server有时候还是得时不时的看看. EOF.