Konfigurationen im Zusammenhang mit dem VDR (Video Disk Rekorder)


1. NFS optimieren

Bei Verwendung des Kernel 2.4 hatte ich nie Problem mit NFS und dessen Default-Einstellungen.

Mit dem Kernel 2.6 hatte sich das leider geändert. Selbst geringe Datenmengen (2-3 Aufnahmen gleichzeitig) führten zu hoher Load auf meinem Server, "server not responding" auf den Clients und als Folge Buffer-Overflow im VDR und beschädigte Aufnahmen.

Ursache waren mehrere einzelne Faktoren, die ich hier mit Lösung beschreibe. System ist Debian Etch.

Altes, nicht optimiertes System:

  • NFS-Root
  • NFS per UDP
  • Swap über NBD (Network Block Device)
  • Relativ wenig RAM, d.h. Swap wird immer benutzt
  • Default IO-Scheduler

a. RAM, Swap über NBD

Die Wirkung von zu wenig RAM ist klar. Es wird ständig über das sehr langsame Netz geswappt, was beiderseits erhöhte Load verursacht. Desweiteren ist NBD oft nicht sehr stabil. Bricht NBD zusammen, damit auch der Swap, crasht Linux. Cache ist praktisch auch nicht vorhanden.

Die Lösung aller derartigen Probleme: mehr RAM.

  • Clients: 384MB statt 128MB, kein Swap, kein NBD
  • Server: 512MB statt 384MB, 512MB Swap

Und alles ist schneller ;-)

b. IO-Scheduler

Mein Fileserver hat 6 Platten, 2 Platten im RAID1 als System-Platte und 4 Video-Platten. Wenn kreuz und quer geschrieben wird ist der Default-Scheduler nicht sehr gut.

Umstellen auf CFQ half hier. Kernel-Konfiguration des Servers:

CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y

c. NFS

Die meisten Probleme bereitete NFS. 5 Clients (NFS-Root) greifen ständig auf den Server zu. 2 Clients sind VDRs die zusammen bis zu 7 Aufnahmen bewältigen sollten. Realistisch waren 2-3 Aufnahmen. Absolut inakzetabel.

Geholfen haben hier optimierte Einstellungen.

  1. TCP statt UDP - Mehr Overhead, aber verlorene Pakete sind Sache des Protokolls.
  2. nfsd - Normalerweise laufen davon etwa 8, je nach Distribution. Die nfsd verteilen die Last, eine Art Load-Balancing für NFS. Wenn davon zu wenig laufen bei höher Netzlast gibt es hohe Loads und ständig "server not responding" auf den Clients. Im NFS-HOWTONFS-HOWTO, Abschnitt "5. Optimizing NFS Performance" ist das näher erklärt. Für meine 5 Clients hat sich ein Wert von 100 als brauchbar erwiesen. 72 hingegen waren zu wenig.
  3. Mount-Parameter - Im weiteren half eine Erhöhung der Timeout-Werte und das verwenden von NFS Version 3.

Server: /etc/default/nfs-kernel-server

RPCNFSDCOUNT=100

RPCNFSDPRIORITY=-10

RPCMOUNTDOPTS="--nfs-version 3"

Server: /etc/exports

/tftpboot/10.0.0.11     10.0.0.11/32(rw,sync,no_root_squash,no_all_squash)
/video1.0               10.0.0.0/28(rw,async,no_root_squash,no_all_squash)

Client: /etc/fstab

10.0.0.1:/tftpboot/10.0.0.11 /         nfs rw,tcp,hard,intr,timeo=1000,retrans=10,acregmin=15,nfsvers=3 0 0
herakles.zh.local:/video1.0  /video1.0 nfs rw,tcp,hard,intr,timeo=1000,retrans=10,acregmin=15,nfsvers=3 0 0

d. VDR

Selbst hier half zusätzlich eine kleine Änderung. Die Erhöhung des Aufnahme-Puffers. Vorrausgesetzt man hat genug RAM. Default ist 5MB pro Aufnahme. Ich habe den Wert auf 20MB vervierfacht.

Client: recorder.c

#define RECORDERBUFSIZE  MEGABYTE(20)

Kommentare:

[ keine Kommentare ]


Zuletzt geändert: 28.03.07 | © 1998-2006 | Counter: 228594 seit 15.02.2002, diese Seite: 3302 seit Juni 2006
Startseite
Casio FX-880P
Elektronik
VDR
VDR Patches
VDR Scripts
VDR Plugins
Konfiguration
Referate
Volltextsuche
Gästebuch
Impressum
Sitemap

select language
deutsch 

Suche:

  

openpgp

Valid XHTML 1.0