Hallo,
warum zeigt das Dashboard die RAM-Auslastung nicht korrekt an?
Tatsächlich liegen 18 GB Logs im tmpfs:
root@OPNsense:~ # df -h /var/log
Filesystem Size Used Avail Capacity Mounted on
tmpfs 32G 18G 14G 56% /var/log
root@OPNsense:~ # du -h -d 1 /var/log | sort -h
0B /var/log/ntp
0B /var/log/radacct
0B /var/log/suricata
8.0K /var/log/monit
28K /var/log/telegraf
36K /var/log/ntpd
41K /var/log/pkg
53K /var/log/gateways
57K /var/log/lighttpd
246K /var/log/firewall
538K /var/log/routing
590K /var/log/resolver
1.7M /var/log/system
41M /var/log/audit
50M /var/log/configd
83M /var/log/squid
84M /var/log/kea
18G /var/log
18G /var/log/filter
Weil evtl je nach deinem Setup:
* ZFS da ist und ZFS für /var/log ggf. inline compression nutzt und df deshalb was anderes reported als faktisch der Fall ist?
* Weil das Disk Widget im Screenshot sich nur auf die physikalische Platte/SSD bezieht und nicht auf ein tmpfs mount? (kann man im Widget ja einstellen was angezeigt wird)
* Weil das evtl einfach nur im RAM rumeiert (RAM Disk aktiviert?)
Da bräuchte man ein paar Infos mehr.
Cheers :)
Klar ist die RAMDisk aktiviert, sonst wäre /var/log ja kein tmpfs.
Was hat denn das Disk Widget mit dem Memory Widget zu tun?
Die RAMDisk ist ein tmpfs. Was hat das ZFS auf den physischen Platten damit zu tun?
Ich hätte einfach nur gerne, dass das Memory Widget mir anzeigt, wie mein Memory ausgelastet ist. Dafür ist es docch da oder.
Quote from: JeGr on November 13, 2025, 06:29:09 PMDa bräuchte man ein paar Infos mehr.
Welche Infos brauchst du denn und wie kann ich die liefern?
Ich frage jetzt mal in einem anderen Forum, ob da jemand eine Idee hat.
Ruf mal "top" auf und guck dir diese Zeile an:
Mem: 209M Active, 1869M Inact, 3488M Wired, 2286M Free
und vergleich das mit dem Widget. Wie das mit dem tmpfs zusammen geht, weiß ich jetzt spontan auch nicht.
Ich habe mittlerweile etwas aufgeräumt und nur noch 5,8 GB Logs in /var/log.
Top sagt:
Mem: 361M Active, 20G Inact, 4410M Wired, 104K Buf, 38G Free
Die Anzeige des Widget stimmt immer noch nicht. Das zeigt 2,4 GB belegten RAM an, während alleine die Logs 5,8 GB im tmpfs belegen.
Filesystem Size Used Avail Capacity Mounted on
tmpfs 32G 5.9G 26G 18% /var/log
Die sind Teil von den 20G Inact. Das ist Speicher, auf den ewig nicht zugegriffen wurde. Der wird behandelt wie "Free", weil man das ja jederzeit raus swappen kann, wenn nötig.
Hm, das verstehe ich nicht. Das 32 GB tmpfs ist doch fest. Wenn der RAM voll läuft, werden dann Logs gelöscht? Wie soll das funktionieren?
Wenn da 18 GB Logs im tmpfs legen, gehe ich davon aus, dass dieser RAM anderen Anwendungen nicht zur verfügung steht. Falsch?
Mit "raus swappen" ist in den Swap verschieben gemeint, nicht löschen. Wenn der RAM vollläuft, dann werden inaktive Pages (und damit potentiell auch das tmpfs) in den Swap verschoben. Hast Du keinen bzw. nicht ausreichend Swap, dann geht das natürlich nicht. Dann ist der RAM eben voll.
Die Speicherverwaltung berücksichtigt bei der Bewertung als "inaktiv" nicht, ob das tmpfs-Daten oder irgendwelche anderen Daten sind.
Und das Widget zählt inaktive Pages zum "freien" Speicher. Ob das sinnvoll ist kann man sicherlich diskutieren.
Grüße
Maurice
Betrachtet man den inaktiven Speicher als "belegt", dann sähe es so aus:
opnsense-patch a49dece
Dazu kommt, dass das tmpfs eben nicht "fest" ist. Das liegt nicht im physischen Speicher sondern im virtuellen. Wenn du ein 10G tmpfs anlegest, ist das dadurch belegte RAM: 0. Schreibst du dann 1G hinein, wird 1G RAM allokiert.
Aber wenn 18 GB an filter Logs im tmpfs liegen, dann muss der RAM doch belegt sein?
Nein, die 18 GByte können in den Swap ausgelagert werden und werden deshalb nicht als aktiv gewertet. Du könntest das sehen, wenn mehr RAM benötigt würde - dann würde ein Teil des durch das tmpfs belegten Platzes swap ausgelagert - aber eben nur, wenn das notwendig ist.
Die Swap-Belegung wird sichtbar, wenn man "top -oswap -w" oder "swapinfo" aufruft. Normalerweise wird genausoviel Swap wie physisches RAM angelegt. Bei Dir fällt das alles nicht ins Gewicht, weil der Kernel plus die Programme plus das tmpfs zusammen immer noch kleiner als das RAM ist.
Wenn Du unter System: Firmware: Packages das Paket "stress-ng" installierst, kannst Du beispielsweise "stress-ng -m1 --vm-bytes 32G --vm-keep" aufrufen. Damit wird Dein gesamtes RAM belegt, so dass Auslagerungen stattfinden müssen. Dadurch werden wahrscheinlich zuerst die (inaktiven) Log-Dateien ausgelagert. Du wirst mit "top -oswap -w" sehen, dass zuerst der Free-Anteil schnell kleiner wird und wenn er nahe Null ist, beginnt der Swap, sich zu füllen.
Jetzt klarer?
Quote from: bamf on November 14, 2025, 10:32:15 AMAber wenn 18 GB an filter Logs im tmpfs liegen, dann muss der RAM doch belegt sein?
Das ist der Teil, den ich ja auch nicht ganz verstehe :-)
Schreibst Du 18 GB Daten in das tmpfs, dann sind dadurch 18 GB RAM belegt, aber eben "inaktiv". Und das Widget interpretiert inaktive Belegung als "frei".
Momentan ist die Logik zur Berechnung des belegten Speichers:
belegt = physisch - frei - cached - inaktiv
Es spricht manches dafür, die inaktiven Pages hier nicht abzuziehen. Teste mal den Patch aus meinem letzten Beitrag, der tut genau das.
Diesen Patch kann ich einfach so anwenden, ohne für zukünftige Updates irgendwas kaputtzumachen? Ich bin da eher vorsichtig :)
Wenn das sinnvoll ist, könnte man das ja mal Upstream einbauen?
Swap habe ich jetzt mal mit swapoff -a und auskommentieren der Zeilen in der fstab ganz abgeschaltet. Brauche ich nicht bei der Menge an RAM. Die Firewall loggt um die 700 MB / Tag, da reichen die 32 GB tmpfs locker für 31 Tage.
opnsense-patch kann immer genutzt werden, es schlägt einfach fehl ohne was zu ändern wenn es nicht kompatibel ist.
Updates überschreiben die patches.
Der commit ist aus einem Fork, den gibt es so nicht im Haupt Repo.
https://github.com/opnsense/core/commit/a49dece
Aber Maurice kannst du schon vertrauen. Ist aber deine Entscheidung. Das sieht sehr low risk aus.
Kannst Du einfach so anwenden, ja. Wird dann durch das nächste Update wieder überschrieben.
Das ist nur eine winzige Änderung:
https://github.com/maurice-w/opnsense-core/commit/a49dece
(opnsense-patch nutzt automatisch auch Forks.)
Es liegt aber nicht an mir zu entscheiden, ob man inaktive Pages als frei oder belegt betrachtet. Da kommt man ganz schnell in Grundsatzdiskussionen, ob z. B. großzügig dimensionierter Swap überhaupt noch zeitgemäß ist.
Außerdem würde dann bei allen Usern auf dem Dashboard plötzlich deutlich mehr belegter RAM angezeigt. Welche Diskussionen das auslöst kann man sich vorstellen.
Daher sehe ich von einem Pull Request erstmal ab.
Bitte nicht nochmal so was wie das Temperatur widget xD
Quote from: bamf on November 14, 2025, 12:49:54 PMDiesen Patch kann ich einfach so anwenden, ohne für zukünftige Updates irgendwas kaputtzumachen? Ich bin da eher vorsichtig :)
Ja, kannst du. Das nächste Update wird ihn einfach wieder überschreiben - entweder mit der vorherigen Version oder evtl. mit der aktualisierten inklusive Patch, falls er in die Release mit aufgenommen wird.
Quote from: bamf on November 14, 2025, 12:49:54 PMWenn das sinnvoll ist, könnte man das ja mal Upstream einbauen?
Bei Upstream (FreeBSD) liegt kein Problem vor. Der Speicher wird als "inactive" gezählt. Schon immer. Die Frage ist ob das Widget "inactive" als frei oder als belegt anzeigen soll.
Speicherverwaltung in einem modernen Unix ist mehr als "frei" oder "belegt".
FreeBSD kennt die Status
- wired
- active
- laundry
- inactive
- free
Und nach dem Motto "free memory is wasted memory" wird was mal im Cache ist, drin behalten, so lange kein anderer Prozess freien Speicher benötigt.
Sieht z.B. auf meinem TrueNAS CORE so aus wie im Anhang.
Mehr Info zur Ausgabe von top(1): https://klarasystems.com/articles/explaining-top1-on-freebsd/
HTH,
Patrick
Quote from: Maurice on November 14, 2025, 01:10:21 PMAußerdem würde dann bei allen Usern auf dem Dashboard plötzlich deutlich mehr belegter RAM angezeigt. Welche Diskussionen das auslöst kann man sich vorstellen.
Daher sehe ich von einem Pull Request erstmal ab.
Ich fände das schon sinnvoll. Denn der im tmpfs belegte RAM steht dem System ja definitiv nicht zur Verfügung. Daher finde ich die Anzeige im Widget irreführend. Und /var/log und /var/tmp als tmpfs ist ja nicht unüblich auf der OPNSense.
Quote from: Patrick M. Hausen on November 14, 2025, 01:15:42 PMBei Upstream (FreeBSD) liegt kein Problem vor. Der Speicher wird als "inactive" gezählt. Schon immer. Die Frage ist ob das Widget "inactive" als frei oder als belegt anzeigen soll.
Achso, ja ich meinte auch eigentlich als fix für das Widget im OPNSense Repo. Nicht upstream bei FreeBSD.
Das sieht schon weitaus näher an der Realität aus, danke :)
Ich stimme dir zu, aber solche Änderungen sind leider ein ganz heikles Thema. Eine Flut von "The latest update eats all my RAM!!!"-Beiträgen wäre garantiert.
Persönlich würde ich sagen: So what. Aber ich bin ja nicht der, der den Backlash dann abbekommen würde, insofern halte ich mich da zurück.
Naja, widgets haben ja ein configuration modell darunter.
Hier z.b. ein Beispiel vom dnsmasq widget, oder das certificate widget was ich geschrieben habe.
https://github.com/opnsense/core/blob/1d060380a56153f62609be01573b2399a6b4cc70/src/opnsense/www/js/widgets/Certificates.js#L186-L194
https://github.com/opnsense/core/blob/1d060380a56153f62609be01573b2399a6b4cc70/src/opnsense/www/js/widgets/DnsmasqLeases.js#L151-L167
Man könnte das RAM widget auch anpassbar machen, dann kann sich jeder das einstellen was er sehen möchte.
PRs welcome :)
Quote from: Monviech (Cedrik) on November 14, 2025, 02:05:09 PMMan könnte das RAM widget auch anpassbar machen, dann kann sich jeder das einstellen was er sehen möchte.
Das wäre natürlich sehr cool.
Grundsätzlich eine gute Idee. Das Memory-Widget bekommt den "belegten" RAM aber schon fertig berechnet von der API (/api/diagnostics/system/system_resources). Daher müsste man erstmal diese erweitern. Die gibt bisher nur total / used / arc aus.
Ja da muss man wohl bis ganz zur quelle runter.
Aber wenn es nicht viele User brauchen ist es viel Arbeit für nichts. Kann man auch YAGNI sagen.