Linux服务器磁盘空间占满问题

本文介绍了Linux系统中磁盘空间被占用后无法释放的问题及其解决方法。通过使用lsof命令查找被进程占用的已删除文件,并重启相关服务来解决磁盘空间问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

下面我们一起来看一篇关于Linux服务器磁盘占满问题解决(/dev/sda3 满了),希望碰到此类问题的人能带来帮助。
 

今天下班某电商技术部leader发现个问题,说他们服务器硬盘满了。把日志文件都删掉了,可硬盘空间依旧满。于是df -h查看了下各个挂载点的状况(如下图)。

/dev/sda3 满了

/dev/sda3占用了100%,那么我们du -s -h ./*看下目录的占用情况(如下图)。

 

 

 在工作中,我们也许会遇到这样的问题,发现某个磁盘空间快满了,于是,找到一些无用的大文件将其删除后,发现磁盘空间还是没有释放掉,这是什么原因呢?如何解决呢?下面来重现一下整个过程:

查看磁盘空间情况


 [@74.114 var]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda2            9.7G  284M  8.9G   4% /
/dev/xvda1            251M   13M  226M   6% /boot
none                  1.1G     0  1.1G   0% /dev/shm
/dev/xvda10            97G   60G   33G  65% /home
/dev/xvda3            3.9G  2.7G  1.1G  72% /usr
/dev/xvda5            3.9G  3.6G   77M  98% /var

var分区快满了,找到大文件,并删除

[@74.114 var]# cd /var
[@74.114 var]# du –sh *
3.3G    account
111M    cache
53M     log
0       mail
156K    run
344K    spool

[@74.114 var]# rm –rf account/*

df –h 看一下,却依然是/var 为98%,一点都没释放。


[@74.114 var]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda2            9.7G  284M  8.9G   4% /
/dev/xvda1            251M   13M  226M   6% /boot
none                  1.1G     0  1.1G   0% /dev/shm
/dev/xvda10            97G   60G   33G  65% /home
/dev/xvda3            3.9G  2.7G  1.1G  72% /usr
/dev/xvda5            3.9G  3.6G   77M  98% /var

但du –sh * 却显示没有大文件了


[@74.114  ~]# cd /var && du –sh *
120K    account
111M    cache
53M     log
0       mail
156K    run
344K    spool

猜想1:应该是删除的内容依然被进程占用,内存没释放,所以用lsof |grep – I deleted 看了一下,发现如下:


[@74.114 account]# lsof |grep -i deleted
listserve  4833           blty    0u      CHR      136,2                    4 /dev/pts/2 (deleted)
listserve  4833           blty    1u      CHR      136,2                    4 /dev/pts/2 (deleted)
listserve  4833           blty    2u      CHR      136,2                    4 /dev/pts/2 (deleted)
Billing_P 16989           blty    0u      CHR      136,0                    2 /dev/pts/0 (deleted)
Billing_P 16989           blty    1u      CHR      136,0                    2 /dev/pts/0 (deleted)
Billing_P 16989           blty    2u      CHR      136,0                    2 /dev/pts/0 (deleted)
Billing_P 16990           blty    0u      CHR      136,0                    2 /dev/pts/0 (deleted)
Billing_P 16990           blty    1u      CHR      136,0                    2 /dev/pts/0 (deleted)
Billing_P 16990           blty    2u      CHR      136,0                    2 /dev/pts/0 (deleted)

发现时billing程序占用没释放,所以联系项目经理将Billing_P停掉,重启,依然没有释放任何空间。无果
猜想2:删除的文件是accout目录下的pacct文件,应该是由psacct产生和管理,重启这个程序后是否会OK呢?解决


[@74.114 account]# /etc/init.d/psacct restart

最后看一下磁盘空间,磁盘空间释放鸟~~


[@74.114 var]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda2            9.7G  284M  8.9G   4% /
/dev/xvda1            251M   13M  226M   6% /boot
none                  1.1G     0  1.1G   0% /dev/shm
/dev/xvda10            97G   60G   33G  65% /home
/dev/xvda3            3.9G  2.7G  1.1G  72% /usr
/dev/xvda5            3.9G  100M   3.6M  4% /var

 小建议:

以后处理相关问题时,如果发现du 和df 大小不一致的情况,可以通过lsof 查看,也许可以找到一些出现问题的原因,如果还是找不到问题,在允许的情况下不妨试一下重启服务,也许问题就迎刃而解了。
重启服务得不到解决的情况下,可以通过卸载磁盘分区来试着解决。
在决定删除某些文件前,最好确定好这个文件被哪些服务使用,先停掉这些服务再删除,这样就很少出现空间释放不了的情况了

 

linux磁盘挂载点目录占用情况(图)

挂载点下的目录之和远小于4.5G,那么是什么占用了硬盘呢?

以下为该问题的解答:

在apache/tomcat服务在运行状态下,清空了运行服务的日志,从而导致了/dev/sda3 满了的问题。一般情况下,大多数服务(包括脚本)在运行时,是不能删除当前正在写入的日志文件的。

原理分析:

1. 当前access.log日志正在被apache进程占用。
2. 通过rm命令删除access.log,实际只删除了文件名(该日志文件应用记数不为0,因此空间不会被释放)。
3. 通过rm命令删除了access.log后,apache依然写日志到access.log中,当开启apache进程时,已经通过access.log定位到该文件的inode了,就是说再写日志是不通过access.log,因此即使删除了access.log,apache依然写日志到access.log所在的inode节点,所以导致硬盘空间增加。
4. 因为删除了access.log,所以我们就找不到该文件了,du也查不到,就会出现硬盘满了但看不到究竟是哪些文件占用的。

(写的不甚详细,不明白的大家再google下。)

解决方法:

重启该日志文件的相关服务或程序,如:为apache日志文件则重启apache(如下图,重启后才硬盘空间占用正常)。

磁盘占用恢复正常(图)

转载于:https://www.cnblogs.com/cindy-cindy/p/6796684.html

Linux环境下,处理磁盘空间已满,导致数据库无法正常使用的处理方法: 第一步:查看磁盘空间使用情况 df -f 第二步:找到日志文件,并清理 1) 进入跟目录 cd / 2)查找日志文件(区分大小写) find -name *.Log; find -name *.log; find -name *.000; 第三步:进入到相应的目录,并删除日志文件 如: cd ./home1/data/db2inst2/NODE0000/SQL00001/SQLOGDIR/; rm -f *.LOG; 或者 rm -f *.log; 或者 rm -f *.000; linux下DB2管理命令 1:进入实例 su - db2inst2 2:查看某个库的表空间 db2pd -tablespaces -db mcmxfb 3:查看这个模式下所有活动库的表空间 db2pd -tablespaces -alldbs option and active database; 4: 系统重启后,对数据库的重启,首先要进入到实例下,再执行重启数据库的命令。系统会重启这个实例下的各个数据库 db2start; (注意,同的实例,要分别进入各个实例,再重启); root用户下,重启系统的方法: 重启命令: 1、reboot 2、shutdown -r now 立刻重启(root用户使用) 3、shutdown -r 10 过10分钟自动重启(root用户使用) 4、shutdown -r 20:35 在时间为20:35时候重启(root用户使用) 关机命令: 1、halt 立刻关机 2、poweroff 立刻关机 3、shutdown -h now 立刻关机(root用户使用) 4、shutdown -h 10 10分钟后自动关机 Linux环境下,磁盘空间已满,导致db2数据库无法正常使用。这里解决的,主要是日志文件和环境文件占用磁盘空间太多所引起问题
<think>嗯,用户想知道Linux服务器磁盘空间满了时的排查方法和解决思路。首先,我需要回忆一下相关的知识,然后结合提供的引用资料来整理出一个清晰的步骤。 首先,用户可能遇到了磁盘空间满的问题,导致应用服务可用,比如报错“No space left on device”。这时候,作为管理员,应该怎么一步步排查呢? 根据引用中的资料,比如引用[3]提到了使用df -h查看磁盘使用情况,然后du命令分析目录大小,还有lsof找已删除但未释放的文件。引用[5]也提到了类似的步骤,包括检查业务文件、系统盘分配、分析磁盘占用,以及考虑Docker容器的问题。 那应该先整体查看磁盘使用情况,用df -h确认哪个分区满了。比如,用户可能看到/dev/sda3使用率100%。接下来,需要找到占用空间大的目录,可以用du命令,比如du -hs /* | sort -rh | head -10,查看根目录下各目录的大小,找出占用最多的。 但有时候可能遇到目录显示占用的空间总和与实际符的情况,这可能是因为有大文件被删除但进程仍占用,导致空间未释放。这时候需要用lsof +L1或者lsof | grep deleted来查找这些文件,然后通过重启相关进程或者清空文件描述符来释放空间,如引用[3]中提到的例子,用echo "" > /proc/PID/fd/XX来释放。 另外,可能还需要检查日志文件,比如应用日志、系统日志(/var/log)是否过大,或者临时目录/tmp是否有大量文件。有些情况下,像MySQL的binlog或者Docker的容器日志也可能占用大量空间,需要检查这些地方。 还有可能磁盘空间被隐藏的大文件占用,比如用find命令查找大文件:find / -type f -size +1G -exec ls -lh {} \;。或者检查是否有过多的旧内核文件占用了/boot分区,这在使用Ubuntu时常见。 如果用户使用的是云服务器,比如阿里云,可能有监控告警,这时候需要结合告警信息快速定位问题。例如,引用[3]中提到收到阿里云的告警后,通过一系列步骤排查出Nginx占用了已删除的大文件。 此外,处理完成后,可能需要设置日志轮转、定期清理旧文件,或者扩展磁盘分区来预防未来的问题。引用[5]也提到检查Docker容器产生的文件,所以如果有容器运行,需要检查相关日志和卷的使用情况。 总结起来,步骤应该是:确认磁盘状态→定位大目录/文件→处理特殊文件(如已删除未释放)→检查日志和临时文件→考虑应用或容器相关的问题→最后优化和预防。需要确保每个步骤都清晰,并给出具体的命令示例,方便用户操作。</think>### Linux服务器磁盘空间满的排查方法及解决思路 #### 一、确认磁盘使用状态 1. **查看磁盘整体使用情况** 使用 `df -h` 命令快速定位满的分区: ```bash df -h ``` 输出示例: ``` Filesystem Size Used Avail Use% Mounted on /dev/sda3 50G 49G 0 100% / ``` 若 `Use%` 达到或接近 **100%**,说明该分区已满[^3][^4]。 --- #### 二、定位大文件或大目录 2. **分析目录占用空间** 使用 `du` 命令逐层排查占用最大的目录: ```bash du -hs /* | sort -rh | head -10 ``` 该命令会显示根目录下占用最大的前10个目录,如 `/var`、`/usr` 或 `/home`[^5]。 3. **查找隐藏的大文件** 若目录占用总和与 `df` 结果一致,可能是存在已删除但未释放的文件(常见于日志文件被删除但进程仍占用)。 使用 `lsof` 命令查找此类文件: ```bash lsof +L1 # 显示已删除但未释放的文件 lsof | grep deleted # 显示被标记为“deleted”的文件 ``` 若发现如 `/var/log/nginx/access.log (deleted)`,表示该文件已被删除但进程仍占用空间[^4]。 --- #### 三、处理特殊场景 4. **释放被进程占用的文件** 若需释放空间且能重启进程(如线上服务),可通过清空文件描述符释放资源: ```bash echo "" > /proc/<PID>/fd/<FD_NUM> ``` 例如,针对PID为1650450的进程占用的文件描述符67: ```bash echo "" > /proc/1650450/fd/67 ``` 此操作会释放文件占用的空间。 5. **检查日志文件** 常见日志文件占用场景: - **应用日志**:如Nginx的 `/var/log/nginx/access.log`。 - **系统日志**:通过 `journalctl --disk-usage` 查看系统日志占用。 - **临时文件**:检查 `/tmp` 目录是否有残留文件。 可通过日志轮转(`logrotate`)或手动清理解决[^5]。 6. **检查Docker或容器** 若服务器运行Docker,检查容器日志和存储卷: ```bash docker system df # 查看Docker磁盘使用 du -hs /var/lib/docker/containers/*/*-json.log # 检查容器日志 ``` 清理方法: ```bash truncate -s 0 /var/lib/docker/containers/*/*-json.log # 清空日志文件 ``` --- #### 四、预防措施 1. **设置日志轮转规则** 修改 `/etc/logrotate.conf` 或应用专属配置(如Nginx的 `/etc/logrotate.d/nginx`),限制日志文件大小和保留时间。 2. **监控与告警** 使用工具如 `Prometheus` + `Grafana` 或云服务商监控(如阿里云监控),设置磁盘使用率阈值告警[^5]。 3. **扩展磁盘分区** 若频繁出现空间足,可考虑扩容磁盘挂载新硬盘,并通过 `LVM` 动态调整分区大小。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值