Linux下的根分区使用率100%，但是查看/分区下的目录都不大，没有占用满，这该怎么处理？
重启是肯定有效的，目前处理情况：重新restart应用后，空间释放出来
（1）lsof|grep deletd
（2）reboot重启
+++++++++++++++++++++++++++++++++++++++++++++ linux下磁盘占用达到100%了，不到哪些大文件耗尽了磁盘。
Linux下使用df -lh查看磁盘时：/dev/sda1 130G 123G 353M 100% / 磁盘快用尽了，但我这边就是查不到具体是哪些大文件占用的。
1、如果是大文件占用了，那么查询大于某个值的文件的方法：
find / -size +100c -print
这是从根盘开始查大于100字节的文件（至于字节数你当然可以自己设置）
你可以用
find / -size +100c -exec ls -l {}\;
来列出文件属性。
2、如果只是因为有些应用生成的日志文件较多，长时间没有清理后占用了，这种情况最明显的标志为系统空间使用量逐步递增，每天的增量基本相差不大。那么最快捷的方式莫过于询问应用厂商要到日志存放目录后进行清理。如果不到厂商，那只好自己动手咯，写个脚本查：
#!/bin/ksh
>用du命令输出所有目录所占的磁盘空间大小，以G为单位>####
du -h >fs_du.log
>#判断各层目录大小，查到占用量大的目录>#
cat fs_du.log|while read LINE FS_USED
do
if [ $LINE -ge 10 ]
then
echo $FS_USED >>result.log
else
exit
fi
donemysql下载哪个盘
####查看运行结果>##
more result.log
这样你就能看到占用量比较大的目录，从而有针对性的到相应目录下检查，看到底是什么东西在占用硬盘空间了。（if [ $LINE -ge 10 ] ，这里是判断超过10G的目录，你可以修改）3、因为人为的误操作，导致了某些进程在没有执行完成的时候被kill掉了，但是缓存中的
程序没有释放，仍然在运行，这会产生一些临时文件占用大量的磁盘空间资源，这种现象的特点是爆
发式的增长，在很短时间内就将磁盘空间占满。解决的方法：
i、如果是因为父进程被杀除，子进程还运行导致，那么最简单，kill子进程，就会释放。
ii、如果能用ipcs确认是哪个用户的进程，那么也不困难，顺着使用ipcrm就行（这个就不一一例举了，有了命令查使用方法还是很方便的）
iii、执行进程的用户是比较关键的用户如：root用户、有实例的oracle用户、在线的生产用户等。那么建议在确认是因为共享缓存的原因导致的问题后重启服务器。
4、你已经删除了一些占用量大的文件，或者在根盘下做du -h发现占用量远远的小于130G，df的结果仍然是100%的使用率。那么基本肯定你碰到了linux的一个bug，直接重启就能
解决。（当然了也不一定是bug，我碰到过那种程序在写一个日志，但是删除日志后空间不释放的问题。这个是linux本身的机制引起的，只需要停止相关的程序空间就会释放的）
其实并不是你的磁盘的空间被占用，而是你的磁盘的i节点耗尽了。使用：df -i /dev/sdbx(x 为逻辑分区)命令查看i节点情况。解决办法：删除占用i节点的空文件，命令：rm -rf `/ -empty -a -type f`
/opt分区被web日志堆满了，导致一些服务无法正常运行，于是rm -fr掉这些日志（近11GB），但是服务仍没有恢复正常，用df -hT看，该分区占用还是100%：
[root@anjing opt]# df -hT
文件系统类型容量已用可用已用% 挂载点
/dev/sda9 ext3  996M  228M  717M  25% /
/dev/sda10  ext3 27G 12G 14G  47% /var
/dev/sda8 ext3  996M 34M  911M 4% /home
/dev/sda7 ext3    2.0G 36M  1.9G 2% /temp
/dev/sda6 ext3    3.0G  2.6G  228M  92% /usr
/dev/sda3 ext3 19G 19G 0 100% /opt
/dev/sda1 ext3 99M 12M 83M  12% /boot
tmpfs  tmpfs    2.0G 0  2.0G 0% /dev/shm
但是用du -sh /opt命令，看到：
[root@anjing /]# du -sh /opt/
8.3G  /opt/
应该是删除了这些文件，但是空间没有释放，当然重启可以解决目的，但是会造成服务器上所有业务中断，可使用下面命令查看删除文件占用情况：
[root@anjing opt]# lsof |grep delete
mysqld_sa 11317  root  cwd DIR  8,6  0 102107
/usr/local/mysql (deleted)
mysqld_sa 11317  root  255r  REG  8,6  13620 102182
/usr/local/mysql/bin/mysqld_safe (deleted)
mysqld  11353 mysql  txt REG  8,6 29382763 102138
/usr/local/mysql/bin/mysqld (deleted)
mysqld  11353 mysql  5u  REG  8,9  0  58761
/tmp/ibpfbHsa (deleted)
mysqld  11353 mysql  6u  REG  8,9  0  58771
/tmp/ibqoMnag (deleted)
mysqld  11353 mysql  7u  REG  8,9  0  58772
/tmp/ibN4C4Rl (deleted)
mysqld  11353 mysql  8u  REG  8,9  0  58781
/tmp/ibkWP8zr (deleted)
mysqld  11353 mysql 12u  REG  8,9  0  58782
/tmp/ibnqrZsx (deleted)
java  16961  root  1w  REG  8,3 5822263296 457562
/
opt/tomcat/logs/catalina.out (deleted)
java  16961  root  2w  REG  8,3 5822263296 457562
/opt/tomcat/logs/catalina.out (deleted)
java  16961  root 12w  REG  8,3 5469261824 197191
/opt/tomcat/logs/catalina.2013-01-02.log (deleted)
java  16961  root 13w  REG  8,3  2166784 197192
/opt/tomcat/logs/localhost.2013-01-02.log (deleted)
java  16961  root 14w  REG  8,3  0 391681
/opt/tomcat/logs/manager.2013-01-02.log (deleted)
java  16961  root 15w  REG  8,3  0 391682
/opt/tomcat/logs/host-manager.2013-01-02.log (deleted)
这里可以看到这些文件虽然删除了，但是还占用着空间，现在只要kill掉这些进程：[root@anjing /]# kill -9 16961
[root@anjing /]# df -hT
文件系统类型容量已用可用已用% 挂载点
/dev/sda9 ext3  996M  228M  717M  25% /
/dev/sda10  ext3 27G 12G 14G  47% /var
/dev/sda8 ext3  996M 34M  911M 4% /home
/dev/sda7 ext3    2.0G 36M  1.9G 2% /temp
/dev/sda6 ext3    3.0G  2.6G  228M  92% /usr
/dev/sda3 ext3 19G  8.4G  9.6G  47% /opt
/dev/sda1 ext3 99M 12M 83M  12% /boot
tmpfs  tmpfs    2.0G 0  2.0G 0% /dev/shm
问题解决，服务也恢复整理啦…

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。

rocketmq消息持久化到mysql_探秘RocketMQ消息持久化机制
« 上一篇
架构设计:系统存储(1)——块存储方案(1)
下一篇 »

发表评论