docker已满,所有inode均已使用

kx7yvsdv  于 2022-12-22  发布在  Docker
关注(0)|答案(6)|浏览(207)

我遇到了一个大问题,我的所有索引节点似乎都被使用了。我已经清理了所有未使用的卷使用命令-〉docker prune清理了所有容器和映像
但似乎它仍然是满的

Filesystem      Inodes   IUsed  IFree IUse% Mounted on
none           3200000 3198742   1258  100% /
tmpfs           873942      16 873926    1% /dev
tmpfs           873942      13 873929    1% /sys/fs/cgroup
/dev/sda1      3200000 3198742   1258  100% /images
shm             873942       1 873941    1% /dev/shm
tmpfs           873942       1 873941    1% /sys/firmware

坞站信息

Containers: 5
 Running: 3
 Paused: 0
 Stopped: 2
Images: 23
Server Version: 17.06.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 53
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 6.668GiB
Name: serveur-1
ID: CW7J:FJAH:S4GR:4CGD:ZRWI:EDBY:AYBX:H2SD:TWZO:STZU:GSCX:TRIC
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

我认为唯一能做到这一点的是我在这台机器上做的一个构建。这个构建运行一个有很多文件的npm安装。这些文件能留在服务器上吗?我有没有机会删除这些临时文件?

yfwxisqw

yfwxisqw1#

系统中是否有任何悬空卷?如果有悬空卷,它可能会填满磁盘空间。
列出所有悬挂卷

docker volume ls -q -f dangling=true

删除所有悬挂卷

docker volume rm `docker volume ls -q -f dangling=true`
vxf3dgd4

vxf3dgd42#

发现错误,这似乎是Docker 17.06.1-ce错误。这个版本似乎没有正确删除图像,并保持文件在/var/lib/docker/aufs/mnt/所以只要升级到新的Docker版本,这将是罚款。现在df显示我

Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda1       51558236 3821696  45595452   8% /
udev               10240       0     10240   0% /dev
tmpfs            1398308   57696   1340612   5% /run
tmpfs            3495768       0   3495768   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs            3495768       0   3495768   0% /sys/fs/cgroup

这样更好:)

dl5txlt9

dl5txlt93#

我也遇到了同样的问题。让Jenkins在Docker内部运行,并附带一个卷。几周后,Jenkins告诉我“npm WARN tar ENOSPC:设备”“上没有剩余空间。在谷歌搜索后,我发现所有信息节点都是使用sudo df -ih获取的。使用sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n,我可以找到使用所有信息节点的文件夹,它是使用npm的特定版本。删除了该文件夹,现在我可以再次使用了。

eit6fx6z

eit6fx6z4#

在我的例子中,它是dangling build cache,因为删除悬挂图像并不能解决这个问题。
此缓存可通过以下命令删除:docker system prune --all --force,但要小心,也许你仍然需要一些卷或映像。

icnyk63a

icnyk63a5#

这也可能是许多停止的容器的影响,例如,如果有一个使用容器的cron作业正在运行,而使用的docker run命令行不包括--rm-在这种情况下,每次cron调用都将在文件系统上留下一个停止的容器。
在这种情况下,docker info的输出将在Server -〉Containers -〉Stopped下显示一个较大的数字。
要解决此问题:

  1. docker container prune
    1.将--rm添加到cron作业中的docker run命令行。
j5fpnvbx

j5fpnvbx6#

在我的例子中,在执行80多天后,带有ingress-nginx和modsecurity的pod在mod安全结构(/var/lib/docker/overlay 2/...)中的容器卷上创建了大量目录和文件。
重启pod可解决问题。
这种情况可以推广到集装箱内部存储不受控制的其他情况

相关问题