Nutzung von Swap steigt an obwohl noch jede Menge RAM frei ist

[Annika Hansen]

Ich habe eine DS1522+ mit 16 GB RAM im Einsatz. Das System rennt so wie es soll, es gibt jedoch eine Sache, die ich nicht verstehe:

Nach einem Reboot ist die Speicherauslastung (also RAM used) bei ca. 10-15% und verbleibt auch in diesem Bereich. Swap used ist dann erwartungsgemäß bei 0%. Und dann, ohne dass ich Last auf dem System habe/erzeuge steigt auf einmal Swap used auf 0,1%, ein paar Minuten später auf 0,2%, dann auf 0,3% usw. geht es stetig weiter bis nach ein paar Tagen Swap used bei knapp unter 10% ist. Alle Prozentangaben sehe ich so in Grafana. Die Leistung des Systems wird in keiner Weise beeinträchtigt, aber ich verstehe nicht, warum Swap used langsam aber stetig ansteigt obwohl noch jede Menge RAM ungenutzt ist und vor allem wer der "Übeltäter" ist. Wie gesagt, das ist bisher kein echtes Problem, ich würde es nur gerne verstehen.

Irgendwelche Ideen, wie ich das herausfinden kann?

 

[Benie]

Falls due Speicherkomprimierung noch aktiviert ist, nimm mal da den Haken raus. Erfordert Neustsrt der DS, und beobachte ob das etwas gebracht hat.

 

[Annika Hansen]

Aaaaaahh - danke für den Hinweis, das macht Sinn. Die Speicherkomprimierung ist natürlich aktiviert. Ich habe die jetzt deaktiviert und warte bis ich heute Nacht einen Reboot machen kann (das ist im Moment nicht möglich).

 

[Benares]

Mmh, eine schnelle Google-Suche liefert mir da sowas. Was sagt denn cat /proc/meminfo bzw. "top" bei der Filterung auf "SWAP"?

 

[Annika Hansen]

Danke @Benares - guter Hinweis, auf die Idee SWAP mit top anzeigen zu lassen bin ich einfach nicht gekommen.

Also wenn ich top nach SWAP Usage sortiere, dann erhalte ich folgendes:

Spoiler: top -o SWAP

  PID USER      PR  NI    VIRT    RES  %CPU  %MEM     TIME+ S COMMAND                                                         SWAP
17385 root      20   0  269.5m  32.5m 0.000 0.203   0:00.81 S /var/packages/SynoFinder/target/sbin/synoelasticd               6.0m
20810 root      20   0  200.0m  16.9m 0.000 0.106   0:03.33 S /var/packages/SynologyDrive/target/sbin/syncd                   5.1m
20753 root      30  10  179.7m  17.1m 0.000 0.107   0:09.58 S /var/packages/SynologyDrive/target/sbin/syno-cloud-clientd      4.4m
21868 root      20   0  370.7m   9.3m 0.000 0.058   0:00.07 S /var/packages/SynologyPhotos/target/usr/sbin/synofoto-task-c+   4.3m
20770 root      35  15   85.7m   5.4m 0.000 0.034   0:00.13 S /var/packages/SynologyDrive/target/sbin/cloud-vmtouchd          4.2m
20971 root      20   0  154.4m  19.1m 0.000 0.119   0:03.42 S /var/packages/SynologyDrive/target/sbin/syncd                   3.9m
21521 root      25   5  147.9m   3.4m 0.000 0.021   0:00.00 S /var/packages/SynologyPhotos/target/usr/sbin/synofoto-check-+   3.6m
21557 root      15  -5   80.4m   2.6m 0.000 0.016   0:00.00 S /var/packages/SynologyPhotos/target/usr/sbin/synofoto-thumbn+   3.4m
20752 root      20   0   68.7m   2.7m 0.000 0.017   0:00.05 S /var/packages/SynologyDrive/target/sbin/cloud-authd             3.4m
16071 root      20   0 1471.7m  13.9m 0.000 0.087   0:06.15 S containerd --config /var/run/docker/containerd/containerd.to+   3.4m
20751 root      30  10  553.2m  16.6m 0.000 0.104   0:08.81 S /var/packages/SynologyDrive/target/sbin/cloud-workerd           3.3m
21131 root      20   0   87.7m   5.3m 0.000 0.033   0:00.35 S synoscgi                                                    +   3.2m
20807 root      20   0   89.3m  16.5m 0.000 0.103   0:03.83 S /var/packages/SynologyDrive/target/sbin/syncd                   3.2m
17692 root      20   0   88.8m  25.4m 0.658 0.159   0:00.74 S synoscgi                                                    +   2.8m
17691 root      20   0   88.8m  25.4m 0.000 0.159   0:00.74 S synoscgi                                                    +   2.8m
21589 root      20   0  169.7m   7.5m 0.000 0.047   0:00.00 S /var/packages/SynologyPhotos/target/usr/sbin/synofoto-bg-jobd   2.3m
18080 root      20   0  647.3m   8.2m 0.000 0.051   0:00.01 S /var/packages/SynoFinder/target/sbin/fileindexd                 2.3m
21556 root      15  -5  121.6m   7.9m 0.000 0.049   0:00.00 S /var/packages/SynologyPhotos/target/usr/sbin/synofoto-check-+   2.1m
21563 postgres  20   0  648.6m  10.3m 0.000 0.065   0:00.00 S postgres: SynologyPhotos synofoto [local] idle                  1.3m
15372 root      20   0 2410.1m  40.6m 0.658 0.254   0:37.77 S /var/packages/ContainerManager/target/usr/bin/dockerd --conf+   1.3m
21430 postgres  20   0  649.5m  12.4m 0.000 0.077   0:00.10 S postgres: SynologyPhotos synofoto [local] idle                  1.2m
21524 postgres  20   0  649.2m  11.2m 0.000 0.070   0:00.00 S postgres: SynologyPhotos synofoto [local] idle                  1.0m
21331 Synolog+  20   0    8.7m   4.1m 0.000 0.026   0:00.90 S /var/packages/SynologyPhotos/target/daemon/pgbouncer -q /var+   0.9m
17677 postgres  20   0  648.6m   9.9m 0.000 0.062   0:00.01 S postgres: postgres synoindex [local] idle                       0.9m
  995 grafana   20   0 1713.6m 107.5m 0.000 0.673   0:18.08 S grafana server --homepath=/usr/share/grafana --config=/etc/g+   0.8m
