RAM/Swap Nutzung

[greyghost]

Hallo allerseits,
ich beobachte auf einer Workstation seit Jahren das Problem, daß der Speicherverbrauch nach und nach immer größer wird und auch die Nutzung des Swapspace immer weiter zunimmt. Nach einigen Monaten Betrieb ist typischerweise alles voll, und es kommt zu OOM-Problemen (einzelne Tasks werden abgeschossen etc.). Beheben läßt sich das nur durch einen Reboot.
Insgesamt sieht das nach Memory-Leaks aus, was sich aber nur schwer für mich festnageln läßt. Die "üblichen Verdächtigen" wie dauerlaufende Mailclients (claws in meinem Fall) oder Browser (Chromium) lassen sich einzeln neu starten, ohne daß der Speicher zurückkommt.
Jetzt habe ich nach einem Reboot und keinen zwei Tagen Betrieb folgenden Status (top):

last pid: 76229; load averages: 1.87, 1.66, 1.53 up 1+22:32:54 07:45:00
164 processes: 1 running, 163 sleeping
CPU: 1.3% user, 11.5% nice, 10.0% system, 0.1% interrupt, 77.0% idle
Mem: 1363M Active, 19G Inact, 5463M Laundry, 4827M Wired, 765M Buf, 822M Free
ARC: 654M Total, 237M MFU, 188M MRU, 774K Anon, 8528K Header, 216M Other
139M Compressed, 644M Uncompressed, 4.64:1 Ratio
Swap: 64G Total, 1082M Used, 63G Free, 1% Inuse

In diesem Zustand (mit nur 1% Swap und eigentlich reichlich freiem -oder zumindest befreibarem- RAM) bekomme ich noch nicht einmal mehr die Swap-Parition ausgehängt:

# swapoff /dev/nvd0p3
swapoff: /dev/nvd0p3: Cannot allocate memory

Im Moment dreht Chromium auch im Hintergrund mit zumindest ein oder zwei Threads relativ hoch. Nach einem Neustart des Browsers ist die Systemlast niedriger, und die Swap-Partition läßt sich aus- und wieder einhängen. Ist Chromium damit der erste Verdächtige?

Wenn das System jetzt ein paar Wochen (oder 2-3 Monate) läuft, liegt der Swap-Use wie gesagt irgendwann bei 100% und es gibt entsprechende Probleme. Genauso sieht es aber auch aus, wenn man von Anfang an ohne Swap arbeitet. Dann ist das RAM irgendwann voll.
Derzeit läuft ein aktuelles 14.4, aber diese Probleme sehe ich wie gesagt schon seit vielen Jahren, auch auf unterschiedlicher Hardware. Kennt das jemand, oder gibt es Vorschläge zur Problemlösung oder weiterem Debugging?

 

[morromett]

Mem: 1363M Active, 19G Inact, 5463M Laundry, 4827M Wired, 765M Buf, 822M Free
ARC: 654M Total, 237M MFU, 188M MRU, 774K Anon, 8528K Header, 216M Other
139M Compressed, 644M Uncompressed, 4.64:1 Ratio
Swap: 64G Total, 1082M Used, 63G Free, 1% Inuse

Wie sind die Ausgaben von:

sysctl vm.stats.vm | grep -iE 'v_free_|swap|falls'
sysctl vm.vmtotal
ps axo pid,ppid,user,%mem,rss,command | sort -nk 5 | tail -n 5
top -b -w -d 1 5

?

 

[greyghost]

# sysctl vm.stats.vm | grep -iE 'v_free_|swap|falls'
vm.stats.vm.v_free_severe: 30891
vm.stats.vm.v_free_count: 359770
vm.stats.vm.v_free_min: 51160
vm.stats.vm.v_free_target: 172774
vm.stats.vm.v_free_reserved: 10622
vm.stats.vm.v_pdshortfalls: 208
vm.stats.vm.v_swappgsout: 446051
vm.stats.vm.v_swappgsin: 207657
vm.stats.vm.v_swapout: 46970
vm.stats.vm.v_swapin: 31580

