这几乎没有什么观点 - 所以让我尝试一下 tl;dr
我关于应该有足够的可用内存的说法正确吗？还是我误解了free 输出中缓冲区/缓存行的含义？我可以合理地声称系统在不应该使用交换的情况下使用了交换吗？
我思考我的系统快要死掉了。然而，还有大量的可用内存。有人可以帮助我理解这一点吗？或者帮我证明这不是问题？
我花了相当多的时间来调试它，但几乎没有什么可展示的。已建立的 ssh 会话仍保持运行，但无法创建任何新会话。系统响应 ICMP ECHO (ping)。
听起来像是资源问题，但我的日常驱动程序是 FreeBSD，所以我不确定我是否在正确的位置查找。我第一次看到这种情况是在长时间运行的rsync作业（TB 级数据）中。
该系统有 4 GB 内存。自始至终，我都被告知我有大约 3400 MiB 可用内存。我看到 buff/缓存已满。对于大量文件活动，这是正常的。不过，我确实希望系统释放一些文件系统缓存而不是进行交换！
Swappiness 保留默认值：
$ cat /proc/sys/vm/swappiness
60
根据经验，我更喜欢有交换空间。到目前为止，我选择将交换文件保持在 100 MB。这是因为我认为有些事情正在发生。只需在交换文件后添加 4 或 8 GB 的空间就可能会解决这个问题。但我想了解发生了什么，因为我不希望这个系统进行交换。
我们不会过度承诺：
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
经过相当多的调试后，我最终运行了一组非常少的进程。然后，我启动了从 cifs 挂载到本地磁盘的 rsync 复制，其中包含 16396 个文件，大小为 3.2 TB。这就是我所看到的：
top - 19:46:53 up 17 min, 3 users, load average: 0,70, 0,24, 0,10
Tasks: 126 total, 2 running, 124 sleeping, 0 stopped, 0 zombie
%Cpu(s): 25,2 us, 4,1 sy, 0,0 ni, 68,3 id, 0,7 wa, 0,0 hi, 1,7 si, 0,0 st
MiB Mem : 3727,6 total, 2259,5 free, 180,1 used, 1288,0 buff/cache
MiB Swap: 100,0 total, 100,0 free, 0,0 used. 3405,7 avail Mem
top - 20:04:21 up 34 min, 3 users, load average: 1,90, 1,68, 1,18
Tasks: 125 total, 2 running, 123 sleeping, 0 stopped, 0 zombie
%Cpu(s): 27,9 us, 3,2 sy, 0,0 ni, 64,0 id, 3,6 wa, 0,0 hi, 1,3 si, 0,0 st
MiB Mem : 3727,6 total, 176,0 free, 180,6 used, 3371,0 buff/cache
MiB Swap: 100,0 total, 94,7 free, 5,3 used. 3410,9 avail Mem
top - 08:51:13 up 13:21, 3 users, load average: 2,46, 1,92, 1,69
Tasks: 126 total, 2 running, 124 sleeping, 0 stopped, 0 zombie
%Cpu(s): 25,0 us, 4,7 sy, 0,0 ni, 68,8 id, 0,0 wa, 0,0 hi, 1,6 si, 0,0 st
MiB Mem : 3727,6 total, 282,4 free, 147,9 used, 3297,3 buff/cache
MiB Swap: 100,0 total, 49,0 free, 51,0 used. 3433,4 avail Mem
[08:55:27] pi@pie:~ $ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 73168 271992 12888 3402752 0 1 6 184 213 106 26 5 66 3 0
top - 08:56:12 up 13:26, 3 users, load average: 1,97, 2,06, 1,83
Tasks: 124 total, 2 running, 122 sleeping, 0 stopped, 0 zombie
%Cpu(s): 25,7 us, 3,9 sy, 0,0 ni, 59,6 id, 9,5 wa, 0,0 hi, 1,3 si, 0,0 st
MiB Mem : 3727,6 total, 262,4 free, 125,5 used, 3339,7 buff/cache
MiB Swap: 100,0 total, 26,2 free, 73,8 used. 3454,9 avail Mem
我看到交换使用量持续缓慢上升，我确信这会杀死系统。但不是。我看到的最高值是 75.3 MB。然后下降到50左右，又开始攀升。作为一个小旁注，我应该说我只看到了 10MB/s 的速度。这大约是预期的一半基准。目前，我将此复制归因于 cifs 安装，但尚未对此进行进一步调查。
[09:05:03] pi@pie:~ $ cat /proc/meminfo
MemTotal: 3817056 kB
MemFree: 273304 kB
MemAvailable: 3542092 kB
Buffers: 10068 kB
Cached: 3319120 kB
SwapCached: 480 kB
Active: 48600 kB
Inactive: 3317168 kB
Active(anon): 18020 kB
Inactive(anon): 20600 kB
Active(file): 30580 kB
Inactive(file): 3296568 kB
Unevictable: 16 kB
Mlocked: 16 kB
HighTotal: 3080192 kB
HighFree: 17628 kB
LowTotal: 736864 kB
LowFree: 255676 kB
SwapTotal: 102396 kB
SwapFree: 24572 kB
Dirty: 46080 kB
Writeback: 0 kB
AnonPages: 36220 kB
Mapped: 15364 kB
Shmem: 2020 kB
Slab: 120440 kB
SReclaimable: 89344 kB
SUnreclaim: 31096 kB
KernelStack: 1072 kB
PageTables: 1564 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 2010924 kB
Committed_AS: 235180 kB
VmallocTotal: 245760 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
Percpu: 608 kB
CmaTotal: 262144 kB
CmaFree: 222808 kB
top - 09:18:32 up 13:48, 3 users, load average: 1,90, 1,54, 1,54
Tasks: 125 total, 2 running, 123 sleeping, 0 stopped, 0 zombie
%Cpu(s): 26,0 us, 3,8 sy, 0,0 ni, 67,4 id, 1,1 wa, 0,0 hi, 1,8 si, 0,0 st
MiB Mem : 3727,6 total, 261,0 free, 122,3 used, 3344,3 buff/cache
MiB Swap: 100,0 total, 24,7 free, 75,3 used. 3458,9 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1004 pi 20 0 22060 4812 1560 R 100,0 0,1 806:11.21 rsync
1010 pi 20 0 27716 2412 936 S 12,3 0,1 109:06.03 rsync
829 root 20 0 0 0 0 S 8,6 0,0 66:54.19 cifsd
47 root 20 0 0 0 0 S 1,3 0,0 13:29.04 kswapd0
79 root 20 0 0 0 0 S 1,0 0,0 6:17.58 usb-storage
5634 root 20 0 0 0 0 I 1,0 0,0 0:05.07 kworker/u8:3-flush-8:16
9 root 20 0 0 0 0 S 0,7 0,0 7:14.45 ksoftirqd/0
top - 09:18:32 up 13:48, 3 users, load average: 1,90, 1,54, 1,54
Tasks: 125 total, 2 running, 123 sleeping, 0 stopped, 0 zombie
%Cpu(s): 26,0 us, 3,8 sy, 0,0 ni, 67,4 id, 1,1 wa, 0,0 hi, 1,8 si, 0,0 st
MiB Mem : 3727,6 total, 261,0 free, 122,3 used, 3344,3 buff/cache
MiB Swap: 100,0 total, 24,7 free, 75,3 used. 3458,9 avail Mem
top - 11:47:09 up 16:17, 4 users, load average: 1,57, 1,61, 1,75
Tasks: 128 total, 2 running, 126 sleeping, 0 stopped, 0 zombie
%Cpu(s): 28,6 us, 5,7 sy, 0,0 ni, 62,9 id, 0,0 wa, 0,0 hi, 2,9 si, 0,0 st
MiB Mem : 3727,6 total, 280,9 free, 155,2 used, 3291,5 buff/cache
MiB Swap: 100,0 total, 46,9 free, 53,1 used. 3426,3 avail Mem
top - 12:32:23 up 17:02, 5 users, load average: 1,36, 1,39, 1,40
Tasks: 133 total, 2 running, 131 sleeping, 0 stopped, 0 zombie
%Cpu(s): 26,5 us, 5,9 sy, 0,0 ni, 66,2 id, 0,0 wa, 0,0 hi, 1,5 si, 0,0 st
MiB Mem : 3727,6 total, 274,7 free, 153,2 used, 3299,7 buff/cache
MiB Swap: 100,0 total, 46,1 free, 53,9 used. 3428,2 avail Mem
top - 10:47:38 up 1 day, 15:17, 3 users, load average: 1,57, 1,69, 1,88
Tasks: 125 total, 2 running, 123 sleeping, 0 stopped, 0 zombie
%Cpu(s): 25,8 us, 12,1 sy, 0,0 ni, 60,6 id, 0,0 wa, 0,0 hi, 1,5 si, 0,0 st
MiB Mem : 3727,6 total, 74,1 free, 155,1 used, 3498,4 buff/cache
MiB Swap: 100,0 total, 47,5 free, 52,5 used. 3427,6 avail Mem
因此，16396 个 3.2 TB 的文件让我得出结论，这不是磁盘问题，也不是 rsync 中的（直接）内存泄漏。
现在我怀疑这是运行rsync时的系统问题。我的一般假设是，如果有可用内存，文件缓存的使用量会增加。但我也希望在交换之前释放该内存。这可能有一个低水位线，但我们应该还远远没有达到这个水平。
由于没有发生任何事情，我随后使用前一个副本的 530 GB/3147 个文件子集启动了新的 rsync。这次我很幸运，在登录时触发了相同的症状。我想仔细看看正在交换和安装的内容smem。我的期望是缓存没有被释放，然后我导致了过多的交换。它看起来是这样的：
[21:15:21] pi@pie:~ $ sudo apt-get install smem
....snip....
Processing triggers for fontconfig (2.13.1-2) ...
Processing triggers for man-db (2.8.5-2) ...
[21:15:49] pi@pie:~ $ smem -t
PID User Command Swap USS PSS RSS
496 pi /lib/systemd/systemd --user 752 244 394 1524
25950 pi tmux a 0 404 815 2832
22475 pi rsync --info=progress2 --ou 0 1000 1250 2676
992 pi -bash 0 924 1277 2952
25939 pi -bash 12 916 1394 3620
25915 pi -bash 0 932 1402 3672
22477 pi rsync --info=progress2 --ou 0 1820 2000 2912
991 pi tmux new -s filecopy 0 1776 2110 3364
26241 pi /usr/bin/python /usr/bin/sm 0 5480 5661 7352
22474 pi rsync --info=progress2 --ou 0 21972 22253 23988
-------------------------------------------------------------------------------
10 1 764 35468 38556 54892
[21:15:55] pi@pie:~ $ top
-bash: /usr/bin/top: Input/output error
Bus error
[19:18:41] pi@pie:~ $ top
-bash: /usr/bin/top: Input/output error
Bus error
[19:18:51] pi@pie:~ $ htop
-bash: htop: command not found
Bus error
[19:19:01] pi@pie:~ $ smem -t
-bash: /usr/bin/smem: Input/output error
Bus error
[19:19:15] pi@pie:~ $ exit
logout
-bash: /home/pi/.bash_logout: Input/output error
-bash: /etc/bash.bash_logout: Input/output error
请注意时间如何从 21 跳回 19。我现在处于 GMT+1，因此这可能会忘记 TZ，只给我 UTC。似乎是systemd交换而不是rsync？
与此同时，我失去了logitechmediaserver在盒子上运行的连接。我使用 tmux 运行了另一个 ssh 会话来显示 rsync 的进度。 rsync 运行得很愉快。我无法在 tmux 中创建新窗口。当我从会话中分离时，我失去了 ssh 连接。我可以 ping 通该盒子，但无法联系到任何服务。
如果系统饥饿，我不确定它是否能够向日志写入任何有用的内容。至少我找不到任何/var/log/messages东西/var/log/kern.log
只有一个稍微有趣的条目/var/log/syslog
May 12 21:10:01 pie CRON[25959]: (pi) CMD (/usr/bin/flock -w 0 /tmp/syncmusic.lock /usr/bin/nice -n 10 /home/pi/syncmusic.sh > /tmp/syncmusic.log)
May 12 21:15:01 pie CRON[25985]: (pi) CMD (/usr/bin/flock -w 0 /tmp/syncmusic.lock /usr/bin/nice -n 10 /home/pi/syncmusic.sh > /tmp/syncmusic.log)
May 12 21:15:49 pie dbus-daemon[317]: [system] Activating via systemd: service name='org.freedesktop.PackageKit' unit='packagekit.service' requested by ':1.43' (uid=0 pid=26225 comm="/usr/bin/gdbus call --system May 12 20:53:52 pie systemd-modules-load[106]: Inserted module 'i2c_dev'
May 12 20:53:52 pie fake-hwclock[110]: Tue May 12 18:17:01 UTC 2020
May 12 20:53:52 pie systemd-fsck[129]: e2fsck 1.44.5 (15-Dec-2018)
May 12 20:53:52 pie fake-hwclock[110]: Tue May 12 18:17:01 UTC 2020
May 12 20:53:52 pie systemd-fsck[129]: e2fsck 1.44.5 (15-Dec-2018)
May 12 20:53:52 pie systemd[1]: Started Set the console keyboard layout.
May 12 20:53:52 pie systemd[1]: Started udev Coldplug all Devices.
May 12 20:53:52 pie systemd[1]: Starting Helper to synchronize boot up for ifupdown...
May 12 20:53:52 pie systemd[1]: Started Helper to synchronize boot up for ifupdown.
May 12 20:53:52 pie systemd-fsck[129]: rootfs: clean, 123935/28436352 files, 2873219/117146326 blocks
May 12 20:53:52 pie systemd[1]: Started File System Check on Root Device.
May 12 20:53:52 pie systemd[1]: Starting Remount Root and Kernel File Systems...
May 12 20:53:52 pie systemd[1]: Started Remount Root and Kernel File Systems.
May 12 20:53:52 pie systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped.
May 12 20:53:52 pie systemd[1]: Starting Flush Journal to Persistent Storage...
May 12 20:53:52 pie systemd[1]: Starting Create System Users...
May 12 20:53:52 pie systemd[1]: Starting Load/Save Random Seed...
May 12 20:53:52 pie systemd[1]: Started Load/Save Random Seed.
May 12 20:53:52 pie systemd[1]: Started Create System Users.
May 12 20:53:52 pie systemd[1]: Starting Create Static Device Nodes in /dev...
May 12 20:53:52 pie systemd[1]: Started Flush Journal to Persistent Storage.
May 12 20:53:52 pie systemd[1]: Started Create Static Device Nodes in /dev.
May 12 20:53:52 pie systemd[1]: Starting udev Kernel Device Manager...
May 12 20:53:52 pie systemd[1]: Reached target Local File Systems (Pre).
May 12 20:53:52 pie systemd[1]: Started udev Kernel Device Manager.
May 12 20:53:52 pie systemd[1]: Starting Show Plymouth Boot Screen...
May 12 20:53:52 pie systemd[1]: Received SIGRTMIN+20 from PID 156 (plymouthd).
May 12 20:53:52 pie systemd[1]: Started Show Plymouth Boot Screen.
May 12 20:53:52 pie systemd[1]: Started Forward Password Requests to Plymouth Directory Watch.
May 12 20:53:52 pie systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
May 12 20:53:52 pie kernel: [ 0.000000] Booting Linux on physical CPU 0x0
May 12 20:53:52 pie systemd[1]: Reached target Local Encrypted Volumes.
May 12 20:53:52 pie kernel: [ 0.000000] Linux version 4.19.97-v7l+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1294 SMP Thu Jan 30 13:21:14 GMT 2020
时间戳 21:15:49 适合安装，smem但我不确定“插入模块”的含义。这就是该行的实际外观 - 不是复制错误。没有LF。
至少我现在知道如何重现。我目前正在等待我的交换再次升温。
这是在具有最新 Raspbian 的 Pi 4 上看到的：
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
[23:38:00] pi@pie:/mnt/piedisk $ uname -a
Linux pie 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux
我关于应该有足够的可用内存的说法正确吗？还是我误解了free 输出中缓冲区/缓存行的含义？我可以合理地声称系统在不应该使用交换的情况下使用了交换吗？
更新1：我需要教育自己slabtop以及那里发生的事情。我在任何崩溃中仍然没有看到 OOM 杀手的踪迹。我打算运行更多测试以便能够正确重现，因为即使使用 100M 的小交换也需要很长时间。我打算将交换减少到 0、1M 和 10M，看看是否可以引发错误。