Torben

Members
  • Posts

    53
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Torben's Achievements

Rookie

Rookie (2/14)

4

Reputation

  1. That's also my plan, the Pi4 with OpenWRT is already prepared. The sad thing about this is that it was working flawlessly with 6.8.3 and something somewhere somehow broke the functionality starting with 6.9. But well, because of that I started looking at OpenWRT and got something new to tinker with.
  2. Me too. And even NFS speed over wireguard got worth running at about 60% of the speed it was before. So I tried to find a workaround and installed an Ubuntu VM with the folders mounted via mount-tags on the receiving unRAID server, which I found out causes the problem (even a fresh installed test server on different hardware on 6.8.3 works, same server on 6.9+ shows the problem). So far it's working great for a couple of weeks now. In the beginning I wanted to do some more investigating on why it works in the VM - or if I can replicate the problem in the VM -, since I think having a VM just for doing what the host was/should be capable of is "a bit" unnecessary, but well, a lot of time spent and no real idea left where to continue. I'm curious what happens when you have new hardware.
  3. Ich habe das Ganze jetzt nochmal auf dem Testserver mit 6.10.0-rc1 probiert und das Problem tritt auch dort auf. Durch das Begrenzen der Geschwindigkeit per --bwlimit kann man es verzögern, aber im Endeffekt ist es das gleiche Resultat.
  4. Die beiden neuen Videos (6.8.3 und 6.9.2) sind nun auch da. Den Verschlucker in der 6.8.3 habe ich in der Timeline markiert. 6.8.3: https://youtu.be/UBZm8w79oKw 6.9.2: https://youtu.be/yDiTijYkVSA
  5. Hups, Hälfte vergessen. Ich synce beim Testen eine große Datei, rsync holt über SMB ab. Wobei ich auch schicken als Workaround probiert hatte, wo es nur länger dauerte, aber auch zum Problem führte. Hier habe ich aber nicht getestet, ob es mit 6.8.3 funktioniert. Rsync-Parameter: -av --human-readable --progress
  6. Korrekt, keinen Cache. Ich missbrauche meinen "Gaming Computer" als Test-Server und konnte nur eine nVme freischaufeln. Geschwindigkeit ist eigentlich auch wurscht, da der Durchsatz per iNet kommt. 🙂 Ach ja, das Wireguard-Plugin habe ich natürlich auch installiert. Verbindung ist "Remote access to server" und die MTU habe ich auf 1280 runtergesetzt. Wobei es bei 6.8.3 als Receiver auch mit "Auto" geht (das ist ja 1500-80), aber da ich das bei jeder Verbindung so habe, eben auch hier. Ansonsten keine Veränderungen.
  7. Das hatte ich schon mal (mit großen Bauchschmerzen) auf meinem Haupt-Server probiert und war froh, dass das Hin- und Herspringen problemlos funktionierte. Der Transfer allerdings funktionierte nicht sauber, sprich wie bei 6.9.2. Ich kann das aber gerne nochmal auf dem Test-Server durchführen. Ansonsten geht mir die ganze Zeit durch den Kopf, dass beide Server Intel I219V onboard NICs nutzen und hier vielleicht ein Treiberproblem vorliegen könnte? Nur eine Vermutung, basierend auf "Das hat was mit der Netzwerkverbindung zu tun". 🙂
  8. Der Sender (mein Haupt-Server) ist ein 6.9.2er unRAID mit verschlüsseltem Array und Cache. Nur der Vollständigkeit halber erwähnt, ich glaube derzeit nicht, dass der Sender relevant ist. Der Receiver (mein Test-Server) hat keinerlei Verschlüsselung oder ähnliches, nur eine nVme als Array-Disk. Verschlüsselung etc. habe ich extra weggelassen, um zu schauen, ab welchem Schritt das Problem auftritt. unRAID 6.9.2 installiert, Community-Apps installiert, Nerd Tools installiert (für Tmux, iotop etc.) und mittlerweile auch Unassigned Devices inkl. Plus installiert (da das Problem auch ohne auftritt). PS: Auf dem Test-Server kann ich anstellen was ich will, wenn es den zerlegt mach ich ihn neu. Der hat keinen anderen Auftrag, als das Problem zu analysieren. 🙂
  9. Soderle, ich habe nun eine weitere Testrunde gefahren und den Test-Server (Receiver) auf 6.8.3 downgegradet (/boot/bz*-Dateien mit denen aus dem 6.8.3-DL überschrieben...hatte das Vorgehen im unRAID-Forum gefunden). Und siehe da, es funktioniert wieder - zumindest ohne den Kollaps. Zwar vereinzelt mit Einbrüchen wie sie bei 6.9+ auftreten, allerdings fängt sich das Ganze innerhalb von ein paar Ticks wieder...daher ist uns das vorher auch nicht aufgefallen (das gute alte "Fire and forget"-Problem 🙂). Die CPU-Last ist ein wenig höher, bei der Download-Geschwindigkeit komme ich auf 200+ MBit anstatt 450+ MBit, aber das kann auch an meiner INet-Verbindung zuhause liegen, die ist heute zickig. Daher hatte ich das Ganze auch nochmal direkt hintereinander mit 9.2 durchgeführt und hatte die gleichen Probleme wie vorher. Die Videos werde ich sichten und auch hochladen, das dauert aber noch ein wenig. Vorab: Wäre es möglich einzelne Komponenten von unRAID zu aktualisieren, um den Auslöser weiter eingrenzen zu können (ich würde die Change-Logs durchgehen)? Sprich z.B. ein Update von Samba durchzuführen, den Rest aber zu lassen wie er ist? Oder würde das, selbst wenn es geht, wenig Sinn machen, weil alles ineinander verwoben ist?
  10. Erst einmal Entschuldigung für die lange nicht erfolgte Rückmeldung. Irgendwo ist irgendwas schief gelaufen und ich konnte mein Windows nicht mehr booten (nein, ich habe nicht die falsche nVme gemountet 🙂 ). Wurscht, nu ist alles neu und gut. Da mir nach der Wiederaktivierung des Write Caches aufgefallen ist, dass mein Geschreibsel oben ...Blödsinn?... ist, habe ich nun ein paar Videos mit htop (Shift-K), top, iotop und unRAID-Dashboard (CPU + Network) gemacht, um das Problem zu zeigen. Vielleicht kann ja jemand etwas daraus ablesen oder mir einen Tipp geben, was ich analytisch noch machen könnte. Der für mich einzige Anhaltspunkt, was die 100% Core-Last im "Fehlerfall" erzeugt, ist der Netdata-Docker, der zu dieser Zeit 99%+ iowait auf dem entsprechenden Core anzeigt. Vielleicht könnte man darin sehen was es erzeugt, aber bei der Masse an Daten bin ich im Moment bisschen überfordert. Leider hatten sich meine Videoschnitt-Programme dazu entschieden aus meinen zusammengeschnittenen Aufnahmen unlesbaren Brei zu machen, daher gibt es eine Youtube-Playlist (sollte das nicht erlaubt sein, bitte löschen oder bescheid geben):
  11. Das hat sich doch schon wieder gelohnt. Ich habe top immer nur genutzt, weil man halt alle Prozesse sehen kann...ja, nee, mal googlen wie das in htop geht war zu schwer. Auch die Info bez. des Dashboard-Loads ist Gold wert, jetzt kann ich 2 Kopfschmerztabletten weniger nehmen, weil die angezeigte Last nun endlich Sinn macht. 😄 Ich habe die beiden Dinge kombiniert und da es ein Test-Server ist (warum bin ich darauf nicht früher gekommen...), habe ich die Dirtypages gleich mal auf 0 gesetzt. Begonnen habe ich mit XFS für den Cache (Array ist immer XFS) und dachte mir, dass das Mounten der externen Verbindung auf dem Array vielleicht Sinn macht, wenn ich auf den Cache schreibe. 1. Auf /mnt/disk1/dir (USB HDD) gemountet und /mnt/cache/dir1 (nVme) geschrieben: Ca. 50-120 MBit - 2 rsync-Prozesse, die in Summe ~96% IO ergeben (es schreibt aber immer nur einer, wechseln sich ab), ab und zu nur 1 Prozess mit 96% IO (der andere hat 0%), wechselt aber wieder auf 2 Prozesse. Die CPU-Last (i9-9900K) ist recht hoch, alle Cores springen wild herum, aber das Problem tritt nicht auf. 2. Auf /mnt/cache/dir gemountet und /mnt/cache/dir1 geschrieben: Ca. 50-190 MBit - starkeres Springen der Geschwindigkeit (vermutlich durch Lese-/Schreibvorgänge, die ja nicht mehr durch den RAM glattgebügelt werden), Rest ist gleich, das Problem tritt nicht auf. Dann kam BRTFS für den Cache. 1. Auf /mnt/disk1/dir gemountet und /mnt/cache/dir1 geschrieben: Geschwindigkeit 14-22 MBit - Es werden wieder 2 rsync-Prozesse gespawnt, aber Prozess 1 zeigt sich dominant, erzeugt dauerhaft 96-99% IO, Prozess 2 wird gespawnt, tut gem. iotop gar nichts und danach nur sehr, sehr sporadisch etwas, gem. htop zeigt er minimale (aber stetige) CPU-Last. Das Dashboard zeigt über mehrere Sekunden Last auf einem Core von 100%, die dann auf einen anderen Core überspringt und dort einige Sekunden verweilt, bevor es weiter geht. Während ich das hier geschrieben habe ist die Geschwindigkeit auf 4 MBit gefallen, das Dashboard zeigt weiterhin 100% wechselnd auf einem Core (htop "nichts"). In iotop ist es allerdings ruhig (alles ~0%), bis - passend zum Core-Wechsel im Dashboard - beide rsync-Prozesse gleichzeitig nach oben springen...Prozess 1 mit 99,99%, Prozess 2 mit 17-61% und nach der nächsten Aktualisierung von iotop ist ggf. Prozess 2 noch mit 5-20% da, je nachdem wie hoch seine IO vorher war. 2. Auf /mnt/cache/dir gemountet und /mnt/cache/dir1 geschrieben: Gleiches Bild wie bei BTRFS 1. 3. Auf /mnt/cache/dir gemountet und /mnt/disk1/dir geschrieben: 15-40 MBit - 2 rsync-Prozesse, Prozess 1 mit 96-99,99% IO dominant und daueraktiv, Prozess 2 verpieselt sich auch gleich und tritt auch hier sehr, sehr sporadisch in Erscheinung. Der Unterschied zum Schreiben auf /mnt/cache ist, dass ein Core im Dashboard zwar immer noch deutlich stärker belastet wird (65-100%), aber er bleibt nicht bei 100% hängen und der Wechsel der Cores passiert auch mit einer deutlich höheren Frequenz. Das Problem, dass das Ganze "hängen" bleibt und die IO auf 0% absinkt und die beiden rsync-Prozesse zeitgleich IO erzeugen (und die Geschwindigkeit einstellig abfällt), tritt hier nicht auf. Prozess 1 bleibt dauerhaft mit 96-99,99% aktiv. 4. Auf /mnt/disk1/dir1 gemountet und /mnt/disk/dir geschrieben: Gleiches Bild wie bei BTRFS 3. Da ich jetzt so richtig hart verwirrt war, dass egal wie bei BTRFS formatiertem Cache nur 1 rsync-Prozess IO-aktiv war, habe ich vorsichtshalber den Cache nochmal als XFS formatiert und es waren wieder 2 rsync-Prozesse IO-aktiv, wie oben beschrieben. Das macht mich alles fertig, ich hoffe Du kannst daraus irgendwas sinnvolles stricken. Da ich diese und nächste Woche Urlaub habe, kann ich gerne noch ausgiebig testen, Analyse-Tools installieren, was immer...aber gedanklich bin ich grad raus - das ist für mich zu tief in Linux/Dateisystemen etc. und unlogisch des Todes (weil ich halt mangels Wissen/Ideen nicht den Schimmer habe warum es auftritt). Vielleicht schaffe ich noch was zu ergooglen, wenn ich wieder weiß auf welchem Planeten ich gerade bin. Aber vielen, vielen Dank schon mal für Deine Hilfe...dass es mit BTRFS zu tun haben könnte, da wäre ich im Leben nicht drauf gekommen.
  12. So, ich habe nun noch ein bisschen mit meinem eigenen Server weiter getestet. Ich bin zwar fast genau so schlau wie vorher, aber...ja, vielleicht hat ja jemand eine Idee, was ich probieren könnte. Zur Überprüfung habe ich mit Windows per Wireguard-Client von meinem unRAID-Server gezogen: Ganz normal mit dem Explorer auf das Share (per /mnt/user/share und /mnt/diskX) zugegriffen und mit 530-550 MBit geladen. Das wurde vermutlich durch meine Leitung zuhause gebremst, da ich "nur" 50 MBit Upload habe und der Rückkanal 51-55 MBit verbrauchte (Holy Shit). Beim unRAID-Server keine Auffälligkeiten, keine Last-Spitzen, nur dauerhaft 3-4% zusätzliche CPU-Last durch Wireguard-Verschlüsselung etc.pp. Dann habe ich mir einen unRAID-Stick fertig gemacht, in den vorherigen Windows-Rechner gesteckt, "Community Apps" installiert, Wireguard installiert, gleiche Tunnel-Konfig wie zuvor verwendet, manuell gemountet (ganz billig einfach nur mount -t cifs -o) und getestet. Vorab: Um das Problem zu "resetten" reicht es zu unmounten, 3-5 Min zu warten, wieder zu mounten und das Spiel kann von vorne beginnen. Mountet man vorher schraubt sich der Transfer im Kilobit-Bereich hoch bis auf irgendwann mal 10 MBit. In allen Fällen lese/schreibe ich direkt über /mnt/cache bzw. /mnt/diskX. Temp-Server zieht vom Haupt-Server: Anfangs 530-600 MBit, Rückkanal 4-20 MBit (ich habe nur per GUI geschaut). unRAID-Oberfläche des ziehenden Temp-Servers zeigt direkt Auslastung eines Cores mit 90-100% an (springt weiter auf andere Cores, in htop und top sieht man das komischer Weise nicht), in iotop kloppen sich der "Midnight Commander" und "[unraidd1]" mit 99%+ um den ersten Platz. Bis der 100%-Core plötzlich nicht mehr so schnell wechselt (unRAID-GUI), in iotop nur noch alle paar Sekunden 99% für MC angezeigt werden und die Geschwindigkeit auf 10 MBit fällt. htop und top zeigen immer noch keine nennenswerte CPU-/Core-Last an. Haupt-Server schiebt auf den Temp-Server: Von der Idee her gleiches Bild, dauert nur länger. Die Cores auf dem empfangenden Temp-Server schaukeln sich in der unRAID-GUI hoch, wenn oft genug hintereinander 100% da steht fällt die Geschwindigkeit auf 10 MBit. Haupt-Server zieht vom Temp-Server: Das Gleiche wie andersrum, nur mit leitungsbedingt geringeren Übertragungswerten. 🙂 Ich installiere gerade interessehalber eine Windows-VM auf dem Haupt-unRAID-Server und will mal schauen was passiert, wenn ich darin mit dem Wireguard-Client ziehe. 🤯
  13. Sorry, das hätte ich gleich dazu schreiben können, ich umgehe bei meinen Netzwerktests immer SHFS, um das als Faktor auszuschließen. 🙂Ich nutze /mnt/cache und habe in diesem Fall sogar mit /mnt/diskX gearbeitet, da ich etwas von möglichen BTRFS-Problemen gelesen hatte, die sich aber nicht bestätigten (2x verschlüsselte Samsung 870 SSD im RAID 1). CPU ist ein Intel i9-10900T. Wenn ich von /mnt/diskX auf /mnt/cache kopiere ist alles gut und geht mit voller HDD-Lese-Geschwindigkeit ohne erwähnenswerte IOwaits. MBit, geht per INet, daher auch Wireguard. Wie gesagt, SMB lokal konnte ich leider noch nicht testen, da ich eine sehr lang Zeit nach Problemen bei Wireguard gesucht hatte, bis ich auf iotop gestoßen bin und mir damit endlich die CPU-Belastung erklären konnte.
  14. Hallo zusammen, ich bastel seit Wochen an einem Problem herum, das ich einfach nicht gelöst bzw. ordentlich analysiert bekomme. Daher wende ich mich an Euch, da mir einfach die Ideen und die Google Suchbegriffe ausgegangen sind. Ich möchte gar nicht all zu sehr auf das eingehen, das ich bisher probiert habe (reicht gefühlt bis "Mit Weihrauch um den Server tanzen"). Wichtigster Punkt ist, dass ich die MTU für die Wireguard-Verbindung mittlerweile auf 1280 gestellt habe, was für Glasfaser-Verbindungen wohl empfohlen wird (Paketfragmentierung tritt bei Ping nicht auf, auch bei höheren MTUs nicht). Der Rest waren wildeste Überlegungen und Gestocher im Unbekannten. Zusatzinfo: Ich nutze das Unassigned Devices Plugin für das Mounten der Shares. Ich bin der Meinung ich habe auch ohne getestet, wenn jemand sagt: "Mach ohne", teste ich das aber gerne auch nochmal. Nun aber zum Problem: Der Dateitransfer per Wireguard + SMB/NFS erzeugt massiv IOWAIT (wie ich mittlerweile herausgefunden habe), wenn unRAID "zieht". Wenn ich die gleiche Datei über die gleiche Verbindung in das gleiche Verzeichnis schiebe ist die CPU-Last völlig normal, kein IOwait, nichts. Das Ganze äußert sich so, dass im Endeffekt 1 (HT-)Core auf 100% Last hoch geht (gem. iotop 99,8% IOwait durch rsync/MC) und diese 100% dann von einem auf einen anderen Core umspringen. Die Verbindungsgeschwindigkeit geht von 250-270 MBit/s auf 10-12 MBit/s runter. Wenn ich die Übertragungsgeschwindigkeit begrenze (runter bis auf 50%) dauert es länger, schaukelt sich aber über die Zeit hoch und das Endergebnis ist das gleiche. Sobald die Geschwindigkeit gefallen ist erzeugen rsync/MC 99,8% IOwait, dann wieder nicht, dann wieder, dann wieder nicht usw. Bisher war es so, dass die Geschwindigkeit bei NFS auf 100 MBit/s stabil lief, seit Kurzem (ich denke seit einem Update von Unassigned Devices) fällt aber auch diese nach einer gewissen Zeit auf 10 MBit/s. Zusätzlich möchte ich erwähnen, dass ein Speedtest (self hosted per Librespeed) in diesem "Fallback"-Zustand über die WG-Verbindung mit maximaler Leitungsgeschwindigkeit läuft, was ich als "Die WG-Verbindung funktioniert" deute. Ich habe das Ganze auch mit der neuen 6.10rc1 (auf dem Receiver) getestet, dort stellt es sich per SMB grundsätzlich gleich dar, nur dass der hängende Core nicht mehr überzuspringen scheint (oder zumindest deutlichst verzögert, ich habe nach 1 Min abgebrochen). Per NFS konnte ich gar nicht ziehen. Ich bin für jede Frage/Vermutung/Idee dankbar mit der ich das Problem weiter eingrenzen kann, denn ich bin mit meinem Latein am Ende. PS: Ich bin mittlerweile der Meinung, dass WG nicht das Problem ist. Da mein Server aber nicht mehr bei mir steht, konnte ich leider noch nicht testen, ob das Problem grundsätzlich bei SMB-Transfer auftritt. Vielleicht kennt ja jemand dieses Problem, der lokal per SMB arbeitet oder kann es nachstellen.
  15. Perfekt, abermals Dank. Dann baue ich das mal nach und schaue was passiert.