Docker容器中的核心转储大于磁盘大小

时间:2019-09-17 16:19:54

标签: docker coredump

我有一个正在创建核心转储的容器,并且文件被报告为大于实际文件系统。

核心转储显示为124 GB,但文件系统只有30 GB,仍然有12 GB的可用空间。

我知道我可以通过在docker run命令中设置容器ulimit来限制核心转储的大小,但是我的问题是:

  • 为什么核心文件看起来这么大?
  • 转储文件的真实大小是多少?

很明显,报告的文件大小不正确,我猜它与覆盖文件系统有关,但是它是某种错误还是预期的行为?

无论是否提及Docker,我都尝试过谷歌搜索,但是我发现唯一与远程相关的是this

一些相关信息:

  • Docker版本18.06.1-ce,内部版本e68fc7a
  • Ubuntu 16.04.5 LTS
  • AWS t3.xlarge实例(16 GB RAM)
$ docker system df -v
Images space usage:

REPOSITORY           TAG                 IMAGE ID            CREATED ago         SIZE                SHARED SIZE         UNIQUE SiZE         CONTAINERS
my-image             latest              df2c7bc0cc50        10 months ago ago   1.608GB             917.7MB             690MB               1


Containers space usage:

CONTAINER ID        IMAGE                        COMMAND                  LOCAL VOLUMES       SIZE                CREATED ago         STATUS              NAMES
f7a9de1659d0        my-image                     "gunicorn --config g…"   0                   124GB               6 months ago ago    Up 13 days          abc
$ docker ps --size
CONTAINER ID        IMAGE                        COMMAND                  CREATED             STATUS              PORTS                 NAMES     SIZE
f7a9de1659d0        my-image                     "gunicorn --config g…"   6 months ago        Up 13 days          5000/tcp, 8000/tcp    abc       124GB (virtual 126GB)
$ df -h
Filesystem       Size  Used Avail Use% Mounted on
udev             7.8G     0  7.8G   0% /dev
tmpfs            1.6G   26M  1.6G   2% /run
/dev/nvme0n1p1    30G   18G   12G  60% /
tmpfs            7.8G     0  7.8G   0% /dev/shm
tmpfs            5.0M     0  5.0M   0% /run/lock
tmpfs            7.8G     0  7.8G   0% /sys/fs/cgroup
tmpfs            1.6G     0  1.6G   0% /run/user/1000

一些来自容器内部:

root@f7a9de1659d0:/app# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay          30G   18G   12G  60% /
tmpfs            64M     0   64M   0% /dev
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
shm              64M     0   64M   0% /dev/shm
tmpfs           7.8G     0  7.8G   0% /proc/acpi
tmpfs           7.8G     0  7.8G   0% /proc/scsi
tmpfs           7.8G     0  7.8G   0% /sys/firmware
root@f7a9de1659d0:/app# ls -l
total 1474124
-rw-rw-r-- 1 root root           40 Sep 17  2018 Procfile
drwxr-xr-x 1 root root         4096 Mar  6  2019 __pycache__
-rw-rw-r-- 1 root root         2487 Oct 22  2018 app.py
-rw------- 1 root root 124045455360 Sep 16 11:31 core
-rw-rw-r-- 1 root root          801 Sep 17  2018 gunicorn.conf
-rw-rw-r-- 1 root root         1815 Sep 17  2018 readme.md
-rw-rw-r-- 1 root root           64 Sep 17  2018 requirements.txt
-rw-rw-r-- 1 root root          412 Sep 17  2018 client.py
root@f7a9de1659d0:/app# file core 
core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), too many program headers (29701)
root@f7a9de1659d0:/app# ulimit -c
unlimited

编辑:添加了使上述file命令起作用的选项:

root@f7a9de1659d0:/app# file -Pelf_phnum=30000 core
core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/usr/local/bin/python /usr/local/bin/gunicorn --config gunicorn.conf app:app', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: '/usr/local/bin/gunicorn', platform: 'x86_64'

0 个答案:

没有答案