# sysctl vm.vmtotal
vm.vmtotal:
System wide totals computed every five seconds: (values in kilobytes)
===============================================
Processes: (RUNQ: 3 Disk Wait: 0 Page Wait: 0 Sleep: 1059)
Virtual Memory: (Total: 80793066636K Active: 80793016084K)
Real Memory: (Total: 9936728K Active: 9912716K)
Shared Virtual Memory: (Total: 1205588K Active: 1155468K)
Shared Real Memory: (Total: 1156956K Active: 1133072K)
Free Memory: 1461468K

# ps axo pid,ppid,user,%mem,rss,command | sort -nk 5 | tail -n 5
77018 76286 username 1.7 558764 chrome: --type=renderer --enable-crash-reporter=, --origin-tri
77618 76286 username 1.7 583108 chrome: --type=renderer --enable-crash-reporter=, --origin-tri
76298 76286 username 2.2 718764 chrome: --type=renderer --enable-crash-reporter=, --origin-tri
76289 76286 username 2.3 756136 chrome: --type=gpu-process --ozone-platform=x11 --enable-crash
76286 2290 username 3.2 1074584 chrome: (chrome)

# top -b -w -d 1 5
last pid: 77655; load averages: 0.40, 0.56, 0.52 up 2+05:30:40 14:42:46
167 processes: 1 running, 166 sleeping
CPU: 1.3% user, 5.2% nice, 5.0% system, 0.0% interrupt, 88.5% idle
Mem: 2023M Active, 20G Inact, 1911M Laundry, 5443M Wired, 1127M Buf, 1437M Free
ARC: 1018M Total, 437M MFU, 387M MRU, 642K Anon, 12M Header, 165M Other
490M Compressed, 1174M Uncompressed, 2.40:1 Ratio
Swap: 64G Total, 33M Used, 64G Free

PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME WCPU COMMAND
1878 username 7 13 0 669M 223M 0B select 3 153:13 10.64% Xorg
76330 username 13 13 5 1366G 429M 0B uwait 0 0:55 7.47% chrome
76289 username 17 11 5 1085M 738M 0B select 0 8:15 5.18% chrome
76286 username 34 11 5 1393M 1049M 0B select 4 10:56 2.25% chrome
1912 username 6 0 0 327M 103M 0B select 1 10:13 0.78% xfwm4

 

[morromett]

# sysctl vm.vmtotal
vm.vmtotal: 
System wide totals computed every five seconds: (values in kilobytes)
===============================================
Processes:              (RUNQ: 3 Disk Wait: 0 Page Wait: 0 Sleep: 1059)
Virtual Memory:         (Total: 80793066636K Active: 80793016084K)

76330 username 13 13 5 1366G 429M 0B uwait 0 0:55 7.47% chrome

Versuch mal chrome mit der Option:

--disable-v8-sandbox

zu benutzen.

 

[mr44er]

Chrome/chromium hat einen Arbeitsspeicher-Sparmodus.

Findest du hier: chrome://settings/performance

Ein gerade inaktiv gehendes Tab hat allerdings nicht immer die gewünschten Auswirkungen, je nachdem was im Tab vonstatten ging. Größerer Upload/Backup auf einen Hoster via webgui? Wahrscheinlich abgebrochen. Youtube? Video fängt wahrscheinlich von vorne an usw.

 

[Azazyel]

Wenn das System jetzt ein paar Wochen (oder 2-3 Monate) läuft, liegt der Swap-Use wie gesagt irgendwann bei 100% und es gibt entsprechende Probleme.

Sollten nicht allein schon die FreeBSD-Security-Patches eine Uptime von 2-3 Monaten verhindern? Ansonsten ist aus Gründen der sauberen Administration des Rechners ein Reboot nach jedem Update sowieso empfehlenswert.

