이것은 거의 말이 되지 않습니다. 그러니 한번 시도해 보겠습니다.
사용 가능한 메모리가 충분해야 한다는 말이 맞나요? 아니면 제가 오해한건가요자유 출력에서 버퍼/캐시 라인의 의미? 시스템이 스왑을 사용해서는 안 되는데도 스왑을 사용한다고 합리적으로 주장할 수 있습니까?
나생각하다내 시스템이 죽어가고 있어요. 그러나 여전히 사용 가능한 메모리가 충분합니다. 누구든지 내가 이것을 이해하도록 도와줄 수 있나요? 아니면 이것이 문제가 아니라는 것을 증명하도록 도와주세요.
나는 그것을 디버깅하는 데 꽤 많은 시간을 보냈지만 보여줄 것이 거의 없습니다. 설정된 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만 입력하면 됩니다. systemd
rsync 대신 스왑 처럼 보입니까 ?
동시에 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로 줄여서 오류가 발생하는지 살펴보겠습니다.