Zram-swap für ar71xx-tiny / 32/4 Geräte

Moin,

ich möchte mit zram auch für 32/4 Geräte experimentieren.

Aktuell habe ich einfach zram-swap in der site.mk unter GLUON_SITE_PACKAGES eingefügt. Das bewirkt natürlich das es für alle targets aktiv ist.

Kann man das eleganter lösen ohne es für jedes Gerät einzeln aufzulisten?

Wie kann ich die Funktion von zram auf den Node testen?
Gibt es schon Erfahrungswerte bzgl. CPU Last, Performanceauswirkung etc?

Das der freie flash dadurch kleiner wird ist mir klar und das nehme ich in Kauf.

Danke euch!

Querverweis zu GH:
https://github.com/freifunk-gluon/gluon/issues/1692

1 Like

site.mk:

ifeq ($(GLUON_TARGET),ar71xx-tiny)
	GLUON_SITE_PACKAGES += zram-swap
endif

(Ja, gibt da gewisse Unschärfen bei 8/32- und 4/64-Geräten. Wer die benennen kann: Gern melden.)

2 Likes

Knoten:

dmesg|grep -i zr
[   13.782767] zram: Added device: zram0
[   23.615885] zram0: detected capacity change from 0 to 13631488
[   23.670609] Adding 13308k swap on /dev/zram0.  Priority:-1 extents:1 across:13308k SS

Vergleich:

cat /proc/meminfo
MemTotal:          27692 kB
MemFree:            2012 kB
MemAvailable:       8780 kB
Buffers:            1800 kB
Cached:             4200 kB
SwapCached:            0 kB
Active:             5364 kB
Inactive:           2912 kB
Active(anon):       1124 kB
Inactive(anon):     1216 kB
Active(file):       4240 kB
Inactive(file):     1696 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:         13308 kB
SwapFree:          13248 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          2284 kB
Mapped:             1820 kB
Shmem:                64 kB
Slab:               9768 kB
SReclaimable:       4928 kB
SUnreclaim:         4840 kB
KernelStack:         432 kB
PageTables:          340 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:       27152 kB
Committed_AS:       5848 kB
VmallocTotal:    1048372 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
cat /proc/meminfo
MemTotal:          27692 kB
MemFree:            1412 kB
MemAvailable:       7420 kB
Buffers:            1832 kB
Cached:             6352 kB
SwapCached:            0 kB
Active:             7668 kB
Inactive:           3112 kB
Active(anon):       2664 kB
Inactive(anon):       40 kB
Active(file):       5004 kB
Inactive(file):     3072 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          2604 kB
Mapped:             2036 kB
Shmem:               108 kB
Slab:               6300 kB
SReclaimable:       1492 kB
SUnreclaim:         4808 kB
KernelStack:         464 kB
PageTables:          380 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:       13844 kB
Committed_AS:       6428 kB
VmallocTotal:    1048372 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB

Ersparnis: 1360K

Gemessen wird ohne Mesh Partner mit einem Client via LAN angeschlossen.

Ich habe nun mal das o.g. GH issue durchgearbeitet und da kam man ja zu dem Ergebnis:

Man will zram weil:

  • mehr freier RAM
  • höhere load durch RAM Kompression ist im Grunde nicht vorhanden eher im Gegenteil, da deutlich weniger flash Zugriffe die Load sogar stark senken
  • eigentlich will man das auch für 32/4 Geräte haben, aber man scheut sich dadurch das Image zu vergrößern
  • Mit ZRAM lassen sich OOM reboots in großen Domänen vermindern, das löst das Problem zwar nicht zögert es aber deutlich hinaus

Hab ich was vergessen? Eure Meinungen?

9 Likes

Hört sich für mich als Laie erst Mal interessant an…
…aber wie verhält sich das ganze im Produktiv Betrieb?
Wie weit werden OOM reboots hinausgezögert…?

Nach meinem Gefühl: Die Geräte geraten früher/häufiger unter Load.
Diese bleibt aber dann im Bereich von 1-2 (was bei einem singlecore trotzdem nicht toll ist).
D.h. die Load geht nicht gleich auf 5/10/20 durch die Decke und dann folgende panic-reboot bleibt aus.

Die Load ist häufig hoch, aber die Plasterouter booten seltener durch.

2 Likes

8 Beiträge wurden in ein existierendes Thema verschoben: Gluon auf 4MB Flash Geräten - Wird es bald eng?

Um den alten Thread auszugraben:

mag hier jemand einen 841er (präziser: ar71xx-tiny) unter gluon 2020.2.x mal den output pasten von

logread |grep zram 

Warum?

ich leide hier unter frequent reboots, weil offensichtlich zram „halb“ installiert ist.

