スワップがゆっくり増加しており、使用可能なメモリは80%です。

スワップがゆっくり増加しており、使用可能なメモリは80%です。

これはほとんど言葉ではありません。だから一度試してみましょう。

利用可能なメモリが十分にあるはずです。それとも私が誤解したのですか?自由出力におけるバッファ/キャッシュラインの意味?システムがスワップを使用してはいけませんが、スワップを使用すると合理的に主張できますか?

考える私のシステムが死んでいます。しかし、まだ利用可能なメモリが十分です。誰でも私がこれを理解するのを助けることができますか?それともこれが問題ではないことを証明するのに役立ちます。

私はそれをデバッグするのにかなりの時間を費やしましたが、表示することはほとんどありません。確立されたSSHセッションは引き続き実行されますが、新しいセッションを作成することはできません。システムはICMP ECHO(ping)で応答します。

リソースの問題のように聞こえますが、私の毎日のドライバはFreeBSDなので、正しい場所を探しているのかわかりません。このようなことが最初に見られたのは、長期実行ジョブrsync(テラバイト単位のデータ)でした。

システムには4GBのメモリがあります。全体的に約3400MiBの空きメモリがあると聞きました。バフ/キャッシュがいっぱいです。これは、ファイルアクティビティが多い場合の通常の現象です。しかし、システムが交換するのではなく、ファイルシステムキャッシュの一部を空にしたい!

交換性のデフォルト値をそのままにします。

$ cat /proc/sys/vm/swappiness
60

経験上、私はスワップスペースを好む。これまで、私はスワップファイルを100MBに保つことを選びました。何かが起こっていると思うからです。ファイルを交換した後に4 GBまたは8 GBのスペースを追加すると、問題が解決する可能性があります。しかし、私はこのシステムがスワップを実行したくないので、何が起こっているのか理解したいと思います。

次の事項を過度に約束しません。

$ 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 接続が切断されます。ボックスにpingを送信できますが、どのサービスにもアクセスできません。

システムが不足している場合は、ログに役立つものを書くことができるかどうかはわかりません。少なくとも私は/var/log/messages何も見つかりません/var/log/kern.log

少し面白いアイテムが1つしかありません。/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に減らしてエラーが発生するかどうかを見てみましょう。

ベストアンサー1

おすすめ記事