Versuch mal chrome mit der Option:

--disable-v8-sandbox

zu benutzen.

Das dürfte meines Wissens nicht helfen. Das Flag muss inzwischen zur Compile-Zeit gesetzt werden (zumindest Upstream, keine Ahnung was der FreeBSD-Port aktuell treibt). Ansonsten wird es zur Laufzeit einfach ignoriert.

Chrome/chromium hat einen Arbeitsspeicher-Sparmodus.

Der hilft tatsächlich etwas, behebt aber nicht das grundlegende Problem. Der FreeBSD-Port von Chromium hat eine ziemlich eigenwillige eigene Implementierung der Sandbox (eben leider (noch) nicht Capsicum), die zu massiver Speicherfragmentierung und Zombie-Prozessen führen kann.

Abhilfe schafft zwischendurch ein killall -9 chromium oder eben ein regelmäßiger Reboot. In dem verlinkten Artikel sind auch noch ein paar Tipps.

 

[dettus]

Ohne jetzt die Antworten genau gelesen zu haben oder FreeBSD zu koennen....


ulimit

?

 

[PMc]

Hm, also meiner ist auch 14.4 und verhält sich sauber - der Swap wächst mal auf 35GB, und schrumpft dann wieder auf 200MB, so wie erwartet. Auf meinem sind aber nur Server-Anwendungen, kein Desktop-Geziefer.
Dewegen würde ich darauf tippen, dass das letztere die Probleme verursacht.
Auch hab ich beobachtet, dass wenn ein Prozess gestoppt wird, der betreffende Swap annähernd sofort frei wird.

Irritieren tun mich bei Deiner Geschichte zwei sachen: einmal, warum läßt das System den Swap nicht abhängen, wenn es doch eigentlich nur ein bischen laundern müsste um Platz zu schaffen?
Und dann, warum wird der Swap nicht frei wenn Du die Prozesse neu startest? Werden die wirklich erstmal komplett rausgenommen?
Es kann natürlich sein dass diese Desktop-Anwendungen irgendetwas machen (Tenor: mir gehört das System), das nicht so verträglich ist mit einem Server-Betrieb.

Ein brauchbares Listing, welcher Prozess wieviel memory wo alloziert, kenne ich nicht. Im Extremum bleibt dann noch die ganz widerliche Variante: procstat -a vm und dann selber sinnvoll aufsummieren. Nach ein paar Stunden/Tagen wieder und schauen was da wächst. Macht keinen Spass.

 

[pit234a]

also, bei mir ist ja auch noch 14.4-RELEASE-p8 am Werken und ich nutze das als Desktop-System, allerdings mit Firefox und da läuft der RAM nicht voll und es ist dauernd am Laufen, was aber Uptimes von maximal etwa 30d bedeutet (wegen gelegentlicher Updates und Neustarts).
Dabei gibt es schon manchmal Seiten, die im FF viel RAM brauchen. Die gehören aber nicht zu jenen, die ich laufend benutzte und nach Schließen der Seiten fängt sich das dann wieder, spätestens nach einem Neustart des FF.
Deshalb ist meine Überlegung, zumindest mal eine Weile zum Testen den FF zu nutzen und ganz auf Chrome zu verzichten.

Was mit außer den unglaublichen Memory-Werten hier auffällt:

76330 username 13 13 5 1366G 429M 0B uwait 0 0:55 7.47% chrome

alle deine chrome laufen mit einem nice von 5, während mein FF und auch mein Chrome mit 0 laufen. Ich glaube, 0 ist auch normal. Hast du da schon was gemacht?

 

[morromett]

Ist Chromium damit der erste Verdächtige?

Dein System hat einen hohen virtuellen Speicher erzeugt (ca. 80 TB):

Virtual Memory:         (Total: 80793066636K Active: 80793016084K)

Du könntest den virtuellen Speicher (temporär) limitieren, mit z. B.:

vm.overcommit = 2

in der "/etc/sysctl.conf" und pro Prozess, in der "/etc/login.conf" (bei default):

:vmemoryuse=16G:\

und schauen was dann passiert bzw. welche Anwendung (chromium?) Probleme bekommt (evtl. abstürzt und wann).

EDIT:

Poste von deinem System, die Ausgabe von:

sysctl vm.pageout_oom_seq vm.v_free_min vm.v_free_target

 

[greyghost]

Danke erstmal für die vielen Ideen, die muß ich mal nach und nach durchgehen.
Was ich direkt sagen kann: Das ist kein reines Chromium-Problem. Daß ein gelegentliches "killall -9 chromium" Speicher zurückbringt, ist mir auch schon aufgefallen. Aber das hat Grenzen, nach und nach läuft das trotzdem voll.
Die Diskussion "Es gibt doch Updates, da muß man sowieso regelmäßig booten" möchte ich jetzt ehrlich nicht aufmachen. Die Software sollte imho dauerhaft stabil betreibbar sein, alles andere klingt eher nach "Windows-Lösung".


# sysctl vm.pageout_oom_seq vm.v_free_min vm.v_free_target
vm.pageout_oom_seq: 12
vm.v_free_min: 51160
vm.v_free_target: 172774
You have new mail

 

[greyghost]

Chrome/chromium hat einen Arbeitsspeicher-Sparmodus.

Findest du hier: chrome://settings/performance

Anhang anzeigen 5163

Ein gerade inaktiv gehendes Tab hat allerdings nicht immer die gewünschten Auswirkungen, je nachdem was im Tab vonstatten ging. Größerer Upload/Backup auf einen Hoster via webgui? Wahrscheinlich abgebrochen. Youtube? Video fängt wahrscheinlich von vorne an usw.

Der Sparmodus ist bereits mit den empfohlenen (mittleren) Einstellungen aktiv. Früher hatte ich auch mal ein Plugin dafür am Start ("Tab Suspender" sowas sowas ähnliches).
Upload/Download oder Youtube mache ich eigentlich fast nie mit dem Browser.

 

[greyghost]

Hm, also meiner ist auch 14.4 und verhält sich sauber - der Swap wächst mal auf 35GB, und schrumpft dann wieder auf 200MB, so wie erwartet. Auf meinem sind aber nur Server-Anwendungen, kein Desktop-Geziefer.
Dewegen würde ich darauf tippen, dass das letztere die Probleme verursacht.

Das sehe ich genauso. Meine Server haben keine solchen Probleme. Als Desktop habe ich nur die eine Maschine, daher sind lokale Vergleiche etwas schwierig (deswegen ja auch per Post hier). Als Oberfläche läuft bei mir xfce, die beiden relevanten und permanent GUI-Applikationen sind wie erwähnt Chromium und Claws.

 

[greyghost]

:vmemoryuse=16G:\und schauen was dann passiert bzw. welche Anwendung (chromium?) Probleme bekommt (evtl. abstürzt und wann).

Kann ich das "im laufenden Betrieb" oder für einzelne Prozesse ändern (mit limits o.ä.)?

 

[morromett]

Kann ich das "im laufenden Betrieb" oder für einzelne Prozesse ändern (mit limits o.ä.)?

Eine Änderung in der "/etc/login.conf" wird für bereits laufende Prozesse und aktive Sitzungen, im laufenden Betrieb nicht wirksam. Und die Allozierung von virtuellem Speicher hat ja auch schon statt gefunden.
Was Du im laufenden Betrieb ändern kannst, sind z. B.:

sysctl vm.v_free_min=262144   # 1 GB
sysctl vm.v_free_target=1048576  # 4 GB
sysctl vm.pageout_oom_seq=120
sysctl vm.swap_async_max=4

