#2352 closed Verbesserung (erledigt)
NFS tunen
| Reported by: | Rüdiger Kupper | Owned by: | bau |
|---|---|---|---|
| Priority: | unverzüglich erledigen | Milestone: | Schuljahr 2016/17 |
| Component: | Hardware: Netzwerktechnik | Severity: | beeinträchtigt den Unterricht vieler Lehrer |
| Keywords: | Cc: |
Description
NFS hat noch einige Parameter, an denen man drehen kann (server- wie clientseitig). Vielleicht finden wir Einstellungen, die für unseren Server besser geeignet sind.
Googeln nach "tune NFS" liefert eine Reihe von Seiten zum Thema, z.B.:
- http://nfs.sourceforge.net/nfs-howto/ar01s05.html
- http://www.slashroot.in/how-do-linux-nfs-performance-tuning-and-optimization
- http://www.cyberciti.biz/faq/linux-unix-tuning-nfs-server-client-performance/
Achtung, nicht alle Seiten sind zu NFS4.
Change History (17)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
- @bau
- Generell raten alle Seiten zunächst einmal dazu, alle Netzwerkkomponenten zu überprüfen und homogen so einzustellen, dass Paketkollisionen vermieden werden:
- stehen sämtliche Switche und Netzwerkkarten auf duplex ?
- arbeiten (wo immer möglich) alle Switche und Netzwerkkarten auf Gigabit? (Ein einzelner Rechner auf 100Mbit kann eventuell ein ganzes Gigabit-Netzwerk ausbremsen)
- Arbeiten alle Switche und Netzwerkkarten mit "Jumboframes" (betrifft nur Gigabitnetze, glaube ich...?)
Vielleicht ist geschicktes Subnetting doch eine Hilfe?
comment:3 by , 10 years ago
Stichwort Festplattengeschwindigkeit:
Hier sind Informationen zu den Befehlen nfsstat und iostat:
http://www.cyberciti.biz/faq/howto-linux-track-nfs-client-disk-metrics/
iostat gibt instbesondere darüber Auskunft, wie belastet die Festplatten sind -- ich könnte mir vorstellen, dass es die Festplattenzugriffe sind, die den paedml ausbremsen, wenn 60 threads gleichzeitig von der Platte lesen wollen.
Vielleicht gibt es zwischen 8 und 64 eine Zahl, mit der unser paedml besser zurechtkommt.
comment:4 by , 10 years ago
Zitat:
NFS Performance tuning can be classified to three different areas. We will be discussing them separately in this tutorial. Lets have a look at these classifications first.
- Underlying Disk Related Performance that affects NFS
- NFS Application based Performance
- And finally Network Related NFS tuning (NFS is a technology that relies heavily on network)
(von http://www.slashroot.in/how-do-linux-nfs-performance-tuning-and-optimization)
comment:5 by , 10 years ago
Thema Filesystem-benchmark/Tuning: http://www.slashroot.in/linux-file-system-read-write-performance-test
comment:6 by , 10 years ago
| Resolution: | → erledigt |
|---|---|
| Status: | new → closed |
Zwei Optionen haben die Situation überragend verbessert:
- NFS-shares mit Option async exportieren
- Zahl der erlaubten parallelen NFS-Prozesse auf mehr als Klassengröße erhöhen
Damit können sich ganze Klassen gleichzeitig einloggen, ohne dass nennenswerte Last auf dem Server entsteht.
Potentielle weitere Verbesserung: Verteiltes NFS.
comment:7 by , 10 years ago
Hast du auch den Ordner .cache auf die lokale Platte verschoben?
Irgendwie müsste der Ordner dann beim Login auf der Platte z.B. in /tmp/.cache/USERNAME angelegt werden und mit den Rechten des Users versorgt werden, dann genügt ein Symlink im HomeVZ.
comment:9 by , 10 years ago
Grade war auf dem paedml mal wieder ziemlich was los: Load von 28, selbst ein Login per ssh war leicht träge. In diesem Zustand startet der Firefox gähnend langsam, wenn ich aber den .cache nach lokal verbiege, dann geht das deutlich schneller. Nebeneffekt: Im HomeVZ des Users werden >20MB weniger belegt.
comment:10 by , 10 years ago
Ja, ich kümmere mich drum. -> Kann ich denn die Rechner wieder normal syncen, hast Du die schueler.conf wiederhergestellt?
comment:11 by , 10 years ago
Warum war denn um kurz nach 8 die Load wohl auf 28? War da eine Klasse im Computerraum?
follow-up: 13 comment:12 by , 10 years ago
Yep - Herr Wagner war mit einer Klasse im Raum - wahrscheinlich war das 100MBit-Modul auch zum Teils Schuld daran.
Die schueler.conf soll nun so bleiben, wie sie ist, denn wir brauchen die virtual-XP-Platte nicht mehr!
Ich weiß nicht, ob man jetzt im Betrieb die Partition 2 verkleinert und die 1 vergrößert oder beim nächsten Sync einfach neu partitioniert?
Ich habe das virtuelle-XP nun in ein cloop gepackt (virtual-XP_S.cloop), welches nur heruntergeladen werden muss, wenn Linbo dann beim Auspacken wegen zu geringer Partitionsgröße aufgibt ist das genau der gewünschte Effekt. Beim Erstellen des neuen Images für die Ubuntu-Partition müssten dann noch erfolgen:
- cloop.ko nach
/lib/modules/`uname -r`/(liegt unter /var/lib auf dem paedml) - cd
/lib/modules/`uname -r`/ - depmod (Eventuell hast du ja eine Ahnung, wie man dkms einrichtet, die Quellen liegen derzeit unter /root/cloop/ auf dem paedml, kompiliert ist das Modul für kernel 4.4.0-38-generic und auch nur damit tut es!)
- mkdir /cache
- in der fstab /dev/sda4 nach /cache ro mounten
- nach dem Mount das Kernelmodul einhängen:
modprobe cloop file=/cache/virtual-XP_S.cloop - danach ist das cloop als Blockdevice /dev/cloop0 verfügbar und kann eingehängt werden:
mount -r /dev/cloop0 /usr/share/virtualbox-vdi - im gemounteten cloop liegt dann die start_XP.sh, so dass der vorhandene Starter funktionieren wird. Dieses legt erstmal /tmp/Snapshots an und setzt den Zugriff auf 777. damit kann jede VM dort ihr Abbild reinlegen.
- Beim Booten sollte das Verzeichnis /tmp/Snapshots komplett entfernt werden. Zu diesem Zeitpunkt kann ja auch das lokale .cache geleert werden.
Ich muss grade noch ein paar kleinere Dinge am virtual-XP_S.cloop auf dem Server ändern. Dazu habe ich dieses auf dem Server entpackt und eingehängt. Wenn es fertig ist, dann kann es auf den Schülerrechnern verteilt werden. Dazu muss wahrscheinlich ein neuer Torrent-Prozess gestartet werden, mal sehen, wie das geht. Das Test-cloop habe ich auf die Rechner in 1-09 per rsync geschoben (da liegt noch ein Script in /root/virtualXP, was die Arbeit macht, wenn man es per pssh startet). Leider war ein entscheidender Fahler drin, weshalb es gleich mal nicht funktionierte: im XP_S.ova ist das Share home bereits nach /home/teachers/bau verbunden, damit kann NxT-G da nichts reinschreiben und meckert ständig.
comment:13 by , 10 years ago
Replying to bau:
Yep - Herr Wagner war mit einer Klasse im Raum - wahrscheinlich war das 100MBit-Modul auch zum Teils Schuld daran.
Die schueler.conf soll nun so bleiben, wie sie ist, denn wir brauchen die virtual-XP-Platte nicht mehr!
Ich weiß nicht, ob man jetzt im Betrieb die Partition 2 verkleinert und die 1 vergrößert oder beim nächsten Sync einfach neu partitioniert?
Letzteres. Derzeit habe ich immer nur die Partition 1 gesynct, so dass die VMs noch wie gewohnt funktionieren sollten (aber Schüler haben die ohnehin nicht genutzt, oder?).
Das Einhängen des cloops werde ich dann bei Gelegenheit auf den Clients so machen wie Du beschrieben hast. Das mit dem Kernel-Modul, das nur mit einem bestimmten Kernel funktioniert, gefällt mir nicht recht. Da besteht die Gefahr, dass mit einem Update der Clients ein neuer Kernel kommt (passiert bei Ubuntu ja dauernd) und dann funktioniert das Modul nicht mehr.
Also mal nachlesen, wie dkms funktioniert...
Sollte aber wohl in ein eigenes Ticket ;-).
comment:14 by , 10 years ago
- Hierher verschoben aus ticket:2292
Der Flaschenhals paedml soll entschärft werden. Wir haben den Server derzeit per Gigabit-Ethernet-NIC an das grüne und das graue Netz angebunden, die Performance ist ordentlich. Wir wollen jedoch zurück zu Etherchannel und TRUNK (bonding), damit wäre der Server per 6GBit-Etherchannel am Switch. Noch besser wäre das 10GE-Modul mit CX4, damit hätten wir den Server mit 10GBit am Switch per copper infiniband. Das wären dann die netzwerkseitigen Möglichkeiten.
Als größeres Problem haben sich die Platten herausgestellt, die die Daten zu langsam bereitstellen. Ich hatte Kontakt zu verschiedenen Unis aufgenommen und gerade mit dem KIT telefoniert. Dort berteiben sie ein System, welches über IP-Rotation mehrere Server anspricht, so dass im Falle des Ausfalls keine Probleme entstehen und die Last verteilt wird. Im Background ist dann ein Storage angebunden, auf das alle Server zugreifen.
Wir dürfen und das Ganze mal vor Ort in Karlsruhe (Campus Nord) ansehen :-)
comment:15 by , 10 years ago
Serveranbindung ab heute wieder über einen 6-Port Gigabit-Trunk.
Next-Step:
Anbindung per CX4, dazu muss aber die komplette SupervisorEngine ausgetauscht werden, das wird
ein etwas größerer Act, da die Konfiguration auf der SE liegt -> Herbstferien
comment:16 by , 10 years ago
Frau Obholz vom KIT gab noch einen guten Tip: Gluster:
läuft auch auf Debian:
comment:17 by , 10 years ago
Das Problem mit der onboard-NIC hat sich anscheinend erledigt seit ich im cisco0027 das Interface auf speed 1000 gesetzt habe ist der failure count überall 0:
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) Bonding Mode: IEEE 802.3ad Dynamic link aggregation Transmit Hash Policy: layer2 (0) MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 200 Down Delay (ms): 200 802.3ad info LACP rate: slow Aggregator selection policy (ad_select): stable Active Aggregator Info: Aggregator ID: 1 Number of ports: 6 Actor Key: 17 Partner Key: 5 Partner Mac Address: 00:0c:85:0e:8b:80 Slave Interface: eth0 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 50:e5:49:cf:ae:e2 Aggregator ID: 1 Slave queue ID: 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 68:05:ca:01:6b:6d Aggregator ID: 1 Slave queue ID: 0 Slave Interface: eth2 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:13:3b:0f:2a:e0 Aggregator ID: 1 Slave queue ID: 0 Slave Interface: eth3 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:13:3b:0f:2a:e1 Aggregator ID: 1 Slave queue ID: 0 Slave Interface: eth4 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:15:17:75:8b:5a Aggregator ID: 1 Slave queue ID: 0 Slave Interface: eth5 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:15:17:75:8b:5b Aggregator ID: 1 Slave queue ID: 0
Vom Tuning abgesehen sind generelle Maßnahmen, um die Dateizugriffe auf den Server zu verringern: