Seltsame IO Probleme mit QEMU und nfs

[slu]

Da schreiben die "You can use the rsize and wsize mount options on the client to alter the buffer cache size.".

Guter Punkt!
Tatsächlich habe ich mit den Werten schon etwas "gespielt":

Code: Alles auswählen

vers=4.2,rsize=1048576,wsize=1048576

Version 4.0 soll ein Bug mit vielen open files haben (wenn ich es recht in Erinnerung habe), daher erst mal 4.2 probiert aber das hat noch nicht geholfen.
Export mit der Option sync macht auf dem NFS Client (home über NFS) im Firefox fast unbenutztbar, mit async läuft es flüssig (was mich nicht wundert).
Woher die sporadische Auslastung immer mal wieder herkommt habe ich noch nicht herausgefunden.

[slu]

Ich könnte mal in /etc/default/nfs-kernel-server "number of servers to start up" von 8 auf 16 erhöhen, aber ob das zielführend ist wenn meine kworker jetzt schon bei 100% hängen?
RPCNFSDCOUNT=8 -> 16

Gibt es für NFS sowas wie smbstatus?

[eggy]

Wie sieht's bei sehr kleinen Buffern aus? Das würde ihn ja zum regelmäßigen Senden zwingen, ka ab wann der Paketoverhead zu sehr ins Gewicht fällt, aber das kann man ja durch etwas Recherche rausfinden oder sich einfach geduldig rantesten. Meine Sorgen wäre, dass er dann die Leitung mit extrem vielen kleinen Paketen auch noch komplett auslastet. Aber auch dafür findet man sicher noch ne Lösung.

Wie sieht's übrigens bei Änderung des Übertragungsprokotolls aus? tcp/udp macht das bei Euch nen merklichen Unterschied?

[slu]

Wie sieht's bei sehr kleinen Buffern aus?

Sehr gute Frage, ich weiß das wir die vor 10 Jahren mal auf den Wert hochgeschraubt haben, seither habe ich das nicht mehr verändert.

Wie sieht's übrigens bei Änderung des Übertragungsprokotolls aus? tcp/udp macht das bei Euch nen merklichen Unterschied?

Guter Punkt, wir sind gerade auf tcp ich muss mal udp probieren.
Wenn ich aber so schaue was ein dstat auf dem Server so sagt (disk und net) ~ 5MB erscheint mir das kein Problem.
Server ist mit 10 GBit angebunden, Clients mit 1 GBit.

Was mir auch etwas verdächtig vorkommt ist die erhöhte Last seit Januar, es ist möglich das hier von NFS3 auf NFS4 umgestellt (home mount Clients) wurde.

[OrangeJuice]

Vielleicht erwähnenswert:
Der Fehler tritt auch auf, wenn Daten langsam kopiert werden (z.B. mit 5 MB/s bei einem Download aus dem Internet)
Wenn Daten auf den Fileserver oder auf den Fernsehserver kopiert werden tritt der Fehler auch bei 100 MB/s nicht auf.

Ich bin für jeden Tipp oder Hinweis, wie ich den Fehler eingrenzen kann, dankbar.

Du kannst mal in den Kommentaren lesen, dort scheint es auch jemanden zu geben der so ein ähnliches Problem hat.

Winni
Geschrieben am20.02.2021

Wenn ich jetzt aber mein altes QNAP auf das neu BasicNAS übertragen möchte, oder mit
meinem i7 Win10 Rechner zugreife =) maximal 250kB/s ???? Oft bricht es auf 0 ein
Nur mein NUC0-i7 mit Linux Mint brint ~8MB/s aber, bricht auch oft zusammen

Quelle: https://www.elefacts.de/test-152-asrock ... pu_im_test

Ansonsten fällt mir zum dem Mainboard mit dem Amedia-USB-Chip noch die Nachricht(CTS-Labs - 2018) zu möglichen Backdoors in Asmedia-USB-Controller ein: https://www.heise.de/security/meldung/H ... 96868.html