Aber auch damit wird die Wirkung anders sein, im Vergleich zur Wirkung "sofort ab dem Bootvorgang".
Wenn Du ZFS benutzt, dann zeig auch die Ausgabe von:

sysctl vfs.zfs.arc_max

 

[CommanderZed]

Meine Erfahrung als Desktop-Admin mit wirklich viel beruflichen Hintergrund ist:

Desktopsoftware wie Browser oder Office-Suiten werden de-facto und auch unabhängig vom Betrübssystem nicht dafür entwickelt dauerhaft zu laufen.
Einmal in der Woche würde ich entsprechend empfehlen die Anwendungen Neuzustarten oder noch besser das ganze System.

Alles andere ist mäßiges und unbefriedigendes rumdoktorn an Symtomen.

 

[greyghost]

Eine Änderung in der "/etc/login.conf" wird für bereits laufende Prozesse und aktive Sitzungen, im laufenden Betrieb nicht wirksam. Und die Allozierung von virtuellem Speicher hat ja auch schon statt gefunden.
Was Du im laufenden Betrieb ändern kannst, sind z. B.:

sysctl vm.v_free_min=262144   # 1 GB
sysctl vm.v_free_target=1048576  # 4 GB
sysctl vm.pageout_oom_seq=120

Aber auch damit wird die Wirkung anders sein, im Vergleich zur Wirkung "sofort ab dem Bootvorgang".
Wenn Du ZFS benutzt, dann zeig auch die Ausgabe von:

sysctl vfs.zfs.arc_max

ZFS ist in Benutzung:

vfs.zfs.arc_max: 0

Mit dem "laufenden Betrieb" hatte ich eben blöd formuliert. Mir ist schon klar, daß das keine laufende Prozesse ändert. Ich meinte, ob die Werte bei einem Neustart des Prozesses (also z.B. Chromium) berücksichtigt werden, oder ob man notwendigerweise erst dafür booten muß.

 

[morromett]

..., oder ob man notwendigerweise erst dafür booten muß.

Ja, erst booten.

EDIT:

Mit "vfs.zfs.arc_max: 0" ist für den ZFS-Cache kein Limit gesetzt. Versuch mal als Test (... wenn o. g. Werte keine Besserung bringen) mit 16GB (als Limit) in der "/boot/loader.conf":

vfs.zfs.arc_max="17179869184"

Wie sind jetzt die Ausgaben von:

sysctl kstat.zfs.misc.arcstats.size
arcstat 1

?

 

[greyghost]

Meine Erfahrung als Desktop-Admin mit wirklich viel beruflichen Hintergrund ist:

Desktopsoftware wie Browser oder Office-Suiten werden de-facto und auch unabhängig vom Betrübssystem nicht dafür entwickelt dauerhaft zu laufen.
Einmal in der Woche würde ich entsprechend empfehlen die Anwendungen Neuzustarten oder noch besser das ganze System.

Alles andere ist mäßiges und unbefriedigendes rumdoktorn an Symtomen.

Ok, dann diskutieren wir das doch weiter. :-)
Ich sehe das nicht als "rumdoktorn" an Symptomen, sondern als Suche nach Bugs, die repariert werden sollten. "Desktop-Software ist halt nicht für den Dauereinsatz gedacht" finde ich da eher unbefriedigend. In meinem Umfeld werden mit den Desktops u.a. auch Anlagen gesteuert und entsprechende Displays dauerhaft (24/7) angezeigt. Diese Anzeigen sind nicht fix und können auch nach einem Reboot nicht automatisiert wiederhergestellt werden, das macht jedes Mal richtig Arbeit.

 

[CommanderZed]

Ok, dann diskutieren wir das doch weiter. :-)
Ich sehe das nicht als "rumdoktorn" an Symptomen, sondern als Suche nach Bugs, die repariert werden sollten. "Desktop-Software ist halt nicht für den Dauereinsatz gedacht" finde ich da eher unbefriedigend. In meinem Umfeld werden mit den Desktops u.a. auch Anlagen gesteuert und entsprechende Displays dauerhaft (24/7) angezeigt. Diese Anzeigen sind nicht fix und können auch nach einem Reboot nicht automatisiert wiederhergestellt werden, das macht jedes Mal richtig Arbeit.

