docker容器临时文件去除，服务器容量空间

概述：

接到告警提醒，服务器容量不足，去查看了一下，发现确实100g左右容量已基本用完；

分析：

1）查看根目录下哪些文件夹占用容量较大

使用命令“ du -ah --max-depth=1 / ” 查看目标目录下所有文件夹的容量：

可以看到目录 /var 下面占用了很大的容量，继续使用命令查看“du -ah --max-depth=1 /var”：

继续跟进lib目录“du -ah --max-depth=1 /var/lib”：

继续下钻“du -ah --max-depth=1 /var/lib/docker/”:

2、看到这里发现/var/lib/docker/overlay2 下的容量非常大

在 Linux 系统中，/var/lib/docker/overlay2 是 Docker 容器引擎使用 overlay2 存储驱动 时的核心数据存储目录，主要用于管理 Docker 镜像和容器的文件系统分层数据。
具体作用：
Docker 采用 分层存储机制（类似 “栈” 的结构），而 overlay2 是 Docker 推荐的存储驱动之一（基于 Linux 内核的 overlayfs 技术），/var/lib/docker/overlay2 正是这种机制的实际数据存放位置，主要包含：

1、 镜像层（Image Layers）：

Docker 镜像由多个只读层（Layer）组成（例如基础系统层、依赖库层、应用层等），这些层的实际文件数据就存储在该目录下。多个镜像可能共享相同的基础层，从而节省空间。

2、容器读写层（Container Layers）：

当容器启动时，Docker 会在镜像只读层之上添加一个 可写层（用于容器运行时的文件修改、新增、删除等操作），这部分临时数据也存储在 overlay2 目录中。容器停止后，可写层不会自动删除（除非手动清理）。
元数据：
3、记录各层的关联关系、校验信息等，确保 Docker 能正确组装镜像和容器的文件系统。
为什么这个目录会很大？

• 长期使用 Docker 后，未清理的 旧镜像、停止的容器（及其可写层）、未使用的临时层 会不断累积，导致目录占用空间增大。
• 容器运行过程中产生的日志、临时文件、缓存等也可能存放在可写层中，进一步占用空间。

如何清理空间？
如果该目录占用过大，可以通过 Docker 自带的命令安全清理（操作前建议确认不需要的资源）：
清理所有未使用的资源（停止的容器、未被引用的镜像、悬空镜像、未使用的卷等）：
本次操作就是用下面的这个命令：

bash
docker system prune -a --volumes

• -a：删除所有未被容器引用的镜像（包括未打标签的 “悬空镜像”）。
• –volumes：同时清理未被使用的数据卷（谨慎使用，确保卷中无重要数据）。

单独清理无用镜像：

bash
docker image prune -a

单独清理停止的容器：

bash
docker container prune

注意：
不要直接手动删除 overlay2 目录下的文件（可能导致 Docker 数据损坏，容器 / 镜像无法正常使用）。
清理前确保重要容器已停止或备份，避免误删正在使用的资源。
通过以上操作，通常能显著减少 overlay2 目录的占用空间。

3）执行完以上操作发现容量还是比较大

继续使用“du -ah --max-depth=1 /var/lib/docker/overlay2/”查看目录的大小：

发现红框这个文件非常大，所以就看这个地方：
911d4b0c8e6ef3ad8cad514279b0b0ba28bb6c6a32cac154aba1d4a703c85836 的子目录占用（43G），其他目录占用空间较小。下面具体解释并提供处理思路：
这些哈希命名的目录是什么？
overlay2 目录下的子目录名称是随机哈希值，每个目录对应 Docker 的一个 存储层（可能是镜像的只读层，或容器的可写层）：

• 带 -init 后缀的目录（如 16fd4ddd…-init）通常是容器初始化时的临时层，空间很小。
• 其他无后缀的目录是常规的镜像层或容器运行时的可写层。

你看到的 911d4b0c8e6ef3ad8cad514279b0b0ba28bb6c6a32cac154aba1d4a703c85836 就是一个占用大量空间的层（极可能是某个容器的可写层，因为镜像层通常不会单独这么大，且多个镜像会共享层）。
如何找到这个大目录对应的容器 / 镜像？
要确定这个 43G 的层属于哪个容器或镜像，需要通过 Docker 的元数据关联。步骤如下：
查看所有容器的存储层信息：
运行以下命令，查找哪个容器的 GraphDriver.Data.MergedDir 或 UpperDir 包含这个哈希目录：

