oom-killer macht keinen reboot - limit für oom-killer nicht optimal #131
Labels
No Label
RFC
RFT
WIP
blocked
bsp
bug
build/scripts/tools
duplicate
feature
fixed
layer3
mantis
more details required
needs changes
node
packages/fff
rejected
security
trivial
upstream
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: freifunk-franken/firmware#131
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Der oom-killer sollte das System komplett rebooten, sonst bleibt ein node kaputt online und kann eventuell je nach dem welcher service vom oom-killer erwischt wurde nicht mehr remote verwaltet werden.
Weiterhin ist das limit nicht optimal gesetzt, auf einem tl-wr1043n-v4 waren noch etwas unter 8MB frei (Normal free:7924kB min:8192kB), aber der oom-killer hat den node unbrauchbar zurückgelassen:
Das ist ein upstream-Problem. Mindestens OpenWrt, wenn nicht sogar kernel.
Reboot nach 10 sek bei OOM:
könnte helfen
Reboot on Panic + Panic on OOM ist sicherlich keine blöde Idee für unsere Firmware, denn der OOM Killer kann den Router aktuell auch nicht wieder ganz machen und egal was man abschießt, der Router ist danach auf die eine oder andere Art kaputt.
Dennoch sollten wir dieses Problem weiter verfolgen, denn es muss eine Ursache haben. Das ganze tritt ja auf Geräten mit 64 MB RAM und ohne 5 GHz auf. Die haben im normalen Betrieb fast die Hälfte des RAMs komplett frei.
Von vm.overcommit_memory=1 halte ich nichts..
In letzter Zeit ohne Änderungen am GW wieder gehäuft Ausfälle durch OOM-Killer. Es ist ein showstopper, gerade für GUs, wenn der Router mit WAN Uplink wegen OOM-Killer hostapd verliert ist nach kurzer Zeit alles dahinter tot. Man kommt aber nicht sofort an die Hardware ran und kann das Problem nicht remote fixen, wenn auch noch sshd und httpd gekillt wird.
Bei dem gepasteten dmesg output kann man sehen, dass der OOM Killer reinkickt, wenn weniger als 8MB Memory frei ist (min:8192kB). Das ist auf Geräten mit 32MB ein seltsames limit, führt es doch dazu, dass maximal 24MB RAM genutzt werden können.
Es macht Sinn, das auf 1MB zu setzen.
Found a workaround. It seems like the vm.min_free_kbytes setting is too high at 8 MB. I've tweaked that down to 4 MB and set vm.swapiness to 1 and that seems to have stopped the OOM killer. - from https://forum.openwrt.org/t/workaround-hostapd-terminated-by-oom-killer/13612
Das stimmt, das Limit wird aber für Geräte dynamisch festgelegt. Der 1043 hat 64 MB RAM, da wird min_free_kbytes von OpenWrt auf 8192 gesetzt. Bei 32 MB RAM ist min_free_kbytes 1024. Siehe hier: [1]
Bei 64 MB RAM ist normalerweise knapp die Hälfte des RAMs frei, daher muss es sich hier eigentlich um einen Bug handeln. Muss weiter untersucht werden.
Der OOM-Killer ergibt in unserer Firmware - wie schon angemerkt - nur wenig Sinn. Ich möchte dies im nächsten Release auf jeden Fall mit
panic_on_oom=1
umsetzen.Mit dem nächsten Release werden 32 MB Geräte wohl nicht mehr unterstützt werden können, da der RAM für OpenWrt 21.02 nicht mehr genügt.
vm.swapiness=1
sollte auf unserer Firmware keinen Effekt haben, da kein Swap aktiv ist.#151