RAM-Puffergröße wächst kontinuierlich

English Allgemein
1

Seit einem kürzlichen Firmware-Update habe ich Probleme mit dem RAM, wobei am Ende 100 % des RAMs verbraucht werden und der normale RAM-Verbrauch von Prozessen in den Swap verschoben wird.

Ein Neustart des Systems ist erforderlich, um das Problem zu beheben, danach kehrt die Nutzung auf „normal“ zurück.

Details:
Firmware: QTS 5.2.9.3410
NAS: TS-673A
RAM: 32GB ECC
Netzwerkkonfiguration: 1 Port, untagged + 2 VLAN
Normaler RAM-Verbrauch der Prozesse: zwischen 7 und 16 GB
NAS-Nutzung: Containerstation Host → Nextcloud, Plex, Nginx, HomeAssistant, (+/-20 Container)

Durchgeführte Tests:
Laufende Prozesse reduziert, um eine einigermaßen stabile Nutzung von 7GB zu erreichen
RAM-Verbrauch über die Zeit beobachtet

Beobachtungen:
Kurz nach dem Booten: 7GB Nutzung, 2GB Buffer, 17GB Cache, 6GB frei, 0GB Swap-Nutzung
4 Stunden nach dem Booten: 7GB Nutzung, 3GB Buffer, 16,5GB Cache, 4,5GB frei, 0GB Swap-Nutzung
16 Stunden später: 9,8GB Nutzung, 16,5GB Buffer, 5GB Cache, 0,7GB frei, 0,5GB Swap-Nutzung

Es scheint, dass der Buffer im Laufe der Zeit immer weiter ansteigt und nicht wieder abnimmt. Sein Speicherplatz wird zuerst vom Cache abgezogen, gefolgt davon, dass normaler RAM in den Swap verschoben wird.

Hat jemand eine Idee, was dazu führen könnte, dass die Buffer-Größe wächst?

2

Obwohl du die Hardware- und Firmware-Details angegeben hast, wäre es wirklich hilfreich, wenn du sagen würdest, welche Prozesse du ausführst und welche Rolle das NAS übernimmt.
Diese Geräte sind so vielseitig, dass alles Mögliche passieren könnte.
Gibt QBoost den Speicher frei?

3

Diese Zahlen sehen gut oder zumindest unauffällig aus. :+1:

Du kennst diese Seite wahrscheinlich schon, aber für alle, die sie nicht kennen:

4

Hallo,

nein. Welche App benutzt du?

Wenn du QVR Pro verwendest (seit QTS 5.2.x), wird nur der Cache genutzt.

Mein TS-264 QTS 5.2.9.3451 hat kein Problem mit dem Puffer.

image
image1559×624 153 KB

Der Neustart war für das QTS-Update.

17:00 QVR Pro gestartet

image
image1175×567 56.5 KB

5

Entschuldigung, ich habe es dem Originalbeitrag hinzugefügt. Und für dich: „NAS-Nutzung: Containerstation Host → Nextcloud, Plex, Nginx, HomeAssistant, (+/-20 Container)“

Früher liefen dort auch GPU-intensive Container wie Viseron (NVR), CodeProjectAI, Wyoming-Whisper & Piper. Diese habe ich migriert, da sie als erste unter der Swap-Nutzung gelitten haben.

QBoost ist meines Wissens nach nicht in Gebrauch, da keine SSD vorhanden ist.
(Edit: Ich habe gerade nachgesehen, QBoost war nicht installiert, ich werde mir anschauen, was ich dort konfigurieren kann.)

6

Beim Cache entspricht das meinen Erwartungen, aber die Pufferauslastung hingegen nicht. Ebenso, dass das System beginnt, Swap zu nutzen, bis es zu einer Verlangsamung kommt.

7

Wird der Out-of-Memory-Killer jemals ausgelöst?

8

Es ist so (wenn mehr Swap verbraucht wird), dass Prozesse, die in den Containern laufen, beendet werden. Währenddessen bleibt der Puffer hoch.

Zurzeit passiert Folgendes mit QBoost:

image
image799×409 28.1 KB

Das verhindert zumindest, dass ein Neustart nötig ist. Ich werde das am Wochenende weiter beobachten und bestätigen, ob die Probleme erneut auftreten.

9

Ich würde ein Ticket eröffnen. Es könnten einige Zombie-Prozesse laufen, die nicht richtig beendet wurden und RAM belegen. So etwas habe ich schon einmal mit CPU-Zeit erlebt. Außerdem hatte ich Fälle, in denen Hybrid Mount plötzlich enorm viel RAM beansprucht hat.

Hier ist mein Vorschlag, was du sogar noch vor dem Eröffnen eines Tickets versuchen könntest: Ich würde HTOP in deiner SSH-Shell installieren. Das ist eine erweiterte Version des TOP-Tools und damit kannst du zum Beispiel die Prozesse nach ihrem Speicherverbrauch sortieren.