Du kannst dich ja gerne wenn du entsprechende Bugs findest an die entsprechenden Chromium, LibreOffice oder Firefox-Entwickler wenden und hoffen das die so beschrieben sind das die gelöst werden.

Aber wenn die gefixt sind ist die chance hoch das dann kurze Zeit später der nächste Ähnliche Bug auftaucht - wie seit 20 Jahren in dem Bereich. Das kann man - natürlich zurecht - blöd finden aber da pellt sich Google und Firefox halt auch nen ei drauf, zumal ihr mit denen ja sicher keine entsprechenden Verträge abgeschlossen haben werdet.

Ich geh gerne mit das das alles sehr unbefriedigend ist. Aber das ist der Stand der Technik, gerade auch so von Browsern, im Jahr 2026. Das zu ändern, selbst wenn man richtig viel Asche hat und draufwirft, ist fraglich. Also wird es sinnvoller sein sich zu arrangieren und zu mitigieren.

Wir haben auch z.B. Desktopsoftware die Anlagen steuert, auch noch ausgerechnet eine Java-Anwendung, dort ist aber alles so für die Kollegen aufbereitet das sich nach einem neustart den wir immer Samstag Nacht automatisiert machen (wo garnicht oder wenig gearbeitet wird) sich alles automatisch wieder öffnet das wäre imho auch der realistischere weg den man sich anschauen sollte.

 

[midnight]

Evtl hilft dir da hier weiter: https://klarasystems.com/articles/controlling-resource-limits-with-rctl-in-freebsd/ Ist auch fuer Jails ganz nuetzlich.

 

[Azazyel]

Ich geh gerne mit das das alles sehr unbefriedigend ist. Aber das ist der Stand der Technik, gerade auch so von Browsern, im Jahr 2026. Das zu ändern, selbst wenn man richtig viel Asche hat und draufwirft, ist fraglich. Also wird es sinnvoller sein sich zu arrangieren und zu mitigieren.

Korrekt. Spätestens seit dem berühtem Zitat everything fails all the time (aus dem Jahre 2008) setzt sich auch mehr oder minder langsam in der IT die Erkenntnis durch, dass die alten Uptime-Battles mehr Probleme verursachen als lösen.

Bei Flugzeugen hat auch auf die harte Tour gelernt, dass auch mit noch so viel Engineering und Sorgfalt immer Probleme auftreten werden. Deswegen setzt man zusätzlich auf Redundanz und Isolation von Fehlern. Gern auch in Verbindung mit dem Austausch von Komponenten, bevor sie Probleme machen können (Stichwort preventive maintenance, was bei Software eben auch ein Reboot ist).

Zurück zu FreeBSD - mit rctl kann man doch auch chromium ein Korsett anlegen. Das geht zwar nicht so elegant wie mit systemd-run, aber mit überschaubarem Aufwand und nativen FreeBSD-Tooling.

Wir haben auch z.B. Desktopsoftware die Anlagen steuert, auch noch ausgerechnet eine Java-Anwendung, dort ist aber alles so für die Kollegen aufbereitet das sich nach einem neustart den wir immer Samstag Nacht automatisiert machen (wo garnicht oder wenig gearbeitet wird) sich alles automatisch wieder öffnet das wäre imho auch der realistischere weg den man sich anschauen sollte.

Ich würde auch meine Zeit und Energie lieber auf die Fehlertoleranz und Wiederanlauffähigkeit der Software bzw. des Systems statt dem utopischen Traum der ewigen Uptime und völligen Fehlerfreiheit von Software setzen.

 

[pit234a]

Als Oberfläche läuft bei mir xfce, die beiden relevanten und permanent GUI-Applikationen sind wie erwähnt Chromium und Claws.