20756 root      20   0   46.0m   3.3m 0.000 0.021   0:11.72 S /var/packages/SynologyDrive/target/usr/bin/redis-server unix+   0.5m

Und hier noch die Ausgabe der Speicherverwendung:

Spoiler: cat /proc/meminfo

#syno# [root@ds1522:/volume1/docker/monitoring]$ cat /proc/meminfo
MemTotal:       16351532 kB
MemFree:          163200 kB
MemAvailable:   14720552 kB
Buffers:           25196 kB
Cached:         14702052 kB
SwapCached:         1472 kB
Active:           803876 kB
Inactive:       14582696 kB
Active(anon):     315184 kB
Inactive(anon):   449212 kB
Active(file):     488692 kB
Inactive(file): 14133484 kB
Unevictable:        1528 kB
Mlocked:            1528 kB
SwapTotal:      11909044 kB
SwapFree:       11798660 kB
Dirty:             26800 kB
Writeback:       1727988 kB
AnonPages:        660248 kB
Mapped:           352028 kB
Shmem:            103568 kB
Slab:             517616 kB
SReclaimable:     264120 kB
SUnreclaim:       253496 kB
KernelStack:       16288 kB
PageTables:        22600 kB
NFS_Unstable:    1058900 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    20084808 kB
Committed_AS:    4874976 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
DirectMap4k:       17940 kB
DirectMap2M:     3065856 kB
DirectMap1G:    13631488 kB

 

[Benares]

Puh, schwer zu sagen. Ich bin da leider auch kein Spezialist

 

[ctrlaltdelete]

Mein SWAP füllt sich auch mit der Zeit, es ist aber kein aktives Swapping zu beobachten (DS920+ mit 20 GB RAM)
Edit: Screenshot Ressourcenmonitor

 

[Ulfhednir]

synoelasticd klingt nach elastic search aká Synology Universal Search. Läuft das zufälligerweise? Was ist dort in den Einstellungen?

 

[Annika Hansen]

Falls due Speicherkomprimierung noch aktiviert ist, nimm mal da den Haken raus. Erfordert Neustsrt der DS, und beobachte ob das etwas gebracht hat.

Ich habe die Speicherkomprimierung deaktiviert und heute Nacht wurde die Diskstation wie geplant rebootet. Das hat leider nichts geholfen, denn die Auslastung des Swap ist bereits wieder bei 1.7% bei 10.7% RAM Usage. In Grafana sehe ich, dass es seit dem Reboot keinen Peak in der RAM Usage gab, also fällt ein kurzzeitiger Engpass beim verfübaren RAM als Grund aus.

Nachtrag: Durch das Deaktivieren wurde übrigens die Größe des Swap auf 2 GB reduziert ... ist mir eben erst aufgefallen.

