网站首页 > 技术文章 正文
作者 | 一得的跋涉
责编 | 伍杏玲
出品 | CSDN博客
对于 Linux 磁盘满的问题,我们通常的处理思路是用 du 查找可清理的大文件,然后临时删掉让磁盘使用率先降下来,从而尽快保证磁盘能继续写入。
但是,有一些情况的处理效果不太一样,du/df 呈现的结果可能还会让人迷惑不解。下面,我就分享下几个工作中遇到过的较离奇的磁盘满问题。
被忽略的隐藏文件
1、认识 swapfile
Linux 的交换文件 swapfile 的产生场景较普遍,而且也是以隐藏文件的形式存在的,因此这里主要聊聊 swapfile 这一类的隐藏文件。
当用 vim 打开一个文件时,都会产生一个 .swp 的临时隐藏交换文件,用来备份缓冲区中的内容。
当文件非正常关闭(比如直接关闭终端或者电脑断电等)时,.swp文件不会被删除,这样就可以用此文件来恢复文件。(注意当正常关闭时,此文件会被删除;且如果只是读取文件,不会产生 .swp 文件)
而且,如果 vim 意外退出后,又重新打开文件二次编辑,那么旧的 .swp 文件会继续保留,并产生新的 .swo 临时隐藏文件。
如果二次编辑的时候,vim 又异常退出了,那么还会继续产生新的临时隐藏文件.swn、.swm、 .swl ……
2、处理建议
有些隐藏文件的磁盘占用也挺大:
:/tmp # ll -rth | grep G
total 17.7G
-rw------- 1 xxxx users 17.6G 2020-02-12 18:27 .sqlkfJTFl.swp
所以有时候碰到大隐藏文件导致磁盘满的情况,如果没能发现这些隐藏文件,就会觉得离奇和疑惑。
所以在排查磁盘满问题的时候,可以通过执行 vim -r 来查看和检查下所有临时交换文件的大小;或者通过 ls -lha 把所有隐藏文件都列出来看看大小。
如果不想留 swapfile 这个特性,可以考虑关掉 swapfile :
vim /etc/vimrc
# 添加如下配置
set noswapfile # 禁止在编辑时候产生此文件;
但是注意这仅限于对文件损失可以容忍的情况下;如果不能容忍文件损失,那还是建议还是打开 swapfile:
vim /etc/vimrc
# 添加如下配置
set swapfile # 则是在编辑时候产生此文件;
未释放的已删除文件
1、du 和 df 不一致
如果隐藏文件因素排除了,还是发现 du 出来的大小诡异,比如 du 发现磁盘并没有用满,但是 df 看到磁盘使用率却是 100% 。
这又会是什么原因呢?
这时候,通常就得怀疑有一些已删除的文件,还被一些进程 hold 住句柄没释放,导致这些文件虽然已经删除,也的确看不到了,但是却还占着磁盘空间;
从而导致 du 和 df 出来的磁盘使用结果不一致的情况。
2、处理建议
通过执行 lsof | grep deleted 可以找到那些没有释放磁盘空间的文件和进程,
然后通过重启对应进程,就可以达到释放已删除文件占用的空间的目的。
这个帖子 《 清空热文件的常见错误操作 》 阐述了 “已删除文件还占用磁盘” 的产生场景和处理方式。
另外,对于这种情况,还有个错误的处理方法,这里特别提醒下:
有些同学在找到未释放已删除文件的 pid 之后,可能会直接通过 kill pid 来达到释放已删除文件的目的。
这种做法确实能够释放已删除文件,从而释放磁盘空间,但是这种做法是有副作用的,危害可大可小。
如果在离线环境这么操作,影响一般不大;但是如果在生产环境这么操作的话,那就可能搞出故障来了。
我们假设这么一种场景:
生产环境的某程序由于某种Bug,一直不会释放日志文件,而分时写入的日志文件又是有过期删除机制的,这样一直持续下去,就会发现服务器上有大量的已过期删除日志文件还占用着磁盘空间,直到产生磁盘满风险。
那么这个时候如果直接通过 kill pid 来处理的话,就直接把生产环境的在线程序直接干掉了;这个后果就可想而知了:在这个程序被守护进程拉起来之前,这个服务都是不可用的。
挂载引发的悬案
1、消失的空间
如果执行 ls -lha 并没有发现大隐藏文件,执行 lsof | grep deleted 也没有发现未释放的已删除文件;但是 df 看到根目录确实达到 100% 了 ,而 du 出来的根目录实际使用空间却并没有用满 。
这又会是什么原因呢?
出现这种情况的时候,请回忆下最近这台磁盘异常的机器,是否检修 或者 换过磁盘?
根目录出现这种离奇现象,通常就是在检修/更换磁盘的时候(这里假设是更换/data1 ),新磁盘还没挂载就开始往 /data1 写数据了,这时候由于还没挂载新盘,所以写入数据占用的是根目录的空间。
然后换好/data1 盘并重新挂载上去后,原本放在 /data1 的数据,也不会出现在挂载盘上,还是继续占用根目录的空间。
所以这时候就会出现这样的现象:
挂载后 du /data1 并不大 ,但是挂载前 /data1目录写入的数据实际却占用了根目录空间;而且这个数据在挂载后是看不到的,因此很难发现。于是就会发现根目录有一些空间似乎凭空消失了,相当诡异。
2、处理建议
2.1 解决方法
怎么确认是新的挂载盘掩盖了一些数据呢?把新的挂载盘 /data1 umount掉,然后再看看 /data1 占用的空间就知道了。
如果 umount提示 busy,可以通过执行以下命令来解决:
fuser -kmvi /data1 && umount /data1
卸载后,就会发现 /data1 目录下确实有大量文件,删除后,再 mount -a 重新挂载,然后根目录消失的磁盘空间,一般就能找回来了。
2.2 测试验证
如果还不放心的话,清理完数据再次挂载后,可以简单测试下:
dd if=/dev/zero of=/data1 bs=1M count=20000
往 /data1 大概写个 20G 数据,再观察下根目录的空间是否受影响,如果不受影响就说明问题解决!
2.3 给个建议
针对根目录这类离奇问题:建议在每次更换磁盘重新做挂载动作之前,检查一下根目录的空间使用情况;如果存在错误写入数据的情况,需要及时清理,然后再进行新盘挂载,切记。
原文链接:
https://blog.csdn.net/weixin_44648216/article/details/104505890
声明:本文系CSDN博主原创文章,版权归作者所有。
猜你喜欢
- 2024-11-04 /etc/passwd格式说明(etcpasswd 详解)
- 2024-11-04 centos7关闭防火墙firewalld 绝对不能在服务器上执行命令
- 2024-11-04 Linux系统搭建NFS网络文件系统,实现文件共享
- 2024-11-04 Linux上使用tinyproxy快速搭建HTTP/HTTPS代理器
- 2024-11-04 「神马课堂」Linux操作系统中主DNS服务器的配置(基于CentOS 7)
- 2024-11-04 Linux命令笔记-01(linux命令教程)
- 2024-11-04 Linux更改ssh端口的详细教程(提升系统安全)
- 2024-11-04 如何加固Linux系统?8种操作示例(linux主机加固)
- 2024-11-04 如何解决 Open /etc/postfix/main.cf: Permission denied ?
- 2024-11-04 Linux服务管理之Systemd配置详解,呕心沥血,匠心之作
- 最近发表
-
- 使用Knative部署基于Spring Native的微服务
- 阿里p7大佬首次分享Spring Cloud学习笔记,带你从0搭建微服务
- ElasticSearch进阶篇之搞定在SpringBoot项目中的实战应用
- SpringCloud微服务架构实战:类目管理微服务开发
- SpringBoot+SpringCloud题目整理
- 《github精选系列》——SpringBoot 全家桶
- Springboot2.0学习2 超详细创建restful服务步骤
- SpringCloud系列:多模块聚合工程基本环境搭建「1」
- Spring Cloud Consul快速入门Demo
- Spring Cloud Contract快速入门Demo
- 标签列表
-
- cmd/c (57)
- c++中::是什么意思 (57)
- sqlset (59)
- ps可以打开pdf格式吗 (58)
- phprequire_once (61)
- localstorage.removeitem (74)
- routermode (59)
- vector线程安全吗 (70)
- & (66)
- java (73)
- org.redisson (64)
- log.warn (60)
- cannotinstantiatethetype (62)
- js数组插入 (83)
- resttemplateokhttp (59)
- gormwherein (64)
- linux删除一个文件夹 (65)
- mac安装java (72)
- reader.onload (61)
- outofmemoryerror是什么意思 (64)
- flask文件上传 (63)
- eacces (67)
- 查看mysql是否启动 (70)
- java是值传递还是引用传递 (58)
- 无效的列索引 (74)