Sat Oct 24 14:40:56 2020 kern.info kernel: [   12.675426] zram: Added device: zram0
Sat Oct 24 14:40:56 2020 daemon.notice procd: /etc/rc.d/S15zram: sh: 0: unknown operand
Sat Oct 24 14:40:57 2020 daemon.debug zram_start: activating '/dev/zram0' for swapping (13 MegaBytes)
Sat Oct 24 14:40:57 2020 daemon.notice procd: /etc/rc.d/S15zram: zram_start: activating '/dev/zram0' for swapping (13 MegaBytes)
Sat Oct 24 14:40:57 2020 daemon.debug zram_reset: enforcing defaults via /sys/block/zram0/reset
Sat Oct 24 14:40:57 2020 daemon.notice procd: /etc/rc.d/S15zram: zram_reset: enforcing defaults via /sys/block/zram0/reset
Sat Oct 24 14:40:57 2020 kern.info kernel: [   46.151663] zram0: detected capacity change from 0 to 13631488
Sat Oct 24 14:40:57 2020 daemon.notice procd: /etc/rc.d/S15zram: Setting up swapspace version 1, size = 13627392 bytes
Sat Oct 24 14:40:57 2020 daemon.notice procd: /etc/rc.d/S15zram: swapon: /dev/zram0: Function not implemented

Aber auch das Auskommentieren des „zram-swap“ aus der site.mk änderte nichts.
(Dann blieb es zu meinem Erstaunen drin, trotz diverser „git reset --hard“)

TP-Link TL-WR841N/ND v9 mit Gluon v2020.2.1:
~# logread | grep zram

Fri Oct 16 19:12:27 2020 kern.info kernel: [ 10.395391] zram: Added device: zram0
Fri Oct 16 19:12:27 2020 daemon.debug zram_start: activating '/dev/zram0' for swapping (13 MegaBytes)
Fri Oct 16 19:12:27 2020 daemon.notice procd: /etc/rc.d/S15zram: zram_start: activating '/dev/zram0' for swapping (13 MegaBytes)
Fri Oct 16 19:12:27 2020 daemon.debug zram_reset: enforcing defaults via /sys/block/zram0/reset
Fri Oct 16 19:12:27 2020 daemon.notice procd: /etc/rc.d/S15zram: zram_reset: enforcing defaults via /sys/block/zram0/reset
Fri Oct 16 19:12:27 2020 kern.info kernel: [ 14.609715] zram0: detected capacity change from 0 to 13631488
Fri Oct 16 19:12:27 2020 daemon.notice procd: /etc/rc.d/S15zram: Setting up swapspace version 1, size = 13627392 bytes
Fri Oct 16 19:12:27 2020 daemon.notice procd: /etc/rc.d/S15zram: swapon: /dev/zram0: Function not implemented

Danke.
Und ist zram bei Dir in der site.mk aktiviert? Oder wolltest Du es aktivieren?
(will sagen: Egal was ich einstelle, bei mir taucht im log immer auf, dass es versucht wird zu aktivieren, dafür auch Speicher alloziert wird, dann aber Abbruch mit

swapon: /dev/zram0: Function not implemented

Und dann liegen (nach meiner Interpretation) 13M RAM ungenutzt im Weg herum, was dann extrem schnell zu OOM-Reboots führt.

Ja, es ist in der site.mk drin.

swapon: /dev/zram0: Function not implemented

Den Abbruch habe ich ja auch drin :frowning:

Wenn ich mir die Ausgabe von cat /proc/meminfo ansehe, dann sieht das nicht gut aus:

...
SwapTotal:             0 kB
SwapFree:              0 kB
...

drüben bei github hiess es, es könne ein Issue von Busybox sein.
Mir ist jedoch unklar,
a) was angeschaltet werden muss
b) wo man das sinnvollerweise tut, um nicht in gluon/openwrt/bin an den config-files herumzupatchen während des Builds.

Ich hätte ehrlich gesagt dort gesucht, aber nichts dazu gefunden, was mir passend erscheint.

Ich habe mal unter Gluon v2020.2.1 den folgenden Patch im OpenWrt-Verzeichnis angewendet:

diff --git a/config/Config-kernel.in b/config/Config-kernel.in
index 87053b7f23..ab34ffb67a 100644
--- a/config/Config-kernel.in
+++ b/config/Config-kernel.in
@@ -33,7 +33,7 @@ config KERNEL_CRASHLOG
 
 config KERNEL_SWAP
        bool "Support for paging of anonymous memory (swap)"
-       default y if !SMALL_FLASH
+       default y
 
 config KERNEL_DEBUG_FS
        bool "Compile the kernel with debug filesystem enabled"

Die Ausgabe von 'logread | grep zram' sieht jetzt so aus:

