Seltsame IO Probleme mit QEMU und nfs

[Anutosho]

Hallo zusammen.
Ich betreibe einen kleinen Home-Server mit einem Asrock J5005-ITX Mainboard und zwei virtuellem Maschinen.
Die VM1 dient im Wesentlichen als Fileserver; VM2 beherbergt einen Fernsehserver mit einem vdr und einem SAT-Receiver als PCI-Karte.

Das Problem:
Wenn auf das Hostsystem per nfs Dateien kopiert werden fängt der vdr an zu spinnen. Es gibt massive Bildstörungen (ungefähr so wie der Satelliten-Empfang bei Starkregen). Der Fehler tritt ausschließlich auf, wenn per nfs auf den Host zugegriffen wird.
Wenn eine Datei per scp, rsync (mit user@host://...) kopiert wird oder wenn der Host per sshfs angesprochen wird tritt der Fehler nicht auf - nur beim Zugriff über nfs passiert das.

Meine Vermutung ist, dass der vdr die Daten vom SAT-Empfänger nicht schnell genug abholen kann, nur die Ursache ist mir nicht klar.
Der Fehler verschwindet erst wieder, wenn der vdr neu gestartet wird, das ist aber hier vermutlich nicht relevant.
Ich habe keine Idee, wie ich den Fehler eingrenzen kann. In den Logs finde ich nichts.

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.

[MSfree]

Ich betreibe einen kleinen Home-Server mit einem Asrock J5005-ITX Mainboard und zwei virtuellem Maschinen.
Die VM1 dient im Wesentlichen als Fileserver; VM2 beherbergt einen Fernsehserver mit einem vdr und einem SAT-Receiver als PCI-Karte.

Auf so eine schwachbrüstigen Maschine 2 VMs? Zumal wohl auch im Privatbetrieb die Trennung in VMs ziemlich unsinnig ist. Das bißchen Zeug, was deine Kiste da machen muß, könntest du auch direkt auf dem Host laufen lassen.

Wenn auf das Hostsystem per nfs Dateien kopiert werden fängt der vdr an zu spinnen.

Mein erste Diagnose: RAM voll, Kiste swapt.
Löse die VMs auf und betreibe die Dienste direkt auf dem Host, das spart locker 4GB RAM ein.

Diagnose:

CPU-Last prüfen:

Code: Alles auswählen

top

IO-Last prüfen:

Code: Alles auswählen

iotop

Speicherauslastung prüfen:

Code: Alles auswählen

free

[Anutosho]

Ich betreibe einen kleinen Home-Server mit einem Asrock J5005-ITX Mainboard und zwei virtuellem Maschinen.
Die VM1 dient im Wesentlichen als Fileserver; VM2 beherbergt einen Fernsehserver mit einem vdr und einem SAT-Receiver als PCI-Karte.

Auf so eine schwachbrüstigen Maschine 2 VMs? Zumal wohl auch im Privatbetrieb die Trennung in VMs ziemlich unsinnig ist. Das bißchen Zeug, was deine Kiste da machen muß, könntest du auch direkt auf dem Host laufen lassen.

Das macht schon Sinn. So kann ich z.B. einfach zwischen vdr und z.B. mythTV umschalten. EInfach die eine vdr VM abschalten und die mythTV VM starten.

Wenn auf das Hostsystem per nfs Dateien kopiert werden fängt der vdr an zu spinnen.

Mein erste Diagnose: RAM voll, Kiste swapt.
Löse die VMs auf und betreibe die Dienste direkt auf dem Host, das spart locker 4GB RAM ein.

Beide VMs haben 4 GB Speicher, den sie aber lange nicht auslasten. Swap ist abgeschaltet.

Diagnose:

CPU-Last prüfen:

Code: Alles auswählen

top

top mit laufendem vdr und einem Download:

Code: Alles auswählen

top - 01:37:58 up 5 days, 21:37,  2 users,  load average: 0,72, 0,40, 0,23
Tasks: 165 total,   1 running,  99 sleeping,   0 stopped,   0 zombie
%Cpu0  :  5,7 us,  1,7 sy,  0,0 ni, 92,3 id,  0,0 wa,  0,0 hi,  0,3 si,  0,0 st
%Cpu1  :  1,3 us,  3,7 sy,  0,0 ni, 59,9 id, 35,1 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu2  :  2,7 us,  3,4 sy,  0,0 ni, 80,5 id, 12,5 wa,  0,0 hi,  1,0 si,  0,0 st
%Cpu3  :  2,3 us,  1,3 sy,  0,0 ni, 94,6 id,  0,0 wa,  0,0 hi,  1,7 si,  0,0 st
KiB Mem :  7859508 total,   133748 free,  2962248 used,  4763512 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  4585888 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                     
16225 libvirt+  20   0 4387800 1,674g  18020 S  18,9 22,3 180:50.01 qemu-system-x86                                                                             
 2457 root      20   0       0      0      0 I   2,3  0,0   0:00.30 kworker/u8:2-ev                                                                             
16249 root      20   0       0      0      0 S   2,3  0,0   3:14.31 vhost-16225                                                                                 
   41 root      25   5       0      0      0 S   2,0  0,0 117:00.73 ksmd                                                                                        
16304 libvirt+  20   0 4120100 1,100g  17904 S   1,0 14,7  13:56.21 qemu-system-x86                                                                             
 2454 root      20   0   42796   3952   3268 R   0,7  0,1   0:02.93 top                                                                                         
   30 root      20   0       0      0      0 S   0,3  0,0   0:08.95 ksoftirqd/3                                                                                 
 2220 root      20   0  107980   7204   6196 S   0,3  0,1   0:00.12 sshd                                                                                        
    1 root      20   0   78112   5984   3364 S   0,0  0,1   0:09.53 systemd                                                                                     
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.12 kthreadd                    

Eigentlich passiert da ja nicht besonders viel.
Wundern tun mich allerdings die hohen waits auf cpu 1 und 2

IO-Last prüfen:

Code: Alles auswählen

iotop

Code: Alles auswählen

Total DISK READ :       0.00 B/s | Total DISK WRITE :      43.20 M/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:      11.52 K/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                          
  728 be/3 root        0.00 B/s    0.00 B/s  0.00 %  1.32 % [jbd2/sdd5-8]
  841 be/4 root        0.00 B/s    6.72 M/s  0.00 %  0.00 % [nfsd]
  842 be/4 root        0.00 B/s    4.80 M/s  0.00 %  0.00 % [nfsd]
  843 be/4 root        0.00 B/s    4.80 M/s  0.00 %  0.00 % [nfsd]
  844 be/4 root        0.00 B/s    6.72 M/s  0.00 %  0.00 % [nfsd]
  845 be/4 root        0.00 B/s    3.84 M/s  0.00 %  0.00 % [nfsd]
  846 be/4 root        0.00 B/s    5.76 M/s  0.00 %  0.00 % [nfsd]
  847 be/4 root        0.00 B/s    4.80 M/s  0.00 %  0.00 % [nfsd]
  848 be/4 root        0.00 B/s    5.76 M/s  0.00 %  0.00 % [nfsd]
 ...

Auch hier wundert mich gerade die hohe Schreiblast (auf mechanische Festplatte). Mein Download ist max 10 MB/s.
Der vdr selbst schreibt nichts auf die Platte.
Nachtrag:
Gerade sehe ich: Wenn ich einen Download mache werden die empfangenen daten nicht kontinuierlich über's Netz geschrieben, sondern hin und wieder werden die (offenbar vorher gesammelten) Daten mit full speed zum Server geschickt, und genau dann beginnen auch die Fehler im vdr.
Trotzdem finde ich es erstaunlich, dass das nur passiert, wenn die Daten per nfs geschrieben werden.

Speicherauslastung prüfen:

Code: Alles auswählen

free

Code: Alles auswählen

              total        used        free      shared  buff/cache   available
Mem:        7859508     2961184      129480        1488     4768844     4586956
Swap:             0           0           0

Für mich sieht das nicht nach Überlastung aus.

[debianoli]

Dein Thread Titel ist falsch. Das ist doch mehr ein Problem der nfs Einstellungen für mich

[Anutosho]

Was genau meinst Du? Das nfs als solches geht ja, aber es hat "Seiteneffekte"
Was könnte da deiner Meinung nach falsch eingestellt sein?
Ich weiß, das der Titel schwierig, aber das Problem ist auch seltsam. Für mich sieht das wie ein io-Problem aus, ausgelöst durch das nfs.

[MSfree]

Was für eine Festplatte steckt in der Kiste?
Bitte genaue Modellbezeichnung, ggfls. mit fdisk -l /dev/sdX ermitteln.

[Anutosho]

fdisk zeigt mir den Typ der Platten erstaunlicher Weise nicht an (auf dem Notebook schon)
Smartctl zeigt's aber:
Die Systemplatte des Hosts ist eine Samsung 840 Series ssd.

Code: Alles auswählen

Disk /dev/sdb: 111,8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4782003F-F4EB-4531-B465-F2CCB13838B5

Device       Start       End   Sectors   Size Type
/dev/sdb1       34      2047      2014  1007K BIOS boot
/dev/sdb2     2048   1050623   1048576   512M EFI System
/dev/sdb3  1050624 234441614 233390991 111,3G Linux LVM

Die Daten und die VMs liegen auf einer 2 TB Seagate ST2000VM003-1CT164

Code: Alles auswählen

Disk /dev/sdd: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F526C0EB-F2E8-4120-A5E7-27F94B6A4649

Device         Start        End    Sectors  Size Type
/dev/sdd1       2048   54687743   54685696 26,1G Linux filesystem
/dev/sdd2   54687744  109375487   54687744 26,1G Linux filesystem
/dev/sdd3  109375488  109570047     194560   95M EFI System
/dev/sdd4  109570048  117383167    7813120  3,7G Linux swap
/dev/sdd5  117383168 3907028991 3789645824  1,8T Linux filesystem

Eine 4 TB WDC WD40EFRX-68N32N0 und eine kleine Intenso ssd für Tests dürften in diesem Zusammenhang irrelevant sein.
Es wird KEIN Raid benutzt.

[MSfree]

OK, SSDs dürfte aussen vor sein. Ich wollte mit derTypbezeichnung feststellen, ob deine Festplatten SMR-Laufwerke sind. Es sind aber beide nicht SMR.

[Anutosho]

OK, SSDs dürfte aussen vor sein. Ich wollte mit derTypbezeichnung feststellen, ob deine Festplatten SMR-Laufwerke sind. Es sind aber beide nicht SMR.

Nein, so ein Unsinn kommt mir nicht in's Haus.

[novalix]

Hi,

wieso hast Du die vorhandene Swap-Partition abgeschaltet? Gab es Probleme mit laufenden Anwendungen?
An sich ist swapspace eine feine Sache. Da kann der Kernel die Registerleichen aus dem memory cache hin packen. Falls da doch mal jemand nach fragt, ist die Auslieferung immer noch schneller und weniger lastreich, als wenn das Ganze neu vom Dateisystem gelesen werden müsste.
Falls eine Anwendung ins Schlingern kommt, weil der Kernel nach ihrem Geschmack zu früh auslagert, kann man an der "swapiness" schrauben, bis es passt.

[Anutosho]

Eigentlich ist swap schon eingeschaltet. Weil trotz niedriger Speicherauslastung aber doch ein paar MB im Swap waren und weil MSfree swapping als möglichen Grund für den Fehler vermutete habe ich das einfach mal abgeschaltet und dann das bekannte Szenario durchgespielt: Fernsehen und einen Download auf den Host speichern. Der Fehler passiert auch dann.

Wie ich ja schon in einem früheren Beitrag geschrieben habe werden die Daten ja auch bei einem eigentlich langsamen Download in chunks geschrieben, und genau in diesem Moment passiert dann der Fehler.
Der Transfer dieser chunks ist langsamer (~ 70 MB/s) als das Netzwerk und auch langsamer als die Platte schreiben könnte. Eine Überlastung in diesem Bereich würde ich deshalb mal ausschließen.
Lokales Kopieren von einer Platte aus eine andere löst den Fehler nicht aus, obwohl die Schreiblast dabei deutlich höher ist ~140 MB/s, und auch die waits ziemlich in die Höhe gehen.

Ich würde einen kleineren Betrag darauf verwetten, das nfs hier der Übeltäter ist. Nur habe ich keine Ahnung, wie ich dem auf die Schliche kommen kann.

Ich poste hier mal Auszüge der /etc/exports des hosts und /etc/fstab meines Rechners. Vielleicht ist da ja irgendwo Mist eingestellt.

/etc/exports:

Code: Alles auswählen

/data      192.168.222.0/24(async,rw,no_root_squash,no_subtree_check) 

/etc/fstab

Code: Alles auswählen

hyper:/    /nfs/hyper     nfs     noauto,user,soft,intr,exec,nosuid,noatime,nodiratime,_netdev 0 0

[slu]

Ich würde einen kleineren Betrag darauf verwetten, das nfs hier der Übeltäter ist. Nur habe ich keine Ahnung, wie ich dem auf die Schliche kommen kann.

Ich stehe gerade vor dem selben Problem, habe jetzt mal von NFS 4.0 auf 4.2 gewechselt aber das war noch nicht die Lösung.
Irgendwas beim NFS lastet die kworker massiv aus.

Edit: Debian 10.10

[OrangeJuice]

Du kannst mal damit nachschauen ob etwas auffälliges zu sehen ist.

Code: Alles auswählen

cat /proc/net/dev
cat /proc/interrupts

[eggy]

Habt ihr den Abschnitt zu Buffern im NFS Artikel im Archiviwiki schon abgearbeitet?
https://wiki.archlinux.org/title/NFS/Tr ... ze_and_MTU
Da schreiben die "You can use the rsize and wsize mount options on the client to alter the buffer cache size.". Vielleicht reicht das ja schon. Sonst verweisen sie auch noch auf nen Tunningartikel mit weiteren Tipps, ka ob da noch was für Euch verwertbares enthalten ist. Ich würd erstmal mit den genannten Optionen experimentieren.

[slu]

Code: Alles auswählen

cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       CPU8       CPU9       
  0:         36          0          0          0          0          0          0          0          0          0   IO-APIC   2-edge      timer
  1:          0          0          0         25          0          0          0          0          0          0   IO-APIC   1-edge      i8042
  6:          0          0          0          0          0          3          0          0          0          0   IO-APIC   6-edge      floppy
  8:          0          0          0          0          0          0          0          0          0          0   IO-APIC   8-edge      rtc0
  9:          0          0          0          0          0          0          0          0          0          0   IO-APIC   9-fasteoi   acpi
 10:          0          0          0          0          0          0          0          0          0       7658   IO-APIC  10-fasteoi   uhci_hcd:usb3, uhci_hcd:usb4, virtio2, qxl
 11:          0          0          0          0          0          0          0          0          0          0   IO-APIC  11-fasteoi   uhci_hcd:usb1, ehci_hcd:usb2
 12:          0          0        308          0          0          0          0          0          0          0   IO-APIC  12-edge      i8042
 14:          0          0          0          0          0          0          0          0          0          0   IO-APIC  14-edge      ata_piix
 15:          0          0          0          0          0          0          0          0          0          0   IO-APIC  15-edge      ata_piix
 24:          0          0          0          0          0          0          0          0          0          0   PCI-MSI 114688-edge      virtio3-config
 25:          0          0          0          0          0          0          0          0    1280230          0   PCI-MSI 114689-edge      virtio3-req.0
 26:          0          0          0          0          0          0          0          0          0          0   PCI-MSI 49152-edge      virtio0-config
 27:          0   31399560          0          0          0          0          0          0          0          0   PCI-MSI 49153-edge      virtio0-input.0
 28:          0          0        287          0          0          0          0          0          0          0   PCI-MSI 49154-edge      virtio0-output.0
 29:          0          0          0          0          0          0          0          0          0          0   PCI-MSI 81920-edge      virtio1-config
 30:          0          0          0          0         13          0          0          0          0          0   PCI-MSI 81921-edge      virtio1-virtqueues
NMI:          0          0          0          0          0          0          0          0          0          0   Non-maskable interrupts
LOC:     941346    1437953    1114985     964787     987880     893330     847965    1360105    1000410     867189   Local timer interrupts
SPU:          0          0          0          0          0          0          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0          0          0          0          0          0          0   Performance monitoring interrupts
IWI:          0          0          0          0          0          0          0          0          0          0   IRQ work interrupts
RTR:          0          0          0          0          0          0          0          0          0          0   APIC ICR read retries
RES:    2697735    1574708    4967374    3293931    3813345    3009940    3168067    2112923    3762557    2635363   Rescheduling interrupts
CAL:     114254     426977     152231      93949     149256     111097      81571      70304       8931      57782   Function call interrupts
TLB:       4118       3979       4336       3577       3975       5324       4718       3669       4720       3256   TLB shootdowns
TRM:          0          0          0          0          0          0          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0          0          0          0          0          0          0   Threshold APIC interrupts
DFR:          0          0          0          0          0          0          0          0          0          0   Deferred Error APIC interrupts
MCE:          0          0          0          0          0          0          0          0          0          0   Machine check exceptions
MCP:        161        161        161        161        161        161        161        161        161        161   Machine check polls
ERR:          0
MIS:          0
PIN:          0          0          0          0          0          0          0          0          0          0   Posted-interrupt notification event
NPI:          0          0          0          0          0          0          0          0          0          0   Nested posted-interrupt event
PIW:          0          0          0          0          0          0          0          0          0          0   Posted-interrupt wakeup event

Rescheduling interrupts ist etwas hoch, allerdings kann ich auch nicht sagen was normal wäre.
So ganz schlau bin ich mit dem Problem noch nicht geworden, evtl. ist da auch ein spezieller NFS Client schuld (Suche indexieren,...).

[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