RAM läuft mit neuer STORJ Version 1.56.4 und das System friert ein

Hallo zusammen,

habe mehrere STORJ-Konten auf einem unRAID-Server laufen und mit der Knotenverison 1.56.4 läuft der RAM leider voll und bei 100% friert das System ein. Wenn ich als Docker-Quelle eine ältere Version wähle wird die nicht installiert und es bleibt bei 1.56.4. Das Volllaufen geschieht auch leider sehr schnell, mehrere 10% in einer Stunde obwohl 16 GB RAM verbaut sind.

Eine hohe Speicherauslastung weist auf Probleme mit dem Datenträgersubsystem hin. Sie müssen die Festplatte auf Fehler überprüfen und diese beheben.
Der Storagenode verhält sich genauso, wenn Sie Netzlaufwerke verwenden.
Es geht nur um die Latenz, wenn sie hoch ist, wird mehr Speicher verwendet, besonders am Anfang, wenn der Filewalker läuft.
Je langsamer das Festplattensubsystem ist, desto schneller wird der Arbeitsspeicher verbraucht.

09:36:

10:07:

Wie @Alexey bereits schrieb: Wenn deine Festplatten langsam sind (SMR?) und die Anzahl der IO-Operationen nicht abarbeiten kann, wird dafür RAM als Zwischenspeicher verwendet - der dann, wenn die HDD nicht aufholen kann, irgendwann voll ist :wink:

BTW: Welchen VPN/VPS-Anbieter nutzt du, wenn ich fragen darf? :wink:

In unRAID > Docker kann man die Übeltäter ausfindig machen:

Da sind jeweils mehrere STORJ-Docker mit einem RAM-Verbrauch >1 GB. Klar das dieser dann bei 16 Knoten und 16 GM RAM voll läuft.

Ich probiere mal einen ChkDsk oder einen SATA-Kabeltausch. Weiß einer wie man den ChkDsk auf unRAID tätigen kann? Kenne das nur unter Windows, will aber die Festplatte (noch) nicht extra nur dafür abklemmen und neu anschließen.

Please avoid doubling content.

Habe die Festplatte nun doch an einen Win-Rechner angeschlossen und einen ChkDsk-Lauf getätigt. Reicht der aus oder braucht es einen ChkDsk/f-Lauf? Oder einen ganz anderen Lauf?

Die Festplatte ist eine praktisch neue WD 550 HC 18 TB Enterprise CMR. Die Schreibraten liegen auch im Normalen. Kann mir das ganze noch nicht ganz erklären und freue mich über weitere Hintergründe.

Da Sie NTFS unter Linux verwenden, hängt dies nicht von der Storagenode-Version ab, Linux ist mit NTFS nur langsamer und verwendet mehr RAM als benötigt. Je mehr Daten Sie haben, desto mehr RAM wird verwendet. Die einzige Lösung ist die Migration auf ext4. Leider ist dies vor Ort nicht gefahrlos möglich. Sie benötigen also eine ext4-Festplatte, um Ihre Daten mit dieser Anleitung zu migrieren: How do I migrate my node to a new device? | Storj Docs

1 Like

Vielen Dank schonmal für die Hilfe. Zahlreiche Knoten sind recht neu und erst vor wenigen Tagen eröffnet, da lohnt die Migration nicht und ich habe einfach neue aufgesetzt. Unglaublich wie schwach NTFS auf unRAID/Linux leistet, das hätte ich nicht gedacht.

Aber sollte XFS unter Linux nicht besser laufen? Es soll ja das schnellere Dateisystem sein, für allem für größere Dateien.

Warum genau nimmt man EXT4 und nicht XFS für Linux?

ext4 gibt es schon länger und wird von mehr Linux-Distributionen unterstützt und hat die wenigsten Probleme.
storagenode verarbeitet keine großen Dateien, das größte Stück auf einem meiner Knoten überschreitet nicht 4 MB. xfs bietet keine besonderen Vorteile gegenüber ext4 für storagenode.
Andererseits - wenn xfs das Standarddateisystem auf Ihrem Betriebssystem ist - können Sie es verwenden.

2 Likes

Jetzt da die Knoten wieder größer werden steigt auch der RAM-Verbrauch der neuen Knoten wieder an.

Aktuell liegt dieser bei 500 MB beispielsweise bei einem Knoten. Normal ist das nicht oder? Was kann man tun? Ich habe aktuell 5 Knoten auf einer 18 TB Festplatte am Laufen? Ist das zuviel? Können 2 Knoten auf einer Festplatte laufen oder wer hat praktische Langzeiterfahrungen?

In Anforderungen ein Knoten pro Datenträger.

1 Like