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.
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“)
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.
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.
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.
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
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: https://paste.debian.net/1168348/)
Auch wenn einem auf der Konsole kurz die Zweifel kommen mögen.
