스왑이 천천히 증가하고 있으며 사용 가능한 메모리는 80%입니다.

스왑이 천천히 증가하고 있으며 사용 가능한 메모리는 80%입니다.

이것은 거의 말이 되지 않습니다. 그러니 한번 시도해 보겠습니다.

사용 가능한 메모리가 충분해야 한다는 말이 맞나요? 아니면 제가 오해한건가요자유 출력에서 ​​버퍼/캐시 라인의 의미? 시스템이 스왑을 사용해서는 안 되는데도 스왑을 사용한다고 합리적으로 주장할 수 있습니까?

생각하다내 시스템이 죽어가고 있어요. 그러나 여전히 사용 가능한 메모리가 충분합니다. 누구든지 내가 이것을 이해하도록 도와줄 수 있나요? 아니면 이것이 문제가 아니라는 것을 증명하도록 도와주세요.

나는 그것을 디버깅하는 데 꽤 많은 시간을 보냈지만 보여줄 것이 거의 없습니다. 설정된 SSH 세션은 계속 실행되지만 새 세션을 생성할 수는 없습니다. 시스템은 ICMP ECHO(ping)로 응답합니다.

리소스 문제처럼 들리지만 내 일일 드라이버는 FreeBSD이므로 올바른 위치를 찾고 있는지 잘 모르겠습니다. 이런 일이 발생하는 것을 처음 본 것은 장기 실행 rsync작업(테라바이트 단위의 데이터)에서였습니다.

시스템에는 4GB의 메모리가 있습니다. 전체적으로 약 3400MiB의 여유 메모리가 있다고 들었습니다. 버프/캐시가 꽉 찼네요. 이는 파일 활동이 많은 경우 정상적인 현상입니다. 하지만 시스템이 교체하는 대신 파일 시스템 캐시의 일부를 비우기를 원합니다!

교환성 기본값을 그대로 둡니다.

$ cat /proc/sys/vm/swappiness
60

경험상 나는 스왑 공간을 선호합니다. 지금까지 나는 스왑 파일을 100MB로 유지하기로 선택했습니다. 뭔가 일이 일어나고 있다고 생각하기 때문입니다. 파일을 교체한 후 4GB 또는 8GB의 공간을 추가하면 문제가 해결될 수 있습니다. 하지만 저는 이 시스템이 스와핑을 수행하는 것을 원하지 않기 때문에 무슨 일이 일어나고 있는지 이해하고 싶습니다.

우리는 다음 사항을 과도하게 약속하지 않습니다.

$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0

꽤 많은 디버깅 끝에 아주 작은 프로세스 세트를 실행하게 되었습니다. 그런 다음 cifs 마운트에서 16396개의 파일을 포함하고 크기가 3.2TB인 로컬 디스크로 rsync 복사를 시작했습니다. 이것이 내가 보는 것입니다:

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.3MB입니다. 그런 다음 약 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

따라서 3.2TB의 16396개 파일을 보면 이것이 디스크 문제도 아니고 rsync의 (직접) 메모리 누수도 아니라는 결론을 내릴 수 있습니다.

이제 rsync를 실행할 때 이것이 시스템 문제인 것으로 의심됩니다. 내 일반적인 가정은 메모리를 사용할 수 있으면 파일 캐시 사용량이 증가한다는 것입니다. 그러나 나는 또한 교체하기 전에 해당 메모리를 해제하고 싶습니다. 이에 대한 최저 수위가 있을 수 있지만 아직 해당 수준 근처에는 도달하지 못했습니다.

아무 일도 일어나지 않았으므로 이전 복사본의 530GB/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만 입력하면 됩니다. systemdrsync 대신 스왑 처럼 보입니까 ?

동시에 logitechmediaserver상자에서 실행되는 연결이 끊어졌습니다. rsync의 진행 상황을 표시하기 위해 tmux를 사용하여 또 다른 SSH 세션을 실행했습니다. rsync는 매력처럼 작동합니다. tmux에서 새 창을 만들 수 없습니다. 세션에서 분리하면 SSH 연결이 끊어집니다. 상자에 핑을 보낼 수는 있지만 어떤 서비스에도 접속할 수 없습니다.

시스템이 부족하다면 로그에 유용한 내용을 쓸 수 있을지 확신할 수 없습니다. 적어도 나는 /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

사용 가능한 메모리가 충분해야 한다는 말이 맞나요? 아니면 제가 오해한건가요자유 출력에서 ​​버퍼/캐시 라인의 의미? 시스템이 스왑을 사용해서는 안 되는데도 스왑을 사용한다고 합리적으로 주장할 수 있습니까?

업데이트 1:나 자신과 그곳에서 무슨 일이 일어났는지 교육해야 합니다 slabtop. 충돌이 발생하더라도 OOM 킬러의 흔적은 여전히 ​​보이지 않습니다. 100M의 작은 스왑으로도 시간이 오래 걸리기 때문에 올바르게 재현할 수 있도록 더 많은 테스트를 실행할 계획입니다. 스왑을 0, 1M, 10M로 줄여서 오류가 발생하는지 살펴보겠습니다.

관련 정보