mgutt

Du meinst nicht "drosselt", sondern "unterbietet"? Ja tut er und zwar deutlich. Du hast mit die ineffizienteste AMD Generation erwischt (alter Chipsatz und alte CPU). Ich habe zb ein Gigabyte C246N-WU2 mit einem Xeon E-2146G und komme da mit 8 schlafenden HDDs auf 18W, wobei die alleine 8W ausmachen dürften. Wichtig ist ein sparsames Board zu finden. Erfahrungsgemäß ist zb ein Gigabyte ITX oder mATX mit 1151v2 Sockel sehr sparsam. Hier eine Messung von meinem Board ohne alles und mit einem i3: Und hier von der mATX Variante: https://www.hardwareluxx.de/community/threads/die-sparsamsten-systeme-30w-idle.1007101/page-68#post-28446459 Und ein i7 zieht im Leerlauf max 2W mehr durch die höhere Anzahl aktiver Kerne. Mit dGPU kommt der im Link beschriebene Overhead dazu. Aber selbst dann sollte der Server mit schlafender VM nicht die 30W überschreiten. Gemessen hat es noch keiner, aber ich denke ein Gigabyte H370M ist auch sehr sparsam.

Ich verstehe nicht wirklich das Problem. Geht der Container bei einem Update ständig kaputt oder warum ist ein "Major Update" so ein Problem? Ich würde einfach regelmäßig ein Backup machen und wenn nach einem Update was nicht geht, eben wieder zurück gehen und per tag die Version des Containers so lange fixieren bis der Fehler vom Entwickler behoben wurde. So gut wie kein Container besitzt eine interne Backup-Funktion, warum sollte man also die von ioBroker benötigen?

OK, ich dachte du sprichst vom Minisforum. Dann kannst du das mit dem geringen Verbrauch tatsächlich abhaken. Eine dGPU frisst im unRAID Server 24/7 Strom, egal ob die VM läuft oder nicht. Die Frage ist welcher Verbraucha akzeptabel ist. Ich favorisiere nach wie vor einen Gaming PC und einen separaten unRAID Server.

Ja "Nur"? Guckst du: https://www.hardwareluxx.de/community/threads/die-sparsamsten-systeme-30w-idle.1007101/ Verwechsle auch nicht TDP mit dem Verbrauch im Leerlauf. Du willst also mit der iGPU zocken? Gerade durch die begrenzte TDP wird die CPU ständig gedrosselt. Dadurch ist der i5-10210U viel langsamer: Als zB ein i3-9100:

Meistens inkompatibler RAM oder inkompatible NVMe.

Jedes Dateisystem hat Vor- und Nachteile. BTRFS hat als Copy on Write Dateisystem den Nachteil der Write Amplification. Es wird also deutlich mehr geschrieben als "notwendig". Das geht zu Lasten der SSD Haltbarkeit. Hat man hochwertige SSDs oder genug Kohle in der Tasche, ist das einem vermutlich egal. Ein weiterer Nachteil von BTRFS ist dessen Empfindlichkeit bei Stromausfall. Das kann einem sogar das ganze Volume zerschießen. Mit einer USV und/oder regelmäßigem Scrub kann einem aber auch das egal sein. Bei XFS hat man wiederum das Problem, das man damit kein RAID aufsetzen kann. Es fehlt also die Ausfallsicherheit bei Defekt. Was für dich nun Grund dafür war auf XFS umzustellen, weißt du nur du 😉 Korrekt. Ich glaube auch nicht, das es am RAM liegt. Nein Config Editor installieren und dann über Tools den Befehl in die "go" Datei packen. Diese Datei wird beim Start von Unraid ausgeführt. Glaube ich nicht. Wenn ein Fenster beim Bewegen ruckelt, gibt es meiner Ansicht nach nur zwei Optionen: 1.) Die GPU Leistung stimmt nicht (in dem Fall also die virtuelle GPU berechnet durch die CPU) 2.) Die Netzwerk Leistung stimmt nicht Letzteres könntest du schon mal testen, in dem mal eine direkte Verbindung testest. Also PC und Server ohne Switch direkt verbinden (beide müssen dann logischerweise eine feste IP besitzen). Außerdem ließe sich das System entlasten, in dem Du so einen USB 3.0 LAN Adapter verwendest (oder eine LAN Karte) und die dann an die VM durchschleifst: https://www.amazon.de/Anker-Gigabit-Ethernet-Netzwerkadapter-Ultrabook/dp/B00NPJV4YY/ Damit fiele schon mal die komplette Virtualisierung für das Netzwerk weg, was ja auch noch mal die CPU entlastet. Teste bitte auch mal die Workstation alleine ohne Kerne zu isolieren. Also gib der Workstation testweise mal alle Kerne. Bitte beachte, dass du Windows dann richtig herunterfahren musst (Schnellstart deaktivieren). Ansonsten kann es sein, dass Windows die neuen Kerne verpeilt. Ach ja noch was. Nutzt du Energiesparmaßnahmen wie zB den CPU Governor Powersave (zB über das Tipps & Tweaks Plugin)? Der wäre auch ein Grund für solche Probleme. Immer Performance verwenden.

