某一天，我在物理机上操作MySQL的时候，突然弹出报错。No space left on device，我：？？？难道MySQL也会导致 磁盘空间不足。于是我开始分析…
首先确定是不是，然后判断如何解决
检查磁盘使用情况：使用 df -h 命令查看当前磁盘的使用情况，找出空间占用较大的分区。
root@pcc:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 152M 1.5G 10% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 98G 89G 4.3G 96% /
tmpfs 7.9G 0 7.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
/dev/loop0 117M 117M 0 100% /snap/core/14784
/dev/loop1 117M 117M 0 100% /snap/core/14946
/dev/loop2 56M 56M 0 100% /snap/core18/2714
/dev/loop4 56M 56M 0 100% /snap/core18/2721
/dev/loop3 64M 64M 0 100% /snap/core20/1828
/dev/loop6 96M 96M 0 100% /snap/kata-containers/2446
/dev/loop5 140M 140M 0 100% /snap/docker/2343
/dev/loop7 167M 167M 0 100% /snap/microk8s/4565
/dev/loop8 263M 263M 0 100% /snap/nextcloud/34073
/dev/loop9 50M 50M 0 100% /snap/snapd/18596
/dev/sda2 2.0G 106M 1.7G 6% /boot
/dev/loop10 54M 54M 0 100% /snap/snapd/18933
/dev/loop11 161M 161M 0 100% /snap/wekan/1998
/dev/loop12 93M 93M 0 100% /snap/juju/22345
/dev/loop13 93M 93M 0 100% /snap/juju/21790
/dev/loop14 92M 92M 0 100% /snap/lxd/24061
/dev/loop15 263M 263M 0 100% /snap/nextcloud/34372
/dev/loop16 71M 71M 0 100% /snap/powershell/234
/dev/loop17 161M 161M 0 100% /snap/wekan/1999
/dev/loop18 92M 92M 0 100% /snap/lxd/23991
/dev/loop19 71M 71M 0 100% /snap/powershell/232
/dev/loop20 140M 140M 0 100% /snap/docker/2746
/dev/loop21 168M 168M 0 100% /snap/microk8s/5016
/dev/loop22 64M 64M 0 100% /snap/core20/1852
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/ef2c5678614dedc3e8bc0eab2aa09eead324d995cc0896f05741bbd246bd69e2/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/5c3b805898fc4c07052b325b3a3e591b04ac45c876153ffa1573691318dee861/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/fa28f14ca099eb5ab367ce5a026d014f33288cba2f511c73964482d074f43b39/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/a073cacc30734a78f37c927ebb19027b2c60390cd2ac9e20700216e093cf57d6/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/ea036587933d1cc197db2ecd6fe6e2c2900adc4b8c03f65d3b95987f69943b02/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/7b50af9938a65afecf24892da5a6256c44549552d5d545189ebf97e504887f92/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/97a7e27f1458554730a59c72c86a575f27a7a2299bbd473ba082ffb794cbaef3/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/030b1bd14f37392d4766357fd64ddb6d6b7cd1efc4e96e91df57d3494825e125/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/8af34824158d64c0552b8a3565f9243afad9993370afa772460b4dc7c72e6413/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/8441ad17388007b6c05228a33a9b08f72f37249b983340a704322777d363f3c3/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/1050ace7f98f4e7c839f6dfe859719d27697d568b40f95747271e5601484e5e9/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/12204ae97f9466c72ca71056cdd2fb77e8a2febb49a71717f99a0975b2351d44/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/5045dc32574332f6ebe252621011fe8e2d3749222d3c3c8732ef30335af0a37a/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/00a8c6f923d46192d94f23e423d3de68967811a329abb1b4d1405644176d7f81/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/a0ab354fcb9c6e35b9a4899149dcc9079582b5ec9d236836a9e2621e3dfd1fbd/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/470bd48bf4629fad22cc0906757499b70b2cdedf6de2e665fa68792dde6094a9/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/6857452d25b99a652ae35643a4387d99b8f7450b4115379088d0c82f7b4ed1b9/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/f36dff6cd01c5ee00b56ffaf44b669211b1547a6b2c7d2ee540dbdf4af13392d/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/b55ca15da9608161fba8a3b70060e1a9616e84d776897320a1ad0b88f1aec8fb/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/74955297371abfaafb77e2b1b11314503f2d653bd30e0a5f304c8856fc6b7723/merged
tmpfs 1.6G 0 1.6G 0% /run/user/1000
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/888278affc9dc350fa0498454a5561096e0df6dc3c1f6a15f5ebda0679ff965e/merged
overlay 98G 89G 4.3G 96% /var/lib/docker/overlay2/d0373a9eaf37b6a49406e60c28485e495c49ca0310a0395ceeac9a80e1175d67/merged
解决办法
根据 df -h 的输出，可以看到根目录 / 使用率已达 96%，空间紧张。同时，有大量的 /snap 和 /var/lib/docker/overlay2 目录下的挂载点使用率也达到了 100%，好了，现在我们可以确定物理机设备确实是磁盘空间不足，那么删掉一些不必要的大文件就能完美解决这个问题了。
-
检查根目录
/下的大文件和不需要的文件。使用如下命令：sudo du -a / | sort -n -r | head -n 20这将列出根目录下占用空间最大的前 20 个文件/目录。根据输出结果，删除或移动不需要的大文件。
-
清理不重要的日志文件。检查
/var/log目录下的日志文件。如果发现有过大的日志文件，可以将其删除或归档。 -
清理 Docker 相关资源。系统中运行了很多 Docker 容器，容器、镜像、卷和网络可能占用了大量磁盘空间。可以使用如下命令清理未使用的 Docker 资源：
sudo docker system prune -a注意：此操作将删除所有未使用的容器、镜像、卷和网络。在执行此操作之前，请确保备份重要数据。
-
清理 Snap 包。系统中安装了很多 Snap 包。卸载不需要的 Snap 包可以释放一些空间。使用如下命令列出已安装的 Snap 包：
snap list然后，使用
sudo snap remove [snap_name]卸载不需要的 Snap 包。 -
清理缓存和临时文件。使用如下命令清理 APT 缓存：
sudo apt-get clean清理
/tmp和/var/tmp目录下的临时文件。
root@pcc:~# du -a / | sort -n -r | head -n 20
du: cannot access '/sys/kernel/slab/:A-0000208/cgroup/vm_area_struct(341980:snap.microk8s.daemon-kubelite.service)': No such file or directory
du: cannot access '/proc/112542/task/112615/fdinfo/252': No such file or directory
du: cannot access '/proc/112542/task/113726/fd/260': No such file or directory
du: cannot access '/proc/112542/task/115608/fdinfo/260': No such file or directory
du: cannot access '/proc/112542/task/147587/fdinfo/267': No such file or directory
du: cannot access '/proc/112542/task/147588/fd/268': No such file or directory
du: cannot access '/proc/2497098': No such file or directory
du: cannot access '/proc/2546759': No such file or directory
du: cannot access '/proc/2546785': No such file or directory
du: cannot access '/proc/2546786': No such file or directory
du: cannot access '/proc/2547237': No such file or directory
du: cannot access '/proc/2571158/task/2571158/fd/4': No such file or directory
du: cannot access '/proc/2571158/task/2571158/fdinfo/4': No such file or directory
du: cannot access '/proc/2571158/fd/3': No such file or directory
du: cannot access '/proc/2571158/fdinfo/3': No such file or directory
du: cannot access '/proc/2572027': No such file or directory
du: cannot access '/proc/2572195': No such file or directory
110293067 /
76528424 /var
71727776 /var/lib
67468876 /var/lib/docker
52020060 /var/lib/docker/containers
51790472 /var/lib/docker/containers/9005ae4d891c64941c97f1e02ef1733061ab62db9a8e7cf43699cd47aed4747b
51790436 /var/lib/docker/containers/9005ae4d891c64941c97f1e02ef1733061ab62db9a8e7cf43699cd47aed4747b/9005ae4d891c64941c97f1e02ef1733061ab62db9a8e7cf43699cd47aed4747b-json.log
14384864 /var/lib/docker/overlay2
13318072 /data
13257140 /data/registry
13257136 /data/registry/docker
13257132 /data/registry/docker/registry
13257128 /data/registry/docker/registry/v2
13127212 /data/registry/docker/registry/v2/blobs
13127208 /data/registry/docker/registry/v2/blobs/sha256
9970615 /snap
7203104 /var/lib/docker/overlay2/6857452d25b99a652ae35643a4387d99b8f7450b4115379088d0c82f7b4ed1b9
4517576 /usr
4194308 /swap.img
3929820 /var/lib/docker/overlay2/6857452d25b99a652ae35643a4387d99b8f7450b4115379088d0c82f7b4ed1b9/merged
大文件分析
从du -a / | sort -n -r | head -n 20的输出来看，以下是磁盘空间占用较大的文件和目录：
/var/lib/docker/containers/9005ae4d891c64941c97f1e02ef1733061ab62db9a8e7cf43699cd47aed4747b/9005ae4d891c64941c97f1e02ef1733061ab62db9a8e7cf43699cd47aed4747b-json.log（约51.8GB）：这是一个Docker容器日志文件，占用了大量空间。可以清理或截断这个日志文件。在清理前，先确认这个日志文件中的信息是否重要，是否需要备份。/data/registry（约13.3GB）：这是一个Docker registry目录，存储了Docker镜像。如果这些镜像不再使用，可以通过docker image prune或docker rmi <image_id>命令删除不需要的镜像。/var/lib/docker/overlay2/6857452d25b99a652ae35643a4387d99b8f7450b4115379088d0c82f7b4ed1b9（约7.2GB）：这是Docker的overlay2存储驱动器的目录，包含了容器的文件系统。可以查看是否有不再使用的容器，使用docker container prune或docker rm <container_id>命令删除这些容器。/snap（约9.9GB）：这个目录包含了snap应用的数据。可以使用snap list命令查看已安装的snap应用，并使用snap remove <snap_name>命令删除不需要的应用。/swap.img（约4GB）：这是一个交换文件。通常情况下，不建议删除或缩小交换文件。
/var/lib/docker/containers/
查看当前文件夹总量
du -sh
查看当前文件夹下所有文件大小（包括子文件夹）
du -h
15M ./package
16K ./.fontconfig
4.0K ./.cache
5.1M ./.rpmdb
20M .
执行
先删除文件，并重新创建一个文件。
在某些情况下，即使删除了一个大文件，磁盘空间也不会立即释放。这通常是因为文件仍然被一个或多个正在运行的进程占用。
在这种情况下，咱们就需要找到仍在使用这个日志文件的进程，并重启它们。因为这是一个Docker容器日志文件，所以尝试重启相关的Docker容器就行。
- 首先，找到使用该日志文件的容器ID。容器ID为：
9005ae4d891c64941c97f1e02ef1733061ab62db9a8e7cf43699cd47aed4747b。 - 使用以下命令重启容器：
docker restart 9005ae4d891c64941c97f1e02ef1733061ab62db9a8e7cf43699cd47aed4747b
- 确认容器已经重启，检查磁盘空间是否已经释放。
如果磁盘空间仍然没有释放，请检查是否还有其他进程在使用该文件。可以使用lsof命令找到这些进程：
lsof | grep 9005ae4d891c64941c97f1e02ef1733061ab62db9a8e7cf43699cd47aed4747b-json.log
成功
这里可以看出来，磁盘空间已经清理了出一部分了，又可以愉快的进行编码啦。
思考
除此之外，为了解决这个问题。咱们还是很有必要搞清楚为什么会出现No space left on device 这个问题。
例如，咱们这次是因为一个日志文件变得非常大，百度发现可能是以下原因
- 高日志级别：应用程序或服务可能被配置为输出大量详细的日志信息，例如调试或跟踪级别的日志。这会导致日志文件迅速增长，占用大量磁盘空间。
- 高请求/事件频率：如果应用程序或服务需要处理大量请求或事件，这可能导致大量日志记录。例如，一个繁忙的Web服务器或数据库可能会生成大量日志。
- 错误或异常：如果应用程序或服务遇到许多错误或异常，这可能导致大量的错误日志记录。这些错误可能是由程序中的bug或配置问题引起的。
- 日志轮换策略：如果应用程序或服务的日志轮换策略不合适，可能会导致日志文件不断增长。一个好的日志轮换策略应该定期删除或压缩旧日志，以节省磁盘空间。
所以咱们得采取以下措施：
- 调整日志级别：将应用程序或服务的日志级别调整为只记录关键信息，如警告和错误。这将减少日志文件大小的增长速度。
- 实施日志轮换策略：确保应用程序或服务使用合适的日志轮换策略，定期删除或压缩旧日志。
- 监控日志文件大小：定期检查日志文件大小，并在需要时手动删除或压缩过大的文件。
- 优化应用程序或服务：修复程序中的错误或配置问题，以减少错误日志记录。
这里使用的是Docker容器，于是咱们从配置Docker守护程序来限制容器日志文件的大小。设置max-size和max-file选项来限制每个容器日志文件的大小和数量。这可以通过编辑/etc/docker/daemon.json**文件或在运行容器时传递参数来实现。
cat /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "10"
}
}
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
