我最近遇到一个奇怪的问题：
有时（我无法故意重现它），我的系统正在使用其所有交换空间，尽管有足够的可用 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
sharedtmpfs 使用的内存（大部分）（/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)，只让程序写入根文件系统。