Dann verteile den Share so, dass bestimmte Unterordner nur auf einer Disk landen und mach aus dem einen rsync Kommando mehrere, die mit einem entsprechenden zeitlichen Abstand einen Unterordner nach dem andern syncen. Also /mnt/disk1/Filme/A bis M und /mnt/disk2/Filme/O bis Z Das Hauptproblem von deinem Server ist, dass dein SSD Cache zu klein ist. Wenn du zb pro Tag 5TB neue Daten auf den Server schaufeln musst, dann sollte dein SSD Cache aus 2x 8TB NVMe oder 3x 4TB NVMe bestehen. Wie bei mehr RAM ist das Problem nicht der Wille, sondern das Budget. Das kann man ja nachvollziehen, nur sich über das Betriebssystem selbst beschweren (weil man "nicht ordentlich kopieren kann), ist dann ja auch nicht richtig. Das unRAID Array ist nun mal lahm und das liegt nicht an der Software, sondern an den HDDs, die mit parallelem Lesen und Schreiben einfach nicht gut klarkommen. Ach ja noch was. Du könntest wenn das finanziell besser passt, bei sehr großen Shares auch einen HDD Pool als Cache davor setzen. Es müssen ja nicht zwangsläufig SSDs sein. Je nachdem wie dein Backup aufgebaut ist, könnte man 1:1 Backups auf diesem Pool belassen und nur alte Backups ins Array schieben. Dann hätte man wieder eine Trennung nach Hot und Cold Storage und vor allem könnte dein Array endlich wieder ohne Reconstruct Write besonders energie-effizient arbeiten.

Die Frage ist eher ob du so oft 10GB auf den Server schiebst wie jetzt mit dem Benchmark getestet. Auch die Frage wie viel RAM du verbaust und mit einem normalen Dirty Ratio Wert zb alleine über den RAM eine hohe Performance ermöglichst. Die 1TB ist sicher besser als Parity. Auch bei 250GB im Array. Umso schneller die Parity, umso besser.

Network.cfg löschen hilft auch. Siehe auch hier: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-1008640

Damit sollen eher Schulen, Unis, größere Unternehmen oder Unraid-Entwickler angesprochen werden. Ich mein wo bekommt man schon Rabatt, wenn man 2 statt einem Produkt kauft. Ich habe zb schon drei gekauft. Dann will ich auch Geld zurück haben ^^

Nutzt du bei rsync "--inplace"? Weil die Option sorgt erst dafür, dass die bestehende überschrieben wird (dann würde er in jedem Fall auf die Disk im Array schreiben). Standardmäßig erstellt rsync eine temporäre Datei im Ziel (mit Cache Yes also auf der SSD) und verschiebt die dann. Eventuell mal "--delete-before" testen, falls er trotz Cache Yes auf die Disk schreibt?! Wie viel RAM hast du verbaut? Verbau so viel wie geht und stell dirty_ratio auf sagen wir mal 70%. Und nun kommt Trick 17. Du rechnest aus wie schnell rsync braucht um dirty pages zu füllen. Sagen wir mal es wären 20GB und du hast eine 10G Verbindung, also 1GB/s. Ein bisschen Puffer eingerechnet, killen wir rsync nach 19 Sekunden: timeout 19 rsync src dst Danach ein sleep, der genug Zeit lässt die Dirty Pages zu leeren (also wieder ausrechnen wie lange es braucht 19GB aufs Array zu kopieren) und dann die Schleife von vorne beginnen bis die Rückgabe von rsync erfolgreich war. Oder weniger kompliziert einfach ein Bandbreitenlimit bei rsync einstellen, dass langsam genug ist, dass er niemals parallel in den RAM und auf die Disk schreibt. Da er ja die Dirty Pages nach X Sekunden leert, müsste man ausrechnen wo der Sweetspot liegt. Sagen wir dein freier RAM erlaubt 20GB Dirty Pages und dein Array kann ohne das parallele Schreiben 80MB/s wegschreiben. Würde man rsync nun auf 80MB/s limitieren, würden die Dirty Pages nie überfüllen. Stellt man es aber auf 160MB/s, würden sie parallel ja mit 80MB/s geleert. Wenn ich jetzt keinen Denkfehler habe, müsste man also alleine dadurch die Dirty Pages "verdoppeln". Bei der Erstbefüllung kann man das ja auch machen, aber du wirst du sicher nicht im regulären Betrieb ständig 10TB draufschieben oder doch? Falls ja, dann ist der Pool dein Weg und nicht das Array. 40 bis 80 MB/s ist normal beim Array. Bleib bitte mal ernst oder willst du mir jetzt damit sagen, dass dein Array aus 16x 10TB besteht und du so große Shares regelmäßig (also nicht Erstbefüllung) abgleichst, dass einzelne Shares niemals auf nur eine 10TB Platte passen?!

Ich habe den offiziellen manuell angelegt. Bei Bedarf kann ich den mal bei den unRAID Apps bereitstellen.

Plex gleicht über den Ordner- / Dateinamen ab. Daher immer sauber benennen wie zb Filme/D/Das Dschungelbuch (1967)/Das Dschungelbuch.mkv Wer sich daran hält, hat in der Regel eine Erkennungsquote von 99 bis 100%. Plex legt keine Daten in dem Filmordner ab, sondern speichert alles in internen Verzeichnissen / Datenbanken. Aus dem Grund ist mein Filmordner auch nur lesend eingebunden.

Die CPU wäre sparsam, aber das Mainboard nur, wenn es ein B550 ist. Andere AMD Chipsätze sind wohl hungriger. Bei Intel ist das einfacher. Da ist eigentlich alles mit DDR4 RAM sparsam, also ab der 6ten Generation. Preislich attraktiv finde ich gebrauchte B365M oder H370M Boards mit einem Pentium Gold oder i3. Eine sparsame GPU wäre eine GTX 1050 Ti. Ist jetzt allerdings kein Leistungsmonster. Die RTX Karten legen leider keinen Wert auf Sparsamkeit: https://www.techpowerup.com/review/nvidia-geforce-rtx-3060-ti-founders-edition/31.html Passt jetzt nicht in deinen Mini PC, aber wenn du eine normale CMR Platte als Parity nutzt, kannst du die SMR Platten auch problemlos im Array weiternutzen.

Wie ist denn die Performance der Workstation, wenn die anderen VMs nicht laufen? Und der virtio Grafiktreiber ist aktiv? Siehst du ja an der besseren Auflösung.

Warum schreibst du auf mehrere Platten parallel? Hör auf deinen Share auf mehrere Platten zu verteilen, dann unterbindest du diesen Effekt auch. Dann benutzt du Unraid aber auch einfach "falsch". Das Array ist ein "Cold Storage". Auf dem schreibt man nicht ständig herum. Wenn Du auf HDDs ständig schreiben willst, solltest du einen Pool mit HDDs erstellen und dort deinen Share ablegen. Ansonsten verstehe ich ehrlich gesagt dein Problem nicht. Lass das Array doch so lahm sein wie es will. Soll der Mover doch nachts auf das Array so lahm und kompliziert schreiben wie er will. Kann dir doch herzlich egal sein, wenn du im RAM/SSD Cache unterwegs bist. Mag sein, aber das wirst du in Unraid vermutlich nicht beeinflussen können, da Unraid User Shares per FUSE mountet und Disk-Mounts haben ja eine ständige Abhängigkeit zur Parity. Da müsstest du also an den Wurzeln von Unraid rumfummeln und dieser Code ist sowieso Closed Source. Die Performance wird dadurch auch nicht besser, sondern massiv schlechter. Selbst schon getestet in dem ich Dirty Pages auf Null gestellt habe. SMB schreibt dann ja jeden Chunk einzeln. Selbst SSDs brechen dann massiv ein. Das ist auch immer noch so. Erst vor ein paar Tagen festgestellt und mich noch gewundert, warum mein Upload auf den Server so lahm war als ich eine Datei überschrieben habe ^^ Wie hast du dieses Verhalten ausgelöst. Über SMB? Das sollte eigentlich nicht passieren. Ansonsten kann ich dir nur mehr RAM und mehr Write Caching ans Herz und nicht das Gegenteil davon. Auch in diesem Video thematisiert: Ich lade so problemlos 30GB an Daten mit 1GB/s direkt auf das Server-Array. Dateien, die regelmäßig verändert werden, hält Linux auf die Art auch im RAM vor. Die werden also gar nicht mehr von der HDD geladen. Was dann danach passiert, also wenn Linux die Dateien aus dem RAM auf die HDDs schreibt, kann mir herzlich egal sein. Das bemerke ich ja nicht.

Stimmt. Bei 112 € macht ja schon fast eine neue Plattform mehr Sinn. Ein i3-8100 für 50 € und ein H370M für 50 €. Fehlt nur noch der RAM und schon ist man auf drei Ecken effizienter unterwegs.

NPM ist NPM und nicht SWAG, wo du die Config Dateien selbst bearbeitest. NPM nutzt die folgenden Standardregeln: cat /etc/nginx/conf.d/include/proxy.conf add_header X-Served-By $host; proxy_set_header Host $host; proxy_set_header X-Forwarded-Scheme $scheme; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; proxy_pass $forward_scheme://$server:$port; Außerdem sind in der config Datei von einer Domain noch diese Einstellungen zu finden, wenn man Websockets aktiviert hat (sollte man für Jellyfin aktivieren): proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; Im Vergleich zu Jellyfins Dokumentation fehlen also diese Optionen: proxy_set_header X-Forwarded-Protocol $scheme; proxy_set_header X-Forwarded-Host $http_host; proxy_buffering off; Falls die wirklich wichtig sein sollten, könnte man die in NPM über die Advanced Settings einer Domain ergänzen.

Du hast zwei Pools? Du weißt schon, dass du dann keine Ausfallsicherheit hast? Siehe auch: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-951565 Ein Intel System wäre für dich eindeutig die bessere Wahl gewesen: https://forums.unraid.net/topic/108650-plugin-intel-gvt-g/ Wo liegen die VDisks? Prüfe, in dem du bei den Shares rechts auf den Ordner klickst. In der Spalte "Location" steht ob sie auf dem Cache oder der Disk 1 liegen. Gerne auch Screenshots posten. Mit der selben Hardware und da haben sich die Workstation und die Server auch die selben Kerne geteilt?

Klingt alles ziemlich komisch. Man installiert sich den DuckDNS Container um die IP aktuell zu halten. Danach gibt man im Router die Ports 80 und 443 so frei, dass der Traffic bei NPM landet. Dann fügt man die DuckDNS Domain in NPM hinzu und im selben Assistenten bestellt man das SSL Zertifikat. Als Ziel trägt man den Port und IP vom Jellyfin Container ein. Was du da mit der config meinst, verstehe ich genauso wenig wie dein bereits erstelltes Zertifikat?! Siehe auch:

Ja, aber das gilt nicht für die Dateien auf dem Cache: https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-951565 Ich weiß nicht wie es bei den Firecuda ist, aber was ich so von den 2.5 Zoll SMR gelesen habe, ist das von der Performance her eine Katastrophe. Das ist ziemlich kontraproduktiv. Eine NVMe kann dank PCIe X4 über 8 Kanäle (4 Lanes) parallel Lesen und Schreiben. Bis USB2 gab es nur einen Kanal, also nur Schreiben oder nur Lesen im Wechsel und seit USB3 gibt es 2 Kanäle, also Lesen und Schreiben gleichzeitig (Voll-Duplex). Allerdings ist das immer noch Äonen von 8 Kanälen entfernt. Und gerade bei einer VM will man ja die beste Performance oder nicht? Bedenke auch, dass nur wenige USB Adapter alle ATA Befehle durchschleifen. Wir haben immer wieder Bug Meldungen, dass die Platte wach ist und Unraid davon nichts erfährt oder dass Unraid die Platte schlafen schickt, aber dieser Befehl nicht verarbeitet wird. Ich hatte zB mal einen NVMe Adapter, da hat die NVMe beim Nichtstun förmlich geglüht. Ich würde eine ausreichend große NVMe nehmen wo alles drauf passt und regelmäßig ins Array sichern.

C7 musst du schon einstellen. Aktuell erreichst du gar keinen C-State. Links das Package ist wichtig, nicht die Kerne. Allerdings hast du so viel Last auf den Kernen, dass das auch logisch ist. Zwei Kerne stehen auf 40% active. Das Package kann C2 usw erst erreichen wenn die CPU nichts macht.

Ups vertippt ^^

Gibt es sowas noch im 21ten Jahrhundert? 😅

Ja. Kann auch eine separate Hardware sein. Du kannst zb auch Cloudflare als Reverse Proxy nutzen. Dann steht der im Internet vor deiner Firewall.