E2 hängt komplett weg, wenn NFS Zugriff ausfällt....

  • Hallo Ihr beiden,


    ja @Swiss-MAD hatte recht meinte sein angeführtes Problem.


    @klik danke diese Info von den älteren Fritzboxen hatte ich gemeint, natürlich weiß ich das es hier um NFS geht.
    Was die Fritzboxen können oder nicht weiß ich nicht, da ich nie eine besessen habe :D


    @Swiss-MAD und ja Externe USB-Luafwerke machten bei mir auch keine Probleme.
    Hatte Jahrelang an meinem alten Qnap-TS119 (OneBay) extern ein Laufwerk per e-sata und zwei Laufwerke per USB angeschlossen.
    Bin ja aber damit nun auf meinem alten Rechner mit Openmediavault umgezogen womit ich nun wesentlich Glücklicher und schneller bin wie mein Qnap.
    Auch spare ich jetzt damit einiges mehr an Strom, seit ich keine 3 Externe Laufwerke mehr benutze :D


    >Back to Topic<

    MfG EgLe



    Kernel : Linux 5.0.1-1-MANJARO
    GUI : KDE 5.56.0 / Plasma 5.15.2
    Machine : Intel NUC8i7HVK
    Graphics : Radeon RX Vega M GH (DRM 3.27.0, 5.0.1-1-MANJARO, LLVM 7.0.1)
    CPU : Intel Core i7-8809G @ 8x 4.2GHz
    RAM : Gskill F4-3000C16S-16GRS Speicherkarte so D4 3000 16GB C16 Rip

  • Ich hänge da nochmal was an diesen Tread an, weil ich mich kürzlich nochmal mit dem mount beschäftigt hatte.

    Einfach das es mal festgehalten ist, falls jemand auch darauf stosst. Denn ich hatte eine weile gebraucht um raus zu finden weshalb bei mir plötzlich die avarage load immer gegen 1.0 läuft.


    Seit bei mir von der DM900 zum Synology NAS eine NFS V4.1 Verbindung ausgehandelt wird, steigt sobald der Mount hergestellt ist, die avarage load auf der DM900 auf ca. 1.0 an.

    Wird der mount danach wieder abgemeldet weil keine Zugriffe mehr stattfinden, sinkt die avarage load wieder gegen 0.

    Die CPU Last steigt dabei aber nie wirklich an.

    Einen erzwungenen mount mit NFS Ver.4.0 reicht aber schon aus, um die avarage load wieder zurück gegen 0 zu bringen. Wichtige Neuerung die an der Dreambox was bringen würden, gibt es bei der V4.1 aus meiner Sicht sowieso nicht. ;)

    Ich vermute das da im Kernel noch was vermurkst ist.

    Das ganze ist aber eher kosmetischer Natur, da die CPU Last selbst immer tief bleibt, und auch bei der Nutzung der Dreambox kein unterschied feststellbar ist.

  • Seit ich mir einen neuen Server gebaut und einen nfs mount über Netzwerkbrowser eingerichtet habe, ist mir ebenfalls aufgefallen das loadaverage >1 ist. Bei mir verbindet er immer mit nfsv4.2. Wie sieht dein fstab Eintrag aus und hat es geholfen?


    Übrigens muss ich rsize und wsize selbst hochsetzen, sonst einigen sich Dreambox und Server auf 8192 :rolleyes:


    Edit: Hab es hinbekommen. Du hast Recht mit nfs Version 4.0 schießt loadaverage nicht in die Höhe. Das Problem mit den Mounts und dem weghängen sobald man was auf dem Server Kopiert habe ich bereits vor Jahren gepostet. Am Server liegt es nicht, der hat Power (Server Mainboard, ECC RAM, Core I3, Inter Netzwerkkarte). Es ist schön zu wissen, dass nicht nur ich Probleme mit mounts habe.


    Das ganze läuft besser wenn man mit version 3/udp mountet. Dann hat man kaum Auslastung und die Box reagiert schneller, allerdings bekommt man Pixelfehler in Aufnahmen. Eventuell macht der Netzwerkbrowser mit systemd komische Sachen.:/

  • Der Networkbrowser sollte mal renoviert werden, der macht unzeitgemässe Sachen. ;)

    Ich mounte nur noch von Hand direkt in der fstab.

    Mein mount ist im Moment wie folgt:

    192.168.2.2:/volume1/Dreambox /media/Dreambox nfs x-systemd.automount,tcp,nfsvers=4.0,noauto,x-systemd.idle-timeout=60,x-systemd.device-timeout=15,soft,nofail 0 0


    Beim letzten Test mit Auslastung des NAS, hatte ich damit keine Probleme mehr. Auch mit tcp nicht.

    Wobei beim Mount nun automatisch eine grössere Blockgrösse ausgehandelt wird.

    192.168.2.2:/volume1/Dreambox on /media/Dreambox type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.2.10,local_lock=none,addr=192.168.2.2)

    Mit dem Networkbrowser wurde die Blockgrösse ja auf 8192 festgenagelt.


    PS: Was hast du für ein Mainboard für den Server verwendet ? Betreibst du den mit OpenMediaVault ?

    Ich überlege mir ob ich in Zukunft mein Synology mal durch ein OpenMediaVault Server ersetzten soll.

    Das werde ich erst aber mal auf einem RaspberryPi testen, ob ich alles zum laufen bekomme wie ich gerne hätte, bevor ich dann richtige Hardware dafür kaufe.

  • Stromsparendes FUJITSU D3644-B Mainboard mit gutem Intel C246 Chipsatz und Intel Netzwerkkarte.

    Habe mit Fujitsu im Serverbereich gute Erfahrungen gemacht, sowohl Stabilität als auch Stromverbrauch.

    Zudem "Made in Germany" :)


    2666mhz DDR4 ECC RAM vom Samsung. und Core I3-8100 von Intel.

    Ich habe mich gegen den Xeon Prozi entschieden, da er vergleichsweise mehr verbrauchen würde und mehr als da doppelte kostet.


    Beim ECC RAM Streiten sich die Geister ob sinnvoll oder nicht. Man beachte Synology und QNAP verbauen kein ECC Speicher.

    Ich finde jedoch es ist für ein 24/7*265 System mit wichtige Daten sinnvoll.


    Man beachte,

    1. Laut Google wird auf einem von drei Computern ein Speicherfehler auftreten.
    2. Laut AMD hat ein 4 GB Systemspeicher mindestens einmal pro Woche einen Speicherfehler. Wenn mehr Speicher verfügbar ist, steigt auch das Risiko eines Fehlers.
    3. Nach LamdaDiode.com hat ein Computer die 96 prozentige Chance eines Speicherfehlers alle drei Tage.

    Ohne Platten hab ich an Stromverbrauch für das o.a. System im IDLE bei ca. 7,43 Watt.


    ================================================================================

    = OS/Debian information

    ================================================================================

    No LSB modules are available.

    Distributor ID: Debian

    Description: Debian GNU/Linux 9.9 (stretch)

    Release: 9.9

    Codename: stretch


    ================================================================================

    = openmediavault information

    ================================================================================

    Release: 4.1.22-1

    Codename: Arrakis

  • Bei Intel basierten Servern werden ECC-Fehler aktiv gemonitored. Nach meinen Erfahrungen sind die ECC-Fehler dramatisch niedriger. Auf 1 von 100 Servern kann man sporadisch ECC-Fehler sehen. Nach dem Wechsel der fehlerhaften DIMMs sind diese Probleme verschwunden.


    Wobei ich grundsätzlich für ECC bin.

  • Beim Netzwerkbrowser kannst du übrigens die rsize, wsize und nfs version eingeben. Dann werden Sie übernommen.

    Ich mach das trotzdem lieber von Hand.

    Alleine schon weil ich öfter übers Netzwerk mit der Dreambox verbunden bin, als das ich vor dem TV sitze, und ich vom Rechner aus immer ein Stockwerk hoch gehen müsste. :D

    Und die Tastatur ist mir immer noch lieber wie die Fernbedienung um solche Sachen ein zu geben. ;)

  • Swiss-MAD


    Du hast rsize=131072,wsize=131072. Macht es überhaupt Sinn diese Werte so hoch zu setzen?

    Ja, definitiv. Man kann auch ruhig auf 256k gehen, es geht hier um die Chunksize bei der Datenübertragung.

    Das was hier alles zu NFSv4 geschrieben wurde, möchte ich in Frage stellen. Gerade hier (0815 NAS mit STB, wo kein Kerberos benötigt wird und wohl auch keine Firewalls dazwischen sind) hat dies 0 Vorteile, insbesondere nicht in der Performance, da höherer Overhead. Ich würde immer auf NFSv3 mit TCP gehen. UDP macht nur Sinn, wenn man nur 100Mbit/s hat, dann hat man Teils noch performance Vorteile.

  • Ok die Verschlüsselung werden wohl die meisten nicht verwenden die nur lokal ihre Dreambox auf das NAS schreiben lassen.

    Das kostet auch Performance.


    Ich hatte aber bezüglich NFS V4 was performance anbelangt was anderes gelesen.

    In Tests war da eher von einem Vorteil von 15-20 % für NFS V4 zu lesen (ohne Verschlüsselung).

    Auch sonst sehe ich nur Vorteil für NFS V4

    Wie z.b. das man kein rpcbind mehr braucht (da bin ich beim manuellen mounten auch schon gescheitert bis ich das raus gefunden hatte) , kann UTF-8, das File-locking wurde verbessert (Wenn noch andere z.b. über smb darauf zugreifen. Mache ich oft, das ich was auf dem PC anschaue, auch wenn diese Aufnahme noch läuft.)

    Und eben den Performance Vorteil wegen verbessertem caching.


    NFS V4 ist einfach komplett runderneuert und kein Flickwerk mehr wie V3.

    Alleine schon deshalb wüsste ich nicht weshalb ich auf NFS V4 verzichten sollte, wenn ich schon moderne System im Einsatz habe die das unterstützen.

    Und Probleme hatte ich auf der DM900 bisher noch nicht damit, bis auf die erhöhte avarage load bei >= NFS V4.1.

    Wobei die höhere avarage load keine CPU Last erzeugte und auch sonst funktionierte.

    Aber ein fader Beigeschmack hat das schon hinterlassen, weshalb ich nun einfach V4 verwende.

    Zumal ich die Features in >= V4.1 nicht benötige.


  • Im Prinzip ist die NFS-Performance für die Dream gar nicht so wichtig, weil Enigma2 hier sowieso drosselt, damit es bedienbar bleibt.

    Hier bekomme ich egal ob NFSv3 oder NFSv4 oder IPv4 oder IPv6 immer exakt die gleiche Transferrate von 29,6MB/s wenn ich z.b. mit AMS einen Film aufs NAS kopiere.

    In der Shell ist natürlich der Unterschied deutlich zu spüren. Da ist hier NFSv3 etwas schneller und auch Verwendung von IPv4 ist etwas schneller - wobei das sicherlich auch vom verwendeten Server abhängt.


    Und ja, es macht eine großen Unterschied, wenn man große rsize und wsize verwendet.

    Hier bei mir werden automatisch rsize=131072,wsize=131072 ausgehandet und das ist auch das performanteste. Hab auch kleinere Werte getestet.


    Ich benutze auch NFSv4, weils einfach moderner ist und es ist ein Stateful Protokoll, so sehe ich an der QNAP, welches Gerät gerade per NFS zugreift. Das war mit V3 nicht so.


    Ryker

  • Deine Zeilen beweisen, dass du dich vermutlich nie mit Storage Protokollen, SunRPC, Buffer Size, TCP/UDP und der vermeintlicher Mehrperformance auseinandergesetzt hast. NFSv3 ist keinesfalls ein Flickwerk, sondern ein wohldefiniertes Protokoll, mitsamt nfsd, portmapper (rpcbind) und mountd. Ja, es ist Firewall unfreundlich und hat keine ernst zu nehmende Authentifizierung, aber das ist oftmals nicht nötig, insbesondere hier im Heimeinsatz. Der Hauptvorteil von NFSv4 sind ACLs, aber auch diese sind wohl bei einer Box, bei der fast alles als root läuft kaum notwendig.

    Das einzige Flickwerk bei klassischem NFSv2/v3 ist der lockd, da der tatsächlich nicht ursprünglich Bestandteil des Protokolls war. Aber mittlerweile funktioniert dieser gut, wenn man weiß was man tut.

    Du zitierst irgendwelche Tests und hast keinerlei praktische Erfahrung. Ich nutze NFS seit v2 und kann dir anhand aktuellen Einsatzes mit Netapp und selbstgebauten ZFS Büchsen in sowohl v3 wie auch v4 in 10 und 40 Gbit/s Netzwerken versichern, dass du bei sequentiellem Traffic sogar bei v3 leichte Performance Vorteile hast. Bei IOPS hat v4 leicht die Nase vorn. Beides ist aber nur messbar und zeigt praktisch keinerlei Auswirkung.

    Wenn es um Performance geht sollte man sich eher mal Gedanken über die defaults des TCP Stacks sowohl beim Client wie auch beim Server, über Jumbo Frames sowie über die mount Optionen machen.

    Wie du auf Verschlüsselung kommst weiß ich nicht, denn der Traffic kann bei NFSv4 nur encrypted werden, wenn getunnelt wird. Dies ist prinzipiell natürlich auch bei v3 möglich. Oder meinst du Krb? Das hat aber nichts mit dem Datenstrom zu tun und daher auch nichts mit der Performance.


    Es gibt Gründe, weshalb NFSv4 nach wie vor nicht weit verbreitet ist und die meisten Storage Hersteller dies auch nicht sonderlich propagieren. Aber NFSv4 hat auch vorteile, ACLs habe ich oben schon genannt und dank Statefulness, gibt es z.B seitens VMware ESX deutliche Verbesseurngen wie Storage IO Control, was vorher nicht möglich war.


    Systemload hat übrigens nicht zwangsweise etwas mit CPU usage zu tun, sondern auch oft mit IOwait. Evtl rührt dein Problem daher.

  • NFS-Performance für die Dream gar nicht so wichtig, weil Enigma2 hier sowieso drosselt, damit es bedienbar bleibt.

    Das ist aber nur bei File Operationen wie löschen & Kopieren der Fall. Da zerstückelt E2 den Vorgang und bearbeitet die nacheinander.

    Bei Aufnahmen oder Streaming ist das nicht der Fall.

    Aber seit wir GBit Ports haben, lasten wir den ja nur selten aus. Vor allem wer keine Platte verbaut hat und da keine grossen Datentransfers macht. ;)