DSM 7.0 RAM läuft voll nach Umstieg auf DSM7 (DS415+ mit 8GB)

[adahmen]

Hallo Zusammen,

seit dem Umstieg auf DSM7 scheint bei mir langsam (aber sicher) das RAM voll zu laufen. Am Ende ist das System unerträglich langsam und nur ein Neustart hilft.

Meine Konstellation:
- DS-415+ mit 8 GB
- Surveillance Station mit 4 Kameras
- MariaDB10 mit einigen Datenbanken und vielen vielen Daten (von OpenHab, volkszaehler, webtrees, SBFSpot)
- Docker (mit Bitwarden, traccar)

Nach dem Neustart hat das System eine RAM-Auslastung von ca. 30%.
Nach 3 Tagen bin ich nun bei 41%.

Aufgefallen ist es mir vor 3 Tagen (da war der letzte Neustart), da das System extrem träge war - die RAM-Auslastung war bei 93%. Und wie gesagt hat nur ein Neustart geholfen.
Im Ressourcen-Manager konnte ich keinen Task sehen, der übermäßig viel RAM beansprucht hat. Auch Docker hat keinen Container mit unnormalem RAM-Verbrauch angezeigt.

Ist das Problem bekannt?
Wie komme ich dem Verursacher auf die Spur?

VG Albert

 

[adahmen]

Update zu diesem Thema:

Habe im traccar Forum nachgefragt und es scheint normal zu sein, dass bei einem offenen Port diese Angriffe stattfinden.
Da ich ein aktuelles Paket habe, sollte das kein Problem sein.

Zur Speicherauslastung: Inzwischen bin ich wieder bei 50% angekommen und ich gehe davon aus, dass es die Surveillance Station ist.
Im Thread zu DSM7 meine ich auch gelesen zu haben, dass dieser Effekt bei einigen Nutzern auftritt.
Löschen und neu anlegen der Kameras scheint wohl zu helfen. Werde ich wohl die Tage mal machen (müssen).

 

[adahmen]

Folgender Satz gehört nicht zu diesem Thema - bitte ignorieren. Gehört zu einem anderen Post

Habe im traccar Forum nachgefragt und es scheint normal zu sein, dass bei einem offenen Port diese Angriffe stattfinden.
Da ich ein aktuelles Paket habe, sollte das kein Problem sein.

 

[adahmen]

Ich würde das Thema gerne nochmal aufgreifen.
Inzwischen habe ich mich an den Synology-Support gewendet und die Antwort bekommen, dass es an einem nicht unterstützten 8GB Riegel liegen soll:
"Ihr System ist den Logs zufolge nicht in der Lage den jetzigen RAM korrekt anzusteuern und lagert die Aufgaben bereits auf den SWAP aus."

Ich verwende in meiner 415+ folgenden RAM-Riegel:

Crucial RAM CT102464BF160B 8GB DDR3 1600 MHz CL11​

Wie geschrieben hatte ich unter DSM6.x seit Jahren keinerlei Probleme - insofern bin ich doch sehr skeptisch, ob as am RAM-Riegel liegt.

Hat jemand eine DS-415+ mit 8GB schon unter DSM7 laufen? Gibt es ähnliche Probleme?
Wie kann ich feststellen, welcher Prozess sich mehr und mehr RAM zieht (dafür fehlen mir leider die Unix-Kenntnisse)?

 

[Fusion]

In der 415+ mit DSM 7 habe ich den Kingston ValueRAM 8GB 1600MHz DDR3L Non-ECC CL11 SODIMM 1.35V - KVR16LS11/8
Keine Probleme, nur wenige Backup Anwendungen installiert.

Den Crucial von dir habe ich in 2 der 216+, allerdings auch noch DSM 6.

Der Resourcen Monitor ist eine GUI Anwendung im DSM.
Will man auf der Konsole nachsehen, weil die GUI auch CPU/RAM frisst, wäre der Einstieg ein einfaches 'top' (eventuell vorher per 'sudo -i' zu root wechseln).

 

[adahmen]

Welche RAM-Auslastung hast Du denn nach dem Start der 415+?

 

[Benares]

Also meine DS415+, mit 8GB RAM bestückt, braucht im Schnitt so ca. 14% davon. Der Rest wird für Buffer/Cache genutzt. Allerdings laufen da auch keine speicherintensiven Anwendungen wie VMM oder Docker.
Wenn da irgendein Prozess im Laufe der Zeit Speicher frisst, müsste das doch ganz leicht über den Ressourcen-Monitor herauszufinden sein.
Auch "top" bietet die Möglichkeit, die Prozessliste nach Speicherverbrauch zu sortieren.

Edit:
Mein RAM ist übrigens der gleiche wie deiner - und läuft problemlos seit 2015.

 

[adahmen]

Tja, leider liefert der Ressourcenmonitor keinerlei Hinweise auf diesen hohen Verbrauch.
Über top habe ich es versucht - aber leider habe ich es noch nicht geschafft die Angaben richtig zu interpretieren. Zumindest war für mich nichts direkt auffällig.

Ich habe inzwischen eine weitere Antwort vom Support bekommen. Hier einige Auszüge:

DSM 6 ist ein relativ zu DSM 7 Ressourcenanspruchsloses Betriebssystem. Es birgt einige Features mehr, welche allerdings auch Ressourcen kosten.

Der von Ihnen verbaute RAM war unter DSM 6 glücklicherweise in der Lage die Menge an Daten zu verarbeiten. Er war zwar inkompatibel, aber konnte die Daten schnell genug verarbeiten als dass ein Datenstau entsteht.

Dadurch, dass Sie inkompatiblen RAM verwenden, kann ein relativ großer Teil des von Ihnen verwendeten RAMs nicht angesteuert werden. Sie nutzen nicht die von Ihnen eingesetzten 8GB RAM. Leider weit aus weniger.

Wenn Sie den originalen RAM einsetzen, wird Ihr System allgemein langsamer sein, aber es kann der RAM komplett angesteuert werden.

Wenn die Aussagen stimmen, wird es wohl keine Lösung mehr geben - denn mit 2 GB komme ich leider nicht hin.
Sind die Aussagen nachvollziehbar? Kann man testen, ob das RAM genutzt werden kann oder nicht?

 

[Benares]

Sind das "Dummschwätzer"
Welches ist denn der speicherintensivste Prozess bei dir? Wie wär's wenn du mal ein paar Screenshots lieferst oder alle "exotischen" Pakete einfach mal stoppst?

 

[adahmen]

Also, hier ein paar Screen-Shots:











Und dann noch top:

 

[Benares]

Na, da würde ich zunächst mal auf die SS tippen. Aber benutze mal "htop", da kannst du mit F6 auch nach Memory sortieren (mit "top" geht sicher auch, aber ich hab dafür die Tastenkombination grad nicht parat)

Edit: Oder doch - bei "top" ist es Shift-M.

 

[adahmen]

Ich habe Surveillance Station mal gestoppt und nochmal geschaut:



Sehe ich das richtig, dass der Prozess mit der ID 22869 mehr als 20 GB an Speicher belegt?

 

[Fusion]

Einfach bei 'top' auf F6 drücken, hoch/runter das Sortierkriterium und Enter drücken.
Gerade nach Memory sortiert sollte es dann nicht mehr so sprunghaft sein wie nach CPU.

Spannend wird es jetzt, wenn du in ein paar Tagen vergleichst, wenn es erst über die Zeit voll läuft.

%MEM ist real, das andere VIRT virtueller Speicher.

Die Frage ist, was ein "dotnet" Prozess auf der DS verloren hat.
Hast du da was in der Richtung installiert, weil man auch Microsoft mssql sieht?

Dass der Linux Kernel keine Probleme hat den RAM zu nutzen sieht man ja an der Belegung und genutztem Pufferspeicher.

 

[Benares]

Sehe ich das richtig, dass der Prozess mit der ID 22869 mehr als 20 GB an Speicher belegt?

Gut aufgepasst, ich hätte jetzt eher nach der Spalte %MEM geschaut.
Starte mal "top -o VIRT". Jetzt müssen wir nur noch rausfinden, was der Prozess "dotnet" macht und wozu der gehört. Bei mir läuft der nicht.

Edit: dotnet scheint zu Docker zu gehören, wenn da ein .Net-Container läuft

 

[adahmen]

Und hier sortiert nach Memory (weiterhin ohne Surveillance Station):



Ich werde nun mal 2-3 Tage die Surveillance Station aus lassen und schauen ob sich die Speichernutzung wieder aufbaut

Oder sieht jemand weitere Hinweise auf den "Täter" ?

 

[adahmen]

Hier das Ergebnis von "top -o VIRT"




Ich denke das ist Bitwarden. Das läuft bei mir unter Docker.
Aber wie schon geschrieben - Bitwarden nutze ich seit Jahren lokal auf der 415+ - und das bisher immer ohne dieses Problem.

Ich habe Bitwarden eben mal gestoppt - dann stieg der freie Speicher wieder an. Und dann wieder gestartet.
Aktuell liege ich bei einer RAM-Auslastung bei 39%.

 

[Fusion]

Welches Image nutzt du?
Ich nutze bitwardenrs bzw vaultwarden.
Da ist nix mit dotnet/mssql und in /opt/ ebenso wenig.

Aber ja, dein Screenshot legt das nahe. Original bitwarden Docker Image?

 

[Benares]

Inzwischen tippe ich eher auf Docker und wohl auch auf Bitwarden. Stopp den Container doch mal.

Edit:
Ich benutze Docker nur testweise, ist auch neu für mich. Aber mit Bitwarden hab ich auch schon gespielt. Mit "bitwardenrs/server:latest" läuft da kein dotnet-Prozess und der Speicherverbrauch ist eher unauffällig.

 

[adahmen]

Ja, ich setze auf das Original Image (wie von Start an). Unter DSM6 war das absolut kein Problem - über Jahre.

Bei einem solch kritischen Thema (wie Passwörter) würde ich ungerne nicht das Original einsetzen.

 

[adahmen]

Hier die Übersicht ohne Bitwarden und weiterhin ohne SurveillanceStation: