OPNSense Schreibvorgänge auf SSD minimieren

[CoMo]

Hallo,

Ich sehe in htop und iostat auf meiner OPNSense ab und zu Schreibvorgänge auf die SSDs. Ich schätze mal so alle 10-20 Sekunden.

                        extended device statistics
device       r/s     w/s     kr/s     kw/s  ms/r  ms/w  ms/o  ms/t qlen  %b
nda0           0      82      0.0    540.0     0     0     0     0    0   0
nda1           0      83      0.0    540.0     0     0     0     0    0   0

/tmp und /var/log liegen im RAM:

root@OPNsense:~ # df -h
Filesystem                   Size    Used   Avail Capacity  Mounted on
zroot/ROOT/default           219G    1.7G    217G     1%    /
devfs                        1.0K      0B    1.0K     0%    /dev
/dev/gpt/efiboot0            260M    1.3M    259M     1%    /boot/efi
zroot                        217G     96K    217G     0%    /zroot
zroot/var/crash              217G     96K    217G     0%    /var/crash
zroot/usr/src                220G    2.6G    217G     1%    /usr/src
zroot/home                   217G     96K    217G     0%    /home
zroot/var/audit              217G     96K    217G     0%    /var/audit
zroot/usr/ports              219G    1.5G    217G     1%    /usr/ports
zroot/var/mail               217G    128K    217G     0%    /var/mail
zroot/var/tmp                217G     96K    217G     0%    /var/tmp
tmpfs                         32G    3.0G     29G    10%    /var/log
tmpfs                         32G    7.6M     32G     0%    /tmp
devfs                        1.0K      0B    1.0K     0%    /var/dhcpd/dev
/lib                         219G    1.7G    217G     1%    /var/unbound/lib
devfs                        1.0K      0B    1.0K     0%    /var/unbound/dev
/usr/local/lib/python3.11    219G    1.7G    217G     1%    /var/unbound/usr/local/lib/python3.11

Reporting ist deaktiviert, Netflow ist deaktiviert, RRD ist deaktiviert. Das System läuft von 2 SSDs im ZFS Mirror.

Ich hätte schon gerne Reporting und Logs, aber das soll halt alles im RAM landen.

Was habe ich übersehen?

 

[Miximus]

Wo ist das Problem?

 

[HisN]

Ich hätte schon gerne Reporting und Logs, aber das soll halt alles im RAM landen.

Du hast Log2Ram nicht installiert? :-)

 

[CoMo]

Keine Ahnung. Hast du irgendwo eins gesehen? Ich habe lediglich die Im Titel genannte Anforderung.

 

[KenshiHH]

Unter System->Settings->Miscellaneous und dort bei Disk/Memory Settings gibt es doch extra die Option für Logs in den RAM

edit: Ups, das hab ich gekonnt übersehen dass du es schon aktiviert hast

 

[CoMo]

Mehr als eine RAMDisk für /tmp und /var/log erstellen kann ich da aber nicht. Und die habe ich schon, siehe erster Beitrag.

 

[Miximus]

Nochmal: wo ist das Problem? Denkst du, du würdest die SSD tot schreiben damit?

 

[CoMo]

Ich habe das System so konfiguriert, dass alles im RAM passieren soll und trotzdem gibt es Schreibzugriffe auf die SSD. Ich möchte herausfinden, warum. Das Problem, nach dem du so verzweifelt suchst, gibt es nicht.

 

[Helge01]

Denkst du, du würdest die SSD tot schreiben damit?

Mit aktivierten pfBlocker auf der pfSense haben das schon einige in kurzer Zeit geschafft.

 

[kartoffelpü]

Schau mal mit iotop, falls das bei OPNsense verfügbar ist. Oder fatrace.

 

[andy_m4]

Ich sehe in htop und iostat auf meiner OPNSense ab und zu Schreibvorgänge auf die SSDs. Ich schätze mal so alle 10-20 Sekunden.

Bist Du Dir überhaupt sicher, das die von irgendwelchen Loggings u.ä. kommt?

Das würde ich erst mal abklären.
OPNsense ist meines Wissens nach ein angepasstes FreeBSD.
Das heißt, Du hast da hoffentlich ein dtrace drauf.

Das kann man nutzen, um zum Beispiel zu gucken, wer welche Dateien zum schreiben öffnet:

dtrace -q -n 'syscall::open:entry /arg1 & 0x1==0x1/  {
printf("%s - %s\n", execname, copyinstr(arg0));
}' -n 'syscall::openat:entry /arg2 & 0x1==0x1/ {
printf("%s - %s\n", execname, copyinstr(arg1));
}'

("unglücklicherweise" gibts open und openat ; die muss man unterschiedlich behandeln weil die Parameterreihenfolge etwas anders ist).
Damit kriegt man nicht alle Schreibzugriffe (remove, move etc. nicht), aber vielleicht reicht das so schon um die Ursache zu identifizieren. Ansonsten muss man es halt entsprechend erweitern.