synoelasticd klingt nach elastic search aká Synology Universal Search. Läuft das zufälligerweise? Was ist dort in den Einstellungen?

Ja, Synology Universal Search läuft auf der Diskstation. Hier die Einstellungen

• Indizierte Ordner sind: Synology Drive und Drive Team Folder.
• Suchverlauf aktivieren unter Allgemein ist deaktiviert.
• Unter System sind aktiviert
  • Überspringen Sie numerische Zeichen bei der Indexierung von Dateninhalt.
  • Indexdaten für beschleunigte Suche nache einer Systemaktualisierung oder einem Neustast vorabladen.

Bei top -o SWAP sehe ich aber auch andere Prozesse wie z.B. /usr/bin/syslog, ContainerManager, SynologyPhotos und grafana server, die Swap "(ver)brauchen". Also kann es meines Erachtens nicht an Universal Search liegen.

 

[Kaiser Wilhelm]

Du kannst dir im Ressourcen-Monitor den Swap anzeigen lassen. Vielleicht findest du zu den dort eingetragenen Zeiten einen Zusammenhang mit anderen Programmen (Sicherungen, Drive, VM,etc) und kannst das ganze eingrenzen.
Bei mir sind es bei 20GB RAM und einer Laufzeit von 25 Tagen auch bereits 9%. Die Peaks kann ich leider nicht mit einer VM oder sonstigen Tätigkeiten in Zusammenhang bringen. Aber man kann so wenigstens die Zeiten etwas einengen.

Spoiler: Ressoucen-Monitor-Swap-Übersicht-monatlich

 

[ctrlaltdelete]

Das Auslagern mit einer Geschwindigkeit von 60 kB/s ist doch marginal, also ehr Null. Die SWAP Datei ist da, wird aber nicht aktiv genutzt, sonst wäre da ja viel mehr Traffic oder verstehe die Anzeige falsch?

 

[Kaiser Wilhelm]

@ctrlaltdelete So sehe ich das auch, dennoch geht es in diesem Thread ja um eher kleine kontinuierliche Peaks

 

[Benares]

Also meine DS1522+ swapped überhaupt nicht mit ihren 40GB RAM (26 Tage Laufzeit). Hier wird geschrieben, dass es es völlig normal sei, wenn auch bei genügend RAM geswappt wird. Hängt vielleicht auch von der verfügbaren Reserve ab. Ich würde mir da keinen Kopf drum machen, wenn im Ressourcen-Monitor bei Swap In/Out nicht ständig was steht.

 

[Annika Hansen]

Jetzt hat meine DS1522+ nach 2,5h Uptime 14.5% von 2 GB Swap verbraucht. In der Mittagspause werde ich sie gleich nochmal rebooten, aber vorher wieder die Speicherkomprimierung aktivieren, da dies nichts gebracht hat außer einer Reduzierung des Swap Spaces.

Sagen wir es mal so: ich kenne es halt aus der Firma von den vielen Red Hat Servern, auf die ich Zugriff habe, anders. Aber RHEL ist nicht Synology und ich werde mir keine Gedanken mehr machen, solange das System ohne Einschränkungen und Performanceeinbußen stabil läuft. Es hat mich halt nur gewundert, weil ich keinen echten Grund für die dauerhafte Nutzung des Swaps sehe.

 

[ctrlaltdelete]

Die Speicherkomprimierung würde ich abgeschaltet lassen.

 

[Annika Hansen]

Warum?

 

[Kaiser Wilhelm]

Weil 16GB mehr als aureichend für den normalen Betrieb sind und die CPU sonst unnötig arbeitet. Damit im Speicher etwas, dass gerade nicht gebraucht wird, komprimiert werden muss.

 

[ctrlaltdelete]

Nachteil: unnötige CPU-Last durchs Komprimieren/Entpacken.
Bei genügend RAM unnötig.

 

[Annika Hansen]

So sieht es in Grafana nach 2h46m uptime aus (sorry für die verblassten Farben beim Screenshot):

Für mich sind 15.4% Swap Nutzung nach so kurzer Laufzeit nicht normal.

 

[ctrlaltdelete]

Interpretation:​

• Dein System nutzt Swap als „Parkplatz“ für selten genutztes Zeug, aber nicht kritisch → kein Hinweis auf RAM-Notstand.
• Dass 2 GB Swap „voll“ sind, ist normal – Linux füllt das gerne einmalig, um RAM freizumachen.
• Wichtig: erst wenn „Swap in/out“ dauerhaft Bewegung zeigt, läuft’s in echten Speicherdruck.