我最近更新到了 Ubuntu 20.04.3(内核 5.11.0-34-generic #36~20.04.1-Ubuntu SMP),所以这可能是一个错误。使用几个小时后,共享内存分区就填满了。根据df
,分区/dev/shm
中有 16G 的数据:
Filesystem Size Used Avail Use% Mounted on
...
tmpfs 16G 16G 0 100% /dev/shm
...
尝试将新文件写入该分区失败:
$ echo "foobar" > /dev/shm/foobar.txt
bash: echo: write error: No space left on device
但是,当我查看该分区中的文件时,这些文件仅使用了大约 170K:
$ du -h /dev/shm/*
0 /dev/shm/foobar.txt
4.0K /dev/shm/sem.CiscoAcMemoryLock
4.0K /dev/shm/sem.CiscoAcNamedEventNVM
4.0K /dev/shm/sem.CiscoAcNamedEventOpenDNS
4.0K /dev/shm/sem.CiscoAcNamedEventPostureISE
156K /dev/shm/tmp
我注意到这种情况发生是因为 google-chrome 转储了核心,并且我无法重新启动 Chrome,直到有空间为止/dev/shm
,而我发现恢复内存的唯一方法就是重新启动。
我怎样才能找出 /dev/shm 中正在使用的空间?
答案1
只要文件仍有目录条目,它们就存在于文件系统中或者正由当前进程保持打开状态。运行du -h /dev/shm/
(添加*
以 开头的排除文件.
)将仅显示前者。
您还需要运行sudo lsof /dev/shm
,它显示该文件系统上当前打开的文件。
例如:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
QtWebEngi 654092 user DEL REG 0,31 2610 /dev/shm/.org.chromium.Chromium.eAzBpJ
QtWebEngi 654092 user DEL REG 0,31 2613 /dev/shm/.org.chromium.Chromium.eY7oKn
QtWebEngi 654092 user DEL REG 0,31 2624 /dev/shm/.org.chromium.Chromium.zuBEOF
QtWebEngi 654092 user 22u REG 0,31 144 2610 /dev/shm/.org.chromium.Chromium.eAzBpJ (deleted)
QtWebEngi 654092 user 29u REG 0,31 144 2613 /dev/shm/.org.chromium.Chromium.eY7oKn (deleted)
QtWebEngi 654092 user 46r REG 0,31 1048576 2624 /dev/shm/.org.chromium.Chromium.zuBEOF (deleted)
以 结尾的行将(deleted)
不会被找到du
,但只要有任何进程持有该文件,它仍然会占用空间。
答案2
我在 Ubuntu 20.04 LTS 上遇到了同样的问题(内核版本 5.11.0.34.36,使用更新程序更新至 5.11.0.36.40)。将内核更新至最新版本后,问题解决了。Marc Gil Sendra 发帖称,请参阅https://unix.stackexchange.com/questions/654004/ubuntu-20-04-problems-with-chrome-teams-visual-studio-code-maybe-related-wi从 2021 年 7 月 14 日起,他解决了将内核更新到 5.12.10 版本的问题。我使用https://linuxhint.com/install-upgrade-linux-kernel-ubuntu-linux-mint/将版本升级到 5.14.8-051408-generic 后问题似乎得到解决。