Ach ja. Ich würde vielleicht noch ein
|grep -v /dev/null
dranhängen. Manche Prozesse schreiben da gerne hin und dann verschmutzt das einem unnötigerweise die Ausgabe.

btw.: Möglicherweise muss dtrace aktiviert werden. Aus Securitygründen ist das gerne mal deaktiviert. Bei OPNsense könnte ich mir das nämlich gut vorstellen.

 

[Teckler]

@CoMo
oder auch mal in der fstab nach den 3 Einstellungen googeln

atime
noatime
relatime

Angabe, wie oft und in welchen Situationen der Zeitstempel access time aktualisiert werden soll. In den meisten Fällen ist die Vorgabe relatime zweckmäßig; hierbei wird der Zeitstempel nur in besimmten Situationen geschrieben. Mit atime odernoatime kann die Aktualisierung vollständig ein- bzw. ausgeschaltet werden.

 

[CoMo]

Ich vermute mal, das dtrace soll eine Zeile sein. Da kommt das hier:

root@OPNsense:/var/log # dtrace -q -n 'syscall::open:entry /arg1 & 0x1==0x1/  {printf("%s - %s\n", execname, copyinstr(arg0));}' -n 'syscall::openat:entry /arg2 & 0x1==0x1/ {printf("%s - %s\n", execname, copyinstr(arg1));}'
dtrace: invalid probe specifier syscall::open:entry /arg1 & 0x1==0x1/  {printf("%s - %s\n", execname, copyinstr(arg0));}: "/usr/lib/dtrace/ipfw.d", line 126: syntax error near "in_addr_t"

Und die fstab sieht so aus:

root@OPNsense:/var/log # cat /etc/fstab
# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/gpt/efiboot0               /boot/efi       msdosfs rw              2       2
/dev/nda0p3             none    swap    sw              0       0
/dev/nda1p3             none    swap    sw              0       0

Ergänzung (25. März 2025)

In der angegebenen Datei /usr/lib/dtrace/ipfw.d steht das hier:

121         /* flow id */
122         uint8_t         addr_type;
123         uint8_t         proto;
124         uint8_t         proto_flags;
125         uint16_t        fib;    /* XXX */
126         in_addr_t       dst_ip; /* in network byte order */
127         in_addr_t       src_ip; /* in network byte order */
128         struct in6_addr dst_ip6;
129         struct in6_addr src_ip6;
130
131         uint16_t        dst_port; /* in host byte order */
132         uint16_t        src_port; /* in host byte order */

Ergänzung (25. März 2025)

iotop und fatrace gibt es nicht in den Paketquellen.

Ergänzung (25. März 2025)

Der Swap ist ungenutzt:

Device              Size     Used    Avail Capacity
/dev/nda0p3         8.0G       0B     8.0G     0%
/dev/nda1p3         8.0G       0B     8.0G     0%
Total                16G       0B      16G     0%

 

[andy_m4]

dtrace: invalid probe specifier syscallpen:entry

Wie gesagt: Kann durchaus sein, das das bei OPNsense ausgeknipst bzw. zumindest beschränkt ist.
# sysctl debug.dtrace.providers
sollte Auskunft darüber geben, ob und was verfügbar ist. Wenn da in der Liste nicht syscall auftaucht, dann gucken wir weiter.

Ergänzung (25. März 2025)

btw.: Ist überhaupt "Module loading" erlaubt oder ist das auch aus?
Man kann ja versuchshalber mal ein
# kldload dtraceall
absetzen.

Ergänzung (25. März 2025)

Man kann ja sonst auch einfach mal find(1) benutzen, um zu gucken, welche Dateien jüngst geändert wurden (anhand der Modification Time).
z.B. find /mypath -mmin -10
um zu gucken, was so die letzten 10 Minuten "passiert" ist.

Oder falls es ne offene Datei ist, findet man die auch mit fstat(1)

Wäre ein anderer Ansatz als jetzt dtrace zurechtzufrickeln.

Ergänzung (25. März 2025)

oder auch mal in der fstab nach den 3 Einstellungen googeln

ZFS taucht bei FreeBSD respektive OPNsense nicht in der /etc/fstab auf. Das hat seinen eigenen Mount-Mechanismus.

Wenn man so was wie noatime machen will, dann aufs jeweilige Dataset bzw Filesystem durch setzen des atime-Attributs mit:
zfs set atime=on mypool/mydataset

bzw. zum Abfragen:
zfs get atime mypool/mydataset

 

[CoMo]

find /mypath -mmin -10

Die Idee ist so simpel wie effektiv 👍 Da hätte ich auch selbst drauf kommen können.

Ich hatte wohl mal vnstat eingerichtet und das bisher bei der Analyse völlig übersehen. Natürlich schreibt der regelmäßig nach /var/lib/vnstat/vnstat.db.

Ansonsten gibt es wohl Schreibzugriffe auf /var/db/aliastables/ und Unbound schreibt auch irgendwas nach /var/unbound/data/unbound.duckdb.