Einfach mal nachlesen und schauen, ob da etwas passendes bei ist.

[slu]

Was mir auch etwas verdächtig vorkommt ist die erhöhte Last seit Januar, es ist möglich das hier von NFS3 auf NFS4 umgestellt (home mount Clients) wurde.

So das Problem ist in unserem Fall gefunden, munin hat mich auf einen Benutzer geführt.
Immer wenn er im Haus war ging die Last hoch und das NFS hatte performance Probleme.
Es hat sich dann herausgestellt das bei diesem Benutzer der Tracker mit 100% CPU Last läuft und da das /home auf dem NFS Share lag...

Cache vom Tracker gelöscht und ein paar Ausnahmen hinzugefügt und die Sache war erledigt.

Zusätzlich haben wir noch in /etc/default/nfs-kernel-server RPCNFSDCOUNT auf 64 gestellt [default 8].

[wanne]

Wie schon angemerkt: Ich wette, dass du dir da Problem durch die VMs schon selber eingebrockt. Das System ist keine Rakete und I/O in VMs frisst halt Leistung. Daneben hat dein Host kein RAM. Deine SWAP-Abschaltung hat das sicher nochmal verschlimmert.
Wie immer gibt es viele Möglichkeiten das Problem zu lösen.


* Du kannst da sicher noch an ein paar Optimierungen in NFS/VDR machen vielleicht bekommst dus trotz irgend wie wieder flüssig. – Bis zum nächsten Update. NFS-Cache runter VDR-Buffer hoch wäre ein guter Tipp. Letzteres willst du vermutlich so oder so machen.
* Hardware: Das System hängt am Platten-I/O weil zu wenig RAM da ist. Mehr RAM und/oder ne flotte NVME dürfte das Problem lösen.
* Die Verteilung ist sehr ungünstig. Gibt der VDR/MyTV-VM 3GiB und dem Fileserver 2GiB. Dann hängst du in jede VM und den Host ~2-4GiB SWAP. Ich tippe, dass das das Problem massiv entschärft.
* Schaff die VMs ab. man kann unter Linux Programme auch einfach beenden. Das gilt selbstverständlich auch für MythTV Dann hast du keine Probleme mehr.

Meine fette Empfehlung: Nimm eine Lösung die möglichst weit unten hängt.

[piotrusch]

Export mit der Option sync macht auf dem NFS Client (home über NFS) im Firefox fast unbenutztbar, mit async läuft es flüssig (was mich nicht wundert).
Woher die sporadische Auslastung immer mal wieder herkommt habe ich noch nicht herausgefunden.

Hier https://www.admin-magazine.com/HPC/Arti ... Management ist der Unterschied zwischen sync und async gut erklärt. Ich habe damit mal auf einem Klassenserver ein ewig dauerndes Anmelden mehrerer Schüler gelöst. Aber laut der letzten Folge von Two-and-a-halfs admins (https://2.5admins.com/2-5-admins-50/) sollte man das aus Gründen der Datenintegrität nicht verwenden.

Meine exports sieht so aus (localhost weil über ssh-Portforwarding):

Code: Alles auswählen

/srv		localhost(rw,fsid=0,sync,insecure,no_subtree_check)
/srv/home	localhost(rw,sync,insecure,nohide,no_subtree_check)
/srv/vdr	localhost(ro,sync,insecure,nohide,no_subtree_check)

Damit habe ich keine Hänger beim Home-Verzeichnis. Allerdings linke ich nur wichtige Ordner von einem separaten Mountpoint in mein Homeverzeichnis, nicht das ganze Verzeichnis. Wenn das für dich unbedingt sein muss, dann könntest du sync einstellen und dann mit den anderen Optionen rumprobieren.
Dass der Server zu schwachbrüstig ist, halte ich für kein valides Argument. Die 0,5Mb/s oder so, die bei einer Aufnahme eintrudeln sind Pillepalle.

Gruß, Piotrusch