Identifiziere die Prozesse oder Apps. Stoppe dann im App Center diese Prozesse. Mache das für jeden einzelnen davon. Sobald alle Prozesse gestoppt sind, starte das NAS neu. Danach starte jede App wieder. Überwache anschließend deinen RAM-Verbrauch und prüfe, ob sich das Verhalten verbessert hat. Falls nicht, dann eröffne ein Ticket.

Ich mache diesen Vorschlag, weil ein einfacher Neustart lediglich alle aus dem Ruder gelaufenen Prozesse, die Ressourcen verbrauchen, wieder neu startet. Ein Neustart allein setzt sie nicht zurück. Du musst sie zuerst stoppen und dann neu starten.

QNAP weist dich vor einem Firmware-Update ausdrücklich darauf hin, das NAS neu zu starten, wenn es schon lange läuft. Diesen Hinweis würde ich ernst nehmen. Früher habe ich diese Meldung ignoriert und einfach das Firmware-Update durchgeführt. Nun, danach hat Hybrid Backup Sync angefangen, extrem viel CPU-Zeit zu verbrauchen. Zunächst sah alles in Ordnung aus, aber nach dem Neustart war es nur eine Weile gut und dann ging es wieder schief. In Zusammenarbeit mit QNAP habe ich diesen Trick entdeckt: App stoppen und dann neu starten. Das hat das Problem gelöst. All das ist nach einem Firmware-Update passiert.

Jetzt starte ich das NAS immer neu, bevor ich die Firmware aktualisiere. Das macht den ganzen Prozess zwar etwas länger, aber es scheint seltsame Probleme zu verhindern.

10

Ich werde unser internes Team bitten, das Problem nachzustellen. Dürfen wir außerdem fragen, ob Sie kürzlich neue Software installiert haben?

11

Ich glaube, ich habe einen weiteren Hinweis für dich.

Das Verhalten scheint mit installiertem QBoost stabiler geworden zu sein, der Puffer wurde reduziert und wird jetzt vom Cache übernommen.
Allerdings wächst der Swap-Bereich zunächst leicht an. Swap scheint sich fast nie zu verringern, es verlief folgendermaßen:

Tag 0 & 1: 0MB

Tag 2: 150MB

Tag 3: 250MB

Tag 4: 500MB

Tag 5: 800MB

Tag 6: 1400MB

Tag 7: 1700MB

Tag 8: 1600MB

Aktueller Stand jetzt, an Tag 8.

image
image1605×870 51 KB

Wie du sehen kannst, ist der Puffer immer noch groß, und ich glaube, ich verstehe jetzt, was sein Wachstum verursacht: USB-Datenträgernutzung.

Seit einem FW-Update konnte ich das entfernte QNap für HBS nicht mehr erreichen, als Übergangslösung habe ich ein USB-Laufwerk zum Backup angeschlossen.
Das war ein paar Tage vor dem Firmware-Update dieses Systems (niemals ohne ein richtiges Backup updaten).

Die NVR-Software hat das verschärft, da sie auch ihre eigene externe SSD verwendet hat (um die internen HDDs bei Lese-/Schreibvorgängen zu schonen). Seitdem das NVR verschoben wurde, ist das System nur noch einmal hängen geblieben, heute, aber nur für sehr kurze Zeit. Der Swap-Bereich war zu diesem Zeitpunkt ungefähr so groß wie auf der Abbildung, allerdings ließ sich das UI nicht laden, um das Cache-/Puffer-Verhältnis anzuzeigen.
Gibt es einen Konsolenbefehl, um das Verhältnis zwischen diesen beiden anzuzeigen? Dann könnte ich mich per SSH einloggen, um das Verhältnis zu prüfen, da ich vermute, dass der Puffer, der den gesamten Speicherplatz von Anwendungen und Cache beansprucht, solche Probleme verursachen könnte.

12

Nun, ich habe die Ursache für die Verlangsamung des Systems gefunden, und zusammen mit dem Rest der Probleme erklärt sich der Rest vielleicht von selbst:

Snapshots sind aktiviert, obwohl sie es eigentlich nicht sind.

Screenshot 2026-04-29 13.12.41
Screenshot 2026-04-29 13.12.411351×882 150 KB

13

Am besten stellst du die Sprache deiner Benutzeroberfläche von Niederländisch auf Englisch um, bevor du Screenshots in einem englischsprachigen Forum postest.

14

Guter Punkt.

15

Tritt dieses Problem weiterhin auf? Falls ja, erstelle bitte ein Support-Ticket und unser Support-Team hilft dir gerne weiter. Danke!

16

Das Problem wurde gefunden – letztlich war es eine Kombination daraus, dass HBS einen Snapshot erstellte (nicht vollständig auf der Festplatte), dem Indexieren der Ordnergrößen und der Tatsache, dass QBoost nicht installiert war.

Das Deaktivieren der Snapshots, wo es nötig war, und vor allem das Abschalten der Ordnergrößen-Indexierung haben den entscheidenden Unterschied gemacht.