bash
docker inspect $(docker ps -aq) | grep -B 10 "911d4b0c8e6ef3ad8cad514279b0b0ba28bb6c6a32cac154aba1d4a703c85836"

输出中会显示容器的 Name 或 Id，说明这个层是该容器的可写层（容器运行时产生的文件都存在这里）。
如果不是容器，再检查镜像：
若上述命令没结果，可能是某个镜像的层（较少见，因为镜像层通常被共享），可通过镜像元数据查找：

bash
docker inspect $(docker images -q) | grep -B 10 "911d4b0c8e6ef3ad8cad514279b0b0ba28bb6c6a32cac154aba1d4a703c85836"

执行命令：

docker inspect 结果来看，这个 43G 的大目录 911d4b0c8e6ef3ad8cad514279b0b0ba28bb6c6a32cac154aba1d4a703c85836 明确属于某个容器的 可写层（UpperDir 指向该目录，这是容器运行时写入数据的位置）。

第一步：找到这个容器的具体信息（ID / 名称）
你的 docker inspect 输出只显示了部分细节，需要进一步定位对应的容器。可以用以下命令直接找到该容器的 ID 和名称：

bash
# 遍历所有容器，找到包含该哈希的容器，并输出其ID和名称
for container in $(docker ps -aq); doif docker inspect $container | grep -q "911d4b0c8e6ef3ad8cad514279b0b0ba28bb6c6a32cac154aba1d4a703c85836"; thenecho "容器ID: $container"docker inspect --format '{{.Name}}' $container  # 输出容器名称fi
done

运行后会得到类似结果（示例）：

plaintext
容器ID: abc123456
/nginx-app  # 容器名称

第二步：分析容器内的大文件来源
确定容器后，需要进入容器内部，查看哪些文件占用了大量空间：

1. 先检查容器状态（是否在运行）：

bash
docker ps | grep 容器ID/名称  # 若有输出，说明正在运行；否则是已停止

2. 进入容器内部查找大文件：

bash
# 若容器运行中，直接进入
docker exec -it 容器ID/名称 /bin/bash
# 查看目录下最大的20个文件
du -a / 2>/dev/null | sort -nr | head -n 20

绝对不要手动删除 overlay2 目录下的文件，否则可能导致 Docker 数据损坏。

可以发现/tmp 容量河大有22g； 进入该目录看有什么文件：

查看该目录下最大的20个文件：

删除文件

 rm -f /tmp/+~JF*.tmp

# 示例：删除7天前的日志（假设日志按日期命名，如 sys-console.2025-08-05.log）
find /juzi/server/logs -name "*.log" -mtime +7 -delete

注意事项
清理文件时，确保不删除应用运行必需的临时文件（如正在使用的缓存），必要时先暂停应用再清理。
操作后建议重启容器，确保空间释放生效（docker restart 容器ID）。
通过以上步骤，可显著减少容器占用的空间，并避免未来再次出现类似问题。

从文件路径（/tmp 临时目录）和命名格式（+~JF 开头的 .tmp 文件）来看，这些文件大概率是办公软件（如 LibreOffice、OpenOffice 等）在编辑文档时生成的临时备份文件。
具体说明：

• 临时备份文件的作用

LibreOffice、OpenOffice 等办公软件在编辑文档（如 Word 文档、Excel 表格等）时，会自动创建临时文件，用于：
实时保存用户的编辑内容，防止程序崩溃、意外关闭时丢失数据；
作为文档的临时缓存，提升编辑时的响应速度。
这类文件的命名通常包含随机字符（如这里的 JF 后接一串数字），并以 .tmp 为后缀，存放于系统临时目录（/tmp）。

• 为何会残留？

正常情况下，当你关闭办公软件或保存文档后，这些临时文件会被自动删除。但如果程序异常退出（如强制关闭、崩溃），临时文件可能来不及清理，就会残留在 /tmp 目录中。
关于 ip2region.xdb
这个文件是一个IP 地址定位数据库（ip2region 是一个常用的开源 IP 库），用于将 IP 地址解析为具体的地理位置（如国家、城市等）。很多应用程序（如日志分析工具、后台服务）可能会临时使用这个库文件，用完后可能留在 /tmp 目录。

• 处理建议：

如果确认近期没有正在编辑的办公文档，这些 +~JF*.tmp 文件可以安全删除（避免占用磁盘空间）；
ip2region.xdb 若暂时不用，也可删除，后续有程序需要时会重新生成或下载。
删除命令（谨慎操作，确保不再需要）：

bash
rm -f /tmp/+~JF*.tmp /tmp/ip2region.xdb