问题解决:记录一次Linux服务器根目录突然爆满
一、出问题了
过了个双休来到公司,同时发现Linux终端的服务器状态中根目录空间直接爆满100%,周五走之前根目录仅仅使用了59%,同时项目服务的后台不停的有日志打印,而且测试的小伙伴说系统登录不上去了。下面记录一下个人排查并解决这个问题的全过程。
这个服务器部署了两个项目的后台服务,一个是在本机安装了.NET Runtime后部署的.NET Web API以及Dapr应用,另一个是Docker部署的Java项目(微服务),两组后台服务均使用到了消息队列,一组使用到了RabbitMQ,另一组则使用到了RabbitMQ和Kafka。
二、首要怀疑
因为看到后台不停的打印出日志,后台日志服务使用到了Kafka,日志也显示Kafka的一些警告信息。因此我首先想到是不是队列一直消费失败,然后不断尝试、不断报错、不停打印日志写入导致空间爆满。
进入到项目后台的容器编排配置目录,使用 du -sh *
查看空间占用,删除了Kafka、ES、RabbitMQ等一些中间件的日志后仅仅腾出了2G空间,服务部署也有俩月了,感觉这个大小属于正常情况,因此根目录爆满可能并非这个原因。
三、根目录内容逐项排查
(1)目录排查:根目录 /
此处排查主要使用du -sh
命令,大概介绍参考:
du -ach * #这个能看到当前目录下的所有文件占用磁盘大小和总大小
du -sh #查看当前目录总大小
du -sh * #查看所有子目录大小
du -sh ./* #查看当前目录下所有文件/文件夹的大小
lsof | grep delete #如果怀疑删掉的数据还在占用磁盘空间试试这个
kill -9 pid #结束掉进程就能释放磁盘空间了
du -sh命令介绍
使用du -sh *
命令查看根目录下所有子目录的大小
[root@localhost /]# du -sh *
0 bin
149M boot
0 dev
41M dockercompose
8.8G dockerfile
37M etc
36G home
32K html
0 lib
0 lib64
0 media
0 mnt
0 opt
du: 无法访问"proc/3514/task/3514/fd/4": 没有那个文件或目录
du: 无法访问"proc/3514/task/3514/fdinfo/4": 没有那个文件或目录
du: 无法访问"proc/3514/fd/4": 没有那个文件或目录
du: 无法访问"proc/3514/fdinfo/4": 没有那个文件或目录
0 proc
1.2G publish
205M root
763M run
0 sbin
0 srv
0 sys
4.0K tmp
3.1G usr
51G var
这里需要关注的两个点:
(1)为什么出现"du: 无法访问"proc/3514/task/3514/fd/4": 没有那个文件或目录"的输出?(后面再看)
(2)哪些目录占用空间巨大?
- dockerfile目录:一些docker的本地镜像文件,大小合理;
- home目录:进行了项目上三维模型数据的数据挂载,大小合理;
- var目录:记忆中并没有对这个目录存放了什么数据,不合理!
(2)目录排查:/var
为什么 /var 目录占用了51个G?本身根目录是/dev/mapper/centos-root
的挂载点,因此我怀疑激增的数据就是在var目录中,使用du -sh *
命令进行排查
[root@localhost /]# cd var
[root@localhost var]# ls
adm cache crash db empty games gopher kerberos lib local lock log mail nis opt preserve run spool tmp yp
[root@localhost var]# du -sh *
0 adm
204M cache
0 crash
8.0K db
0 empty
0 games
0 gopher
0 kerberos
51G lib
0 local
0 lock
41M log
0 mail
0 nis
0 opt
0 preserve
0 run
16K spool
0 tmp
0 yp
lib目录按照过往的经验一般就是”libraries“,存放一些库、依赖等,但是此处空间大小感觉不太对,上网搜了一下,对linux系统下var/lib的作用是这样描述的:
程序本身执行的过程中,需要使用到的数据文件放置的目录。在此目录下各自的软件应该要有各自的目录。 举例来说,MySQL的数据库放置到/var/lib/mysql/而rpm的数据库则放到/var/lib/rpm去
Linux 系统的/var目录 原创
(3)目录排查:/var/lib
进入到/var/lib下再次执行du -sh *
命令进行排查
[root@localhost var]# cd lib/
[root@localhost lib]# ls
alternatives chrony dbus docker initramfs machines NetworkManager plymouth postfix rpm-state selinux systemd tuned yum
authconfig containerd dhclient games logrotate misc os-prober polkit-1 rpm rsyslog stateless tpm vmware zerotier-one
[root@localhost lib]# du -sh *
28K alternatives
0 authconfig
4.0K chrony
1.1M containerd
0 dbus
0 dhclient
51G docker
0 games
0 initramfs
4.0K logrotate
0 machines
0 misc
16K NetworkManager
0 os-prober
4.0K plymouth
0 polkit-1
4.0K postfix
110M rpm
0 rpm-state
4.0K rsyslog
0 selinux
0 stateless
64K systemd
0 tpm
0 tuned
0 vmware
11M yum
120K zerotier-one
发现docker目录空间占用巨大,同时服务器主要用于部署Java服务(使用Docker打包、发布、部署),现在就将主要问题定位到了docker上。
(4)目录排查:/var/lib/docker
进入到var/lib/docker目录,再次执行du -sh *
命令进行排查
[root@localhost lib]# cd docker
[root@localhost docker]# du -sh *
416K buildkit
18G containers
24M image
172K network
32G overlay2
0 plugins
0 runtimes
0 swarm
0 tmp
0 trust
1.4G volumes
为什么docker的overlay2这个目录空间达到32G?到这个环节时基本能够确定是Docker相关的问题了。
四、Docker的相关排查
通过上面的逐项排查,两天内根目录的空间暴增这个情况基本定位到Docker上。
(1)Docker空间分布分析 docker system df
首先使用Docker内置命令进行Docker空间分布的分析。
docker system df
Docker 的内置 CLI 指令 docker system df ,可用于查询镜像(Images)、容器(Containers)和本地卷(Local Volumes)等空间使用大户的空间占用情况。
Docker 空间使用分析与清理
执行命令得到如下输出:
[root@localhost lib]# docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 34 24 13.85GB 6.31GB (45%)
Containers 24 24 1.128GB 0B (0%)
Local Volumes 14 9 2.086GB 536.9MB (25%)
Build Cache 13 0 0B 0B
其中”RECLAIMABLE“表示可回收的
很奇怪的一件事,一共有34个镜像,但是使用的只有24个,是不是说那些没有使用到的镜像就可以删除掉腾出空间了?
使用docker system df -v 命令查看docker空间占用的详细参数
通过”CONTAINERS“列(此镜像的容器数)发现一些镜像并没有使用到,出现这种未使用的镜像的原因是:
(1)项目需求制作服务的基础镜像时形成的冗余镜像,可删除
(2)原本由docker命令部署的容器改为了使用docker-compose部署后之前部署时拉取的重复镜像,可删除
但我觉得这些都不是一个周末后”/“目录从67%到100%爆满的原因。
先清理一下Docker的冗余吧,docker提供了docker system prune
空间清理命令
docker system prune 自动清理说明:
- 该指令默认会清除所有如下资源:
- 已停止的容器(container)
- 未被任何容器所使用的卷(volume)
- 未被任何容器所关联的网络(network)
- 所有悬空镜像(image)。
- 该指令默认只会清除悬空镜像,未被使用的镜像不会被删除。
- 添加 -a 或 --all 参数后,可以一并清除所有未使用的镜像和悬空镜像。
- 可以添加 -f 或 --force 参数用以忽略相关告警确认信息。
- 指令结尾处会显示总计清理释放的空间大小
Docker 空间使用分析与清理
[root@localhost lib]# docker system prune
WARNING! This will remove:- all stopped containers- all networks not used by at least one container- all dangling images- all dangling build cacheAre you sure you want to continue? [y/N] y
Total reclaimed space: 0B
因为记录之前做了一次清理,当时清理腾出了不到1g的空间。添加-a
参数清除所有未使用的镜像和悬空镜像,腾出大约2.49g的空间,但是距离两天前根目录69%的存储还是有一定距离。
此时再使用docker system df
命令查看docker的空间分析信息是这样的,似乎镜像于容器本身没什么问题了
[root@localhost docker]# docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 24 24 11.36GB 796.3MB (7%)
Containers 24 24 1.129GB 0B (0%)
Local Volumes 14 9 2.086GB 536.9MB (25%)
Build Cache 0 0 0B 0B
再次执行du -sh *
命令进行排查
[root@localhost docker]# du -sh *
404K buildkit
19G containers
21M image
172K network
30G overlay2
0 plugins
0 runtimes
0 swarm
0 tmp
0 trust
1.4G volumes
很奇怪的是,其中overlayer2目录仅仅比第一次少了2g,也清理了其它没用的镜像以及日志,那(92%-69%)的23%的根目录空间占用在哪里??问题很大可能就是overlayer2这个目录了。
(2)Docker的overlayer2目录
Docker目录为:
科普内容就不一一罗列了,Docker的存储目录介绍参考 docker存储目录详解。
然后搜索了关于”docker overlayer2 目录空间暴增“的内容,在下面这篇帖子得到如下答案,Docker Overlay2磁盘空间占用过大清理的方法实现 帖子中第一种情况,对帖子内容进行了概括,大概如下:
情况1: docker中部署的系统中日志内容的不断扩大 。这种情况可以手动、定时进行清理。
对于/var/lib/docker/overlay2 空间占用,存在很多误导的方法是去迁移路径等。 其实磁盘空间的占用和overlay没关系,它的使用和真实的disk使用相同,overlay只是一个docker的虚拟文件系统,真实的文件系统是前者/dev/vda1,可以看到路径所指为根目录。所以,通过该目录去查找哪里占用资源过大。占用大量空间的日志文件位于containers下…
也就是说,containers目录下是以容器id为命名的目录,存放有该容器的一些配置文件以及日志文件
[root@localhost containers]# cd 8f64f9ed27cc12e5233f877a22a461b7b47d11525cd8069b087333835f9ff802/
[root@localhost 8f64f9ed27cc12e5233f877a22a461b7b47d11525cd8069b087333835f9ff802]# ls
8f64f9ed27cc12e5233f877a22a461b7b47d11525cd8069b087333835f9ff802-json.log config.v2.json hostname mounts resolv.conf.hash
checkpoints hostconfig.json hosts resolv.conf
其中日志文件以容器ID-json.log
的结构命名,例如8f64f9ed27cc12e5233f877a22a461b7b47d11525cd8069b087333835f9ff802-json.log
(3)Docker日志清理
在/var/libs/docker/container目录下,通过这个命令查看所有容器的日志文件大小
ls -lh $(find /var/lib/docker/containers/ -name *-json.log)
发现了异常文件!为什么这个容器的日志文件大小是18G?!
查看这个ID发现是PG数据库
查看容器的日志(最后100条),发现不断再刷新,提示组合键重复,我找到原因了。我在上周四部署了另一个项目的服务后台,这个后台服务消费RabbitMq消息失败了,由于MQ的ACK机制,一直重复传递推送,一直插入失败,一直记录日志,导致两天后存储爆满。
五、举措
针对于这个问题的实际情况,我首先停止了另外一个Consumer服务,然后清空了容器的日志文件。当然后续也需要针对这个队列的消费者服务进行一些异常的处理,避免此类情况发生。
清空Docker容器的日志文件,truncate截断命令。
truncate -s 0 /var/lib/docker/containers/*/*-json.log
清理docker 容器下面的log
执行完后,空间已经腾出,根目录恢复到之前的水平。
六、回顾
这次事件暴露了很多个人的问题:
(1)消息队列的ACK机制,例如后台出现异常时不会进行确认,会重复发送执行,Consumer端的不当处理可能会导致服务器问题,因此需要加深对ACK机制的深入。
(2)Linux的磁盘分区和挂载需要加深学习。
问题解决:记录一次Linux服务器根目录突然爆满相关推荐
- 增加linux服务器根目录空间大小方法
增加linux服务器根目录空间大小方法,由于没做分区照成存储空间不足 步骤: 1.df -hl --查看系统文件分配和使用情况 Filesystem Size Used Avail Use% Moun ...
- linux服务器根目录空间不足
一.问题背景 根据用户反馈,上传下载文件报网络错误,经过排查,发现是nginx服务器根目录满了,导致出现此问题.经多次查询,重启,最终找到问题症结并处理 df -h 二.问题排查 根目录下包括所有的目 ...
- 【便签纸】记录一次Linux服务器上通过sftp上传文件时的错误
背景:在Linux服务器上,通过sftp上传文件到远程服务器. 首先,需要登录远程服务器,格式是: sftp [服务器名]@[服务器地址] 然后,需要输入服务器密码: [服务器名]@[服务器地址]'s ...
- Linux服务器根目录被误删后,找回oracle数据文件进行异机恢复
前两天,看见ITPUB微信公众一篇文章,服务器误删文件后,恢复mysql的过程,今天模拟该环境,进行oracle数据库的恢复.具体如下: reference ITPUB分享文章: http:// ...
- 记录一次linux服务器被挖矿的解决
闲来登录了一下腾讯云控制台,发现资源监控面板服务器的cpu利用率一直100%以上,甚至达到了130% 反常必有妖,毕竟我服务器除了挂了个docker几乎是没开其他应用的,一定有异常程序在作怪. 进入服 ...
- Linux服务器根目录有大量 java_pid88637.hprof文件,把更目录空间占满了,top中有java进程占用大量cpu资源
1. 查看文件后发现是 安装的 logstash 给的内存太少了: 2. 进入 logstash 目录,修改 config/jvm.options 修改: -Xms1g -Xmx1g 可以适当的 根 ...
- Linux服务器被挖矿及解决办法
记录一次Linux服务器被挖矿的经历(chattr文件权限被改)及解决办法 服务器被人挖矿,用sudo权限删除可疑进程后,发现有几个文件始终不能被具有sudo权限的用户删除.上网查找发现,这几个文件的 ...
- 美国Linux服务器系统增强安全的配置
美国Linux服务器系统可能出现的安全漏洞中,更多是由于不当的系统配置所造成的,用户们可以通过一些适当的安全配置来防止问题的发生.美国Linux服务器系统上运行的服务越多,不当配置的概率也就越高,那么 ...
- Linux入门实践笔记(七)——云服务器中配置Java项目的JMX连接失败问题解决记录
Linux入门实践笔记(七)--云服务器中配置Java项目的JMX连接失败问题解决记录 参考文章: (1)Linux入门实践笔记(七)--云服务器中配置Java项目的JMX连接失败问题解决记录 (2) ...
最新文章
- 查看mysql字符集及修改表字符集
- 跨浏览器图像灰度(grayscale)解决方案
- HDFS/zookeeper/hbase初始化
- Python缩进问题
- java删除csv一行_在Java中读取CSV文件时跳过第一行
- 荒岛余生最后一个包裹_从《荒岛余生》看上世纪九十年代美国社会主流价值观...
- 【转】拷贝构造函数的参数类型必须是引用
- 9-16 原生命令和redis-trib.rb对比
- 挑战malloc极限,看看你的系统有多大的内存分配能力
- 剑指offer——面试题59:对称的二叉树
- T-SQL语言(一)
- FL Studio21.0中文版本FL水果娘发布更新
- 神经网络——深度学习应用于计算机视觉
- Windows 平台下 LiteIDE 的安装和使用
- 计算机基金经理排名,科班出身的基金经理业绩一定比非科班的好吗?
- 电池电压测试技术总结
- 数据建模:个人信用分是如何计算出来的?
- ASE0510SH-ASEMI的MOS管ASE0510SH
- 跌吧,继续跌吧,小灰的基金已亏损64万。。。
- 1.5 DICOM图像CT值转RGB
热门文章
- 聚观早报 | 《三体》将于2023年上映;李恩祐加入京东董事会
- 史上最全自定义dialog- CommonDialog
- 中国聚乙烯亚胺(PEI)行业研究与投资前景报告(2022版)
- Go语言凭什么能成为区块链主流开发语言?
- PS学习记录9--PS网页设计教程IX——巧用大括号设计惊艳的咨询页面
- 如何在GitHub上克隆项目(超详细的图文并解)
- 在牛客网答题总结的前端面试71道HTML+CSS常考题
- 竣达技术电池SNMP网络管理远程监控方案
- 大咖齐聚CCIG论坛——文档图像智能分析的产业前沿
- 「GoCN酷Go推荐」交互式命令行工具库survey