Fri Feb 22 22:48:23 2019 kern.info kernel: [   13.895554] zram: Added device: zram0
Fri Feb 22 22:48:23 2019 daemon.debug zram_start: activating '/dev/zram0' for swapping (13 MegaBytes)
Fri Feb 22 22:48:23 2019 daemon.notice procd: /etc/rc.d/S15zram: zram_start: activating '/dev/zram0' for swapping (13 MegaBytes)
Fri Feb 22 22:48:23 2019 daemon.debug zram_reset: enforcing defaults via /sys/block/zram0/reset
Fri Feb 22 22:48:23 2019 daemon.notice procd: /etc/rc.d/S15zram: zram_reset: enforcing defaults via /sys/block/zram0/reset
Fri Feb 22 22:48:23 2019 kern.info kernel: [   23.962029] zram0: detected capacity change from 0 to 13631488
Fri Feb 22 22:48:23 2019 daemon.notice procd: /etc/rc.d/S15zram: Setting up swapspace version 1, size = 13627392 bytes
Fri Feb 22 22:48:23 2019 kern.info kernel: [   23.981942] Adding 13308k swap on /dev/zram0.  Priority:-2 extents:1 across:13308k SS

Die Ausgabe von 'free' sieht nun so aus:

              total        used        free      shared  buff/cache   available
Mem:          27704       15148        3404         136        9152       10424
Swap:         13308           0       13308

EDIT:
Der OpenWrt-Patch basiert auf Infos aus

und

tja… es scheint damit zu knapp zu werden für die Buffer.

Dann ist damit wohl das Ende der Fahnenstange erreicht und überschritten.

Verständnisfrage: zram-swap nimmt – vom ohnehin knappen – RAM etwas weg, um eine komprimierte SWAP-Partition dorthin zu legen — klaut also Arbeitsspeicher, um knappen Arbeitsspeicher zu kompensieren? Das klingt arg nach Münchhausen (an den eigenen Haaren aus dem Sumpf ziehen) — kann das auf 32 MByte-RAM-Geräten überhaupt theoretisch sinnvoll sein‽

ja! Wenn dort Dinge komprimiert herausgeswapt werden, die in einigen Routern kaum genutzt werden (z.B. den Webserver für die Statusseite).
Die Kompressionswerte die man angezeigt bekommt bei Aufruf von

/etc/init.d/zram status

liegen so im Bereich von 1:3 bis 1:4

aber: die Berechenung der Swapsize(MB): die ist mit „mem(kb)/2048“ das Problem:
Wenn man dem Router nach dem Start erstmal 10-15 Minuten Ruhe „gönnt“ bevor die ersten Clients Traffic machen: Alles gut, dann sind schon sachen rausgeswapt.
Wenn man jedoch sofort loslegt, dann gibt es obige Situation.

Berechnung geht im Source folgt:

zram_getsize()	# in megabytes
{
	local zram_size="$( uci -q get system.@system[0].zram_size_mb )"
	local ram_size="$( ram_getsize )"

	if [ -z "$zram_size" ]; then
		# e.g. 6mb for 16mb-routers or 61mb for 128mb-routers
		echo $(( ram_size / 2048 ))
	else
		echo "$zram_size"
	fi
}

und da habe ich jetzt kurzerhand mal ein " + 5" in die Klammer mit hineingetan.
Das ist ein empirisch ermittelter Wert, z.B.

uci set system.@system[0].zram_size_mb='8'; uci commit; reboot

Tests are not yet completed.

Ich bin alt(modisch). Speicher kann man nicht vergrößern, indem man ihn verkleinert. Zumal die CPU bei 4/32 typisch ein weiteres Nadelöhr ist. Heißt also, sobald von außen auf die Statuspage geschaut wird, gibt’s doppelt Streß, denn der ausgelagerte Speicher wird angesprochen, was ja nun etwas dauert? Fragwürdiges Konzept?

Bei l2tp statt fastd hat die CPU kaum noch was zu tun, da bräuchte es keine 700MHz, die 400MHz einer Nanostation würden auch reichen…
Auf Servern mit vielen geforkten und dann „punktuell aktivierten“ Prozessen (dovecot, viele idelnde User) hat sich zram als rechter Problemlöser erwiesen.
Ob es bei Gluon etwas bringt, habe ich in er Tat meine Zweifel.

immerhin funktionieren FW-Updates jetzt wieder „im ersten Anlauf“ und nicht nur bei x-ten Versuch (oder ausschließlich im Configmode. Bei Versuchen aus „laufendem Betrieb“ sah das dann so aus: debian Pastezone)

Auch wenn einem auf der Konsole kurz die Zweifel kommen mögen.

P.S.: Wer testen möchte, Testimages liegen in Freifunk Düsseldorf Flingern Firmware Seite

1 Like