![Linux 使用整个交换区,在有足够的可用 RAM 时变得无响应](https://linux22.com/image/7144/Linux%20%E4%BD%BF%E7%94%A8%E6%95%B4%E4%B8%AA%E4%BA%A4%E6%8D%A2%E5%8C%BA%EF%BC%8C%E5%9C%A8%E6%9C%89%E8%B6%B3%E5%A4%9F%E7%9A%84%E5%8F%AF%E7%94%A8%20RAM%20%E6%97%B6%E5%8F%98%E5%BE%97%E6%97%A0%E5%93%8D%E5%BA%94.png)
我最近遇到一个奇怪的问题:
有时(我无法故意重现它),我的系统正在使用其所有交换空间,尽管有足够的可用 RAM。如果发生这种情况,系统会在几分钟内变得无响应,然后 OOM 杀手会杀死一个没有多大帮助的“随机”进程,或者杀死 X 服务器。如果它杀死一个“随机”进程,系统不会变得响应(仍然没有交换空间,但有大量可用 RAM);如果它杀死了 X,则交换区将被释放,系统将再次响应。
free 发生时的输出:
$ free -htl
total used free shared buff/cache available
Mem: 7.6G 1.4G 60M 5.7G 6.1G 257M
Low: 7.6G 7.5G 60M
High: 0B 0B 0B
Swap: 3.9G 3.9G 0B
Total: 11G 5.4G 60M
名称-a:
Linux fedora 4.4.7-300.fc23.x86_64 #1 SMP Wed Apr 13 02:52:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
交换性:
cat /proc/sys/vm/swappiness
5
dmesg 中的相关部分:http://pastebin.com/0P0TLfsC
临时文件系统:
$ df -h -t tmpfs
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.8G 1.5M 3.8G 1% /dev/shm
tmpfs 3.8G 1.7M 3.8G 1% /run
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
tmpfs 3.8G 452K 3.8G 1% /tmp
tmpfs 776M 16K 776M 1% /run/user/42
tmpfs 776M 32K 776M 1% /run/user/1000
内存信息: http://pastebin.com/CRmitCiJ
顶部-o SHR -n 1 任务:总共 231 个,1 个正在运行,230 个正在睡觉,0 个停止,0 个僵尸 %Cpu(s):8.5 us、3.0 sy、0.3 ni、86.9 id、1.3 wa、0.0 hi、0.0 si、0.0 st KiB Mem:总计 7943020,空闲 485368,已用 971096,6486556 buff/缓存 KiB 交换:总计 4095996,免费 1698992,已使用 2397004。 989768 可用内存 PID 用户 PR NI VIRT RES SHR S %CPU %MEM TIME+ 命令 2066 mkamlei+ 20 0 8342764 163908 145208 S 0.0 2.1 0:59.62 Xorg 2306 mkamlei+ 20 0 1892816 138536 27168 S 0.0 1.7 1:25.47 侏儒外壳 3118 mkamlei+ 20 0 596392 21084 13152 S 0.0 0.3 0:04.86 侏儒终端- 1646 gdm 20 0 1502632 60324 12976 S 0.0 0.8 0:01.91 侏儒外壳 2269 mkamlei+ 20 0 1322592 22440 8124 S 0.0 0.3 0:00.87 侏儒设置- 486 root 20 0 47048 8352 7656 S 0.0 0.1 0:00.80 系统日志 2277 姆卡姆莱+ 9 -11 570512 10080 6644 S 0.0 0.1 0:15.33 2581 mkamlei+ 20 0 525424 19272 5796 S 0.0 0.2 0:00.37 红移gtk 1036 根 20 0 619016 9204 5408 S 0.0 0.1 0:01.70 网络管理器 1599 gdm 20 0 1035672 11820 5120 S 0.0 0.1 0:00.28 gnome-设置- 2386 mkamlei+ 20 0 850856 24948 4944 S 0.0 0.3 0:05.84 果阿守护进程 2597 mkamlei+ 20 0 1138200 13104 4596 S 0.0 0.2 0:00.28 进化警报 2369 mkamlei+ 20 0 1133908 16472 4560 S 0.0 0.2 0:00.49 进化源 2529 mkamlei+ 20 0 780088 54080 4380 S 0.0 0.7 0:01.14 gnome 软件 2821 mkamlei+ 20 0 1357820 44320 4308 S 0.0 0.6 0:00.23 进化日历 2588 mkamlei+ 20 0 1671848 55744 4300 S 0.0 0.7 0:00.49 进化日历 2525 mkamlei+ 20 0 613512 8928 4188 S 0.0 0.1 0:00.19 abrt 小程序
ipc:
[mkamleithner@fedora ~]$ ipcs -m -t ------ 共享内存附加/分离/更改时间 -------- shmid 所有者附加分离已更改 294912 mkamleithn 4 月 30 日 20:29:16 未设置 4 月 30 日 20:29:16 393217 mkamleithn 四月 30 20:29:19 四月 30 20:29:19 四月 30 20:29:17 491522 mkamleithn 四月 30 20:42:21 四月 30 20:42:21 四月 30 20:29:18 524291 mkamleithn 4月30日 20:38:10 4月30日 20:38:10 4月30日 20:29:18 786436 mkamleithn 4 月 30 日 20:38:12 未设置 4 月 30 日 20:38:12 [mkamleithner@fedora ~]$ ipcs ------ 消息队列 -------- 密钥 msqid 所有者权限已用字节消息 ------ 共享内存段 -------- 密钥 shmid 所有者权限字节 nattch 状态 0x00000000 294912 mkamleithn 600 524288 2 目标 0x00000000 393217 mkamleithn 600 2576 2 目的地 0x00000000 491522 mkamleithn 600 4194304 2 目标 0x00000000 524291 mkamleithn 600 524288 2 目的地 0x00000000 786436 mkamleithn 600 4194304 2 目标 ------ 信号量数组 -------- key semid 所有者权限 nsems
[mkamleithner@fedora ~]$ ipcs -m -t ------ 共享内存附加/分离/更改时间 -------- shmid 所有者附加分离已更改 294912 mkamleithn 4 月 30 日 20:29:16 未设置 4 月 30 日 20:29:16 393217 mkamleithn 四月 30 20:29:19 四月 30 20:29:19 四月 30 20:29:17 491522 mkamleithn 四月 30 20:42:21 四月 30 20:42:21 四月 30 20:29:18 524291 mkamleithn 4月30日 20:38:10 4月30日 20:38:10 4月30日 20:29:18 786436 mkamleithn 4 月 30 日 20:38:12 未设置 4 月 30 日 20:38:12
[mkamleithner@fedora ~]$ sudo grep 786436 /proc/*/maps /proc/2084/maps:7ff4a56cc000-7ff4a5acc000 rw-s 00000000 00:05 786436 /SYSV00000000 (已删除) /proc/3984/maps:7f4574d00000-7f4575100000 rw-s 00000000 00:05 786436 /SYSV00000000 (已删除)
[mkamleithner@fedora ~]$ sudo grep 524291 /proc/*/maps /proc/2084/maps:7ff4a4593000-7ff4a4613000 rw-s 00000000 00:05 524291 /SYSV00000000 (已删除) /proc/2321/maps:7fa9b8a67000-7fa9b8ae7000 rw-s 00000000 00:05 524291 /SYSV00000000 (已删除)
[mkamleithner@fedora ~]$ sudo grep 491522 /proc/*/maps /proc/2084/maps:7ff4a4ad3000-7ff4a4ed3000 rw-s 00000000 00:05 491522 /SYSV00000000 (已删除) /proc/2816/maps:7f2763ba1000-7f2763fa1000 rw-s 00000000 00:05 491522 /SYSV00000000 (已删除)
[mkamleithner@fedora ~]$ sudo grep 393217 /proc/*/maps /proc/2084/maps:7ff4b1a60000-7ff4b1a61000 rw-s 00000000 00:05 393217 /SYSV00000000 (已删除) /proc/2631/maps:7fb89be79000-7fb89be7a000 rw-s 00000000 00:05 393217 /SYSV00000000 (已删除)
[mkamleithner@fedora ~]$ sudo grep 294912 /proc/*/maps /proc/2084/maps:7ff4a5510000-7ff4a5590000 rw-s 00000000 00:05 294912 /SYSV00000000 (已删除) /proc/2582/maps:7f7902dd3000-7f7902e53000 rw-s 00000000 00:05 294912 /SYSV00000000 (已删除)
获取进程名称:
[mkamleithner@fedora ~]$ ps aux |查询 2084 mkamlei+ 2084 5.1 2.0 8149580 159272 tty2 Sl+ 20:29 1:10 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3 mkamlei+ 5261 0.0 0.0 118476 2208 点/0 S+ 20:52 0:00 grep --color=auto 2084 [mkamleithner@fedora ~]$ ps aux | grep 3984 mkamlei+ 3984 11.4 3.6 1355100 293240 tty2 Sl+ 20:38 1:38 /usr/lib64/firefox/firefox mkamlei+ 5297 0.0 0.0 118472 2232 点/0 S+ 20:52 0:00 grep --color=auto 3984
我还应该发布其他 shmids 的结果吗?我真的不知道如何解释输出。
我怎样才能解决这个问题?
编辑:开始游戏“请出示文件”似乎总是在一段时间后触发此问题。不过,当游戏未开始时,有时也会发生这种情况。
Edit2:似乎是一个X问题。在 Wayland 上,这种情况不会发生。可能是由于 xorg.conf 中的自定义设置。
最终编辑:对于遇到相同问题的任何人:我使用的是 DRI 2。切换到 DRI 3 也可以解决该问题。这是我在 xorg.conf 中的相关部分:
“设备”部分 标识符“英特尔显卡” 驱动程序“英特尔” 选项“AccelMethod”“sna”# 选项“背光”“intel_backlight” 总线ID“PCI:0:2:0” 选项“DRI”“3”#here 选项“TearFree”“true” 结束部分
我系统上的相关文件位于 /usr/share/X11/xorg.conf.d/ 中。
答案1
tmpfs 使用的共享内存(大部分)(/proc/meminfo 中的 Shmem,在内核 2.6.32 上可用,如果不可用则显示为零)>
因此,联机帮助页定义Shared
并没有它应有的帮助:(。如果 tmpfs 使用确实不是如果要反映 Shared 的高值,则该值必须表示某个进程“谁使用 MAP_SHARED|MAP_ANONYMOUS 执行了 mmap()”(或 System V 共享内存)。
8G 系统上的 6G 共享内存仍然是一个很多。说真的,你不希望这样,至少在桌面上不希望这样。
奇怪的是它似乎也有助于“buff/cache”。但我用 python 做了一个快速测试,这就是它的工作原理。
要显示拥有最多共享内存的进程,请使用top -o SHR -n 1
。
系统V共享内存
最后,您可能有一些使用系统 V 共享内存段的可怕的遗留软件。如果他们得到泄露,他们不会出现在top
:(。
您可以使用 列出它们ipcs -m -t
。希望最近创建的一个仍在使用中。获取 shmid 编号,例如
$ ipcs -m -t
------ Shared Memory Attach/Detach/Change Times --------
shmid owner attached detached changed
3538944 alan Apr 30 20:35:15 Apr 30 20:35:15 Apr 30 16:07:41
3145729 alan Apr 30 20:35:15 Apr 30 20:35:15 Apr 30 15:04:09
4587522 alan Apr 30 20:37:38 Not set Apr 30 20:37:38
# sudo grep 4587522 /proc/*/maps
-> 那么 /proc 路径中显示的数字就是使用 SHM 的进程的 pid。 (所以你可以例如 grep ps 的输出来查找该 pid 号)。
明显的矛盾
Xorg 有 8G 映射。即使您没有独立的显卡 RAM。它只有 150M 居民。并不是说剩下的都被换掉了,因为你没有足够的交换空间。
显示的 SHM 段
ipcs
全部附加到两个进程。所以它们都没有泄露,它们应该都会出现在SHR栏目中top
(双数偶数)。如果使用的页数小于内存段的大小也没关系,这只是意味着还有页没有被使用。但是free
说我们有 6GB 的已分配共享内存需要占用,但我们找不到。
答案2
shared
tmpfs 使用的内存(大部分)(/proc/meminfo 中的 Shmem,在内核 2.6.32 上可用,如果不可用则显示为零)
tmpfs 是可交换的。您的 tmpfs 文件系统的填充量超出了安全限制。作为比较,我输入此内容的系统有 200M 共享空间。对于运行桌面、同时运行 Dropbox 和 Steam 等功能的 8G 系统来说,6G 太多了。
您可以使用普通工具来查找导致问题的文件。尽管从理论上讲,当您的 X 会话终止时,这些文件可能会消失。
$ df -h -t tmpfs
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.9G 1.7M 1.9G 1% /dev/shm
tmpfs 1.9G 1.6M 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
tmpfs 1.9G 80K 1.9G 1% /tmp
tmpfs 376M 20K 376M 1% /run/user/42
tmpfs 376M 20K 376M 1% /run/user/1000
限制您的 tmpfs 安装,以便解决您的问题,获得分析它们的机会,甚至可能从填充它们的软件中触发有用的错误消息。
默认情况下,每个 tmpfs 限制为可用 RAM 的 1/2。
因此,最好不要在默认限制下增加多个 tmpfs 挂载。正如您在上面所看到的,对于我的 4GB 系统来说,发行版在这方面并没有达到应有的水平。
显然可以在运行时更改限制mount -oremount,size=10% /tmp
。
您可以将重新安装命令放置在启动时运行的某个位置,例如/etc/rc.local
(可能需要systemctl enable rc-local
)。注意/run/user/*
可能会在脚本运行后安装;希望他们已经有了合理的限制。
默认的 tmpfs 安装往往不会在 中列出/etc/fstab
。在systemd下,您可以使用/tmp
例如修改挂载systemctl edit tmp.mount
。否则,您可以通过系统脚本 grep 来查找它们挂载 /tmp 的位置;它可能使用您可以编辑的配置文件。另一个有效的选项/tmp
是完全禁用 tmpfs 挂载 ( systemctl disable tmp.mount
),只让程序写入根文件系统。