also nochmal zu mir:
14.4-RELEASE-p8, alle paar Wochen mal Updates.
Bei Updates gibt es immer mal wieder neue FF-Versionen -> FF-Neustart (und Claws, etc).
System komplett Neustart nur nach Updates auf neue Module / neuen Kernel oder bei längerem Stromausfall (wenn die USV nicht langt).
Der Rechner laüft als labwc-Desktop mit Wayland in 24x7.
Für mich ohne erkennbare Probleme.

pit@Mifcom ~:- > top -b -w -d 1 5
last pid: 90871;  load averages:  0,83,  0,45,  0,27  up 30+05:03:44    19:22:44
130 processes: 2 running, 128 sleeping
CPU:  0,2% user,  0,0% nice,  0,1% system,  0,0% interrupt, 99,7% idle
Mem: 1534M Active, 25G Inact, 1231M Laundry, 23G Wired, 198G Free
ARC: 9632M Total, 5864M MFU, 2000M MRU, 3561K Anon, 114M Header, 1508M Other
     6656M Compressed, 15G Uncompressed, 2,35:1 Ratio

  PID USERNAME    THR PRI NICE   SIZE    RES SWAP STATE    C   TIME    WCPU COMMAND
93504 pit         103   1    0    35G  5620M   0B select   6 132:38  20,51% firefox
57567 pit          33  13    0  2743M   383M   0B CPU59   59   2:54  19,34% firefox
89919 pit           7  19    0  1913M  1471M   0B select  44 653:54  14,84% labwc
90021 pit           5   5    0    76M    42M   0B select  46  23,0H   3,08% gkrellm
33905 pit          34   0    0  4388M  1868M   0B select  25 104:06   2,49% firefox

pit@Mifcom ~:- > sysctl kstat.zfs.misc.arcstats.size
kstat.zfs.misc.arcstats.size: 10099986176

Seit diesem Beitrag läuft auch ein Chrome mit einem geöffneten Tab.
Mein ZFS-Arc-max steht auf 10G (von früher her schon), SWAP nutze ich noch immer nicht, FF und Claws laufen dauernd, zusätzlich übliche Desktop-Anwendungen schon mal über viele Tage.

Der erste Unterschied, der mir ins Auge springt: XFCE.
Dass der ZFS-Arc unbegrenzt bei dir ist, natürlich auch, aber das sollte doch funktionieren, sonst wäre das ja ein ziemlich ernster Bug in FreeBSD und würde vielleicht eher noch bei den Servern auffallen.

 

[Yamagi]

Abseits der anderen, guten Überlegungen finde hier wired auffällig hoch:

Mem: 1363M Active, 19G Inact, 5463M Laundry, 4827M Wired, 765M Buf, 822M Free
ARC: 654M Total, 237M MFU, 188M MRU, 774K Anon, 8528K Header, 216M Other
    139M Compressed, 644M Uncompressed, 4.64:1 Ratio
Swap: 64G Total, 1082M Used, 63G Free, 1% Inuse

wired ist hart verdrahteter Speicher, also Speicher, der nicht auf virtuellen, sondern auf physischen Adressen liegt und daher nicht geswapt werden kann. Das sind Dinge wie DMA-Zonen, kernelinterne Buffer abseits des Buffer Caches, der ZFS ARC und in geringem Maße mit mlock() gesperrter Speicher. Wenn etwas im Kernel wired Speicher leckt, hat das System - es kann den ja nicht swappen - immer weniger Luft zum Atmen und erstickt irgendwann an sich selbst.

Ich würde mal beobachten, ob wired mit zunehmender Uptime immer weiter ansteigt oder ob es sich einpendelt. Wenn ja, ist unser aller Freund, der übertrieben komplexe und fragile Grafiktreiber mit all seinem unschönen Geraffel außen rum, ein ganz heißer Kandidat.