Weiterhin werden wohl die DHCPv6 Leases auf die Disks geschrieben: /var/dhcpd/var/db/dhcpd6.leases.

Damit kann ich was anfangen, danke!

 

[andy_m4]

Weiterhin werden wohl die DHCPv6 Leases auf die Disks geschrieben

Wobei das auch nicht verkehrt ist. Weil sonst hat der dhcpd nach einem Reboot vergessen, welche Leases noch vergeben sind.
Man könnte aber auch noch abmildert, wenn man das auch in die RAM-Disk schreiben lässt und im Shutdown-Skript hinterlegt, das er es erst dann auf Disk schreiben soll bzw. beim booten es wieder in die RAM-Disk verschiebt bevor dhcpd gestartet wird.

Und so ähnlich könnte man natürlich auch mit den anderen Dateien verfahren.

Die Idee ist so simpel wie effektiv

Manchmal sind die einfachsten Lösungen die besten. :-)

 

[CoMo]

Man könnte aber auch noch abmildert, wenn man das auch in die RAM-Disk schreiben lässt und im Shutdown-Skript hinterlegt, das er es erst dann auf Disk schreiben soll bzw.

Die Funktionalität bringt die OPNSense von Haus aus mit und die habe ich auch aktiviert.

Warum die Leases dennoch im laufenden Betrieb auf der Platte landen, muss ich vielleicht mal im OPNSense-Forum erfragen.

 

[andy_m4]

Die Funktionalität bringt die OPNSense von Haus aus mit und die habe ich auch aktiviert.

Ah ok. Gut zu wissen.

Warum die Leases dennoch im laufenden Betrieb auf der Platte landen, muss ich vielleicht mal im OPNSense-Forum erfragen.

Evtl. macht es auch Sinn dazu das Startup-Skript zu konsultieren. Das sind ja (wenn die den FreeBSD-Gepflogenheiten folgen) nur einfache Shell-Skripte, die relativ einfach zu lesen sind.
I.d.R. liegen die unter
/usr/local/etc/rc.d
oder
/etc/rc.d
Der Name wird ja irgendwas mit dhcp sein, wenn die jetzt nicht gerade dnsmasq oder so was nehmen.

Wenn die sich an die Konventionen halten, dann gibt es irgendwo eine Funktion die mit _precmd respektive _postcmd endet, wo die Funktionalität drin stecken könnte.
Da wird dann vielleicht ein Flag abgefragt oder so. Dann weiß man zumindest, wo man gucken kann und kann dann auch prüfen, ob was schief läuft und auch direkt debuggen.

muss ich vielleicht mal im OPNSense-Forum erfragen.

Macht absolut Sinn.
Dann musst Du Dich nicht auf mein gefährliches Halbwissen stützen. :-)

 

[netzgestaltung]

muss ich vielleicht mal im OPNSense-Forum erfragen.

ev hier noch die antwort oder einen link posten, würde mich auch interessieren.

@andy_m4 im OPNSense Interface lässt sich sowohl DNSMasq als auch unbound wählen - aber da hatte er keine Zugriffe, also vermutlich nicht aktiviert.

 

[andy_m4]

aber da hatte er keine Zugriffe, also vermutlich nicht aktiviert.

dnsmasq erzeugt ja auch eine Lease-Datenbank.
Und was unbound angeht, so scheint der ja nach /var/unbound/data/unbound.duckdb zu schreiben. So wie ich verstanden hab, zum Zwecke des Loggings.

Wenn man das nicht braucht, könnte man das Logging auszuschalten. Die Holzhammermethode die man machen könnte, wäre in der "unbound.conf" das auszuschalten.

Aber vielleicht findet sich da auch im WebUI eine Einstellung.
Denn meist haben diese WebUIs ihr ihre eigenen Konfig.Dateien aus denen sie dann die Konfig.Dateien der jeweiligen Programme erzeugen. Und wenn man die Konfig.Dateien der Programme direkt ändert, läuft man Gefahr, das die Änderungen (irgendwann) überschrieben werden.

Mit aktivierten pfBlocker auf der pfSense haben das schon einige in kurzer Zeit geschafft.

Ja. Aber war das wirklich eine SSD oder nicht eher eine SD-Karte bzw. USB Stick?
Und wie groß war die SSD? Wenn die randvoll ist, so das im Wesentlichen immer nur die selben Blöcke beschrieben werden (je nachdem, wieviel Reserve-Blöcke fürs Wear-Levelling da sind), dann läuft man natürlich eher mal in Probleme, als wenn man genug Platz hat.

Aber ja: Unnütze Schreibvorgänge vermeiden ist natürlich da prinzipiell eine gute Idee. Man darf ja auch nicht vergessen, das selbst wenn nur wenige Byte geschrieben werden, auf der "Disk" immer ein ganzer Block geschrieben werden muss. Wenngleich man da mit Write-Cache etwas entgegenwirken kann.