Re: Erfahrungsberichte heterogenes Entwickler-Netzwerk
Richard Mittendorfer wrote:
>Also sprach Matthias Albert <m.albert@sysadmin.aicas.de> (Thu, 10 Nov
>2005 17:28:26 +0100):
>
>
>>Hallo zusammen,
>>
>>
>
>Hi there,
>
>
>
>>[...]
>>
>>File-/CVS-/NIS-server ist ein Dual Xeon 2.8 Ghz mit 2 Gig Ram und nem
>>750Gig SATA Raid 5(3ware escalade 8506-4) (Flaschenhals hier, sind bei
>>gleichzeitigem checkout von 300Mbyte großen Modulen von 10 Benutzern die
>>Festplatten bzw. das Raid). Innerhalb von 1-2 Minuten hat der Server
>>eine Load von 10.
>>
>>Die CPU's sind dabei zu 80% idle. RAM ist noch genügend zur Verfügung
>>(geswappt hat er bis heute noch nicht) und das Netzwerk funktioniert
>>soweit auch tadellos (Gigabit mit hohen Übertragungsraten). Was ich
>>sehen konnte über top, dass wenn er kräftig am arbeiten ist, er
>>hauptsächlich in den Kernel Funktionen "lock_page" und "wait_on_b"
>>steckt (konnte aber noch nicht herausfinden was genau die machen).
>>
>>
>
>evtl. mal mit dstat/vmstat sehen wie hoch io-wait ist. Fuer
>Langzeitanalyse ist sysstat (sar/iostat) recht nuetzlich. Hab hier
>SW-Raid auf scsi, alt aber flott, am laufen und kann mir den recht
>hohen io-wait beim 2.6er auch nicht recht erklaeren. 2.4 war hier IMHO
>besser unterwegs. Was da helfen koennt', sind andere FS's/Mountoptionen
>(Fileserver).
>
>
>
Mit dstat und vmstat hab ich die Tage schon ein paar Tests
gemacht. Da
konnte man wirklich sehr schön sehen, wenn man große Files
überträgt,
wie das Netzwerk Interface am übertragen ist und die Platte
anfängt zu
schreiben. (was auffälliges konnte ich aber nicht erkennen)
iostat hab ich heute morgen mal laufen lassen, sowohl unter
richtiger
Last (system load von 10-17) als auch unter niedriger last
(system load
von 0-3). Unter Vollzeit hatte ich einen durchschnittlichen
iowait
gemessen über 4minuten hinweg von 60.9%
Im `top` kann ich erkennen, dass die "wa" Spalte der CPU's
(ich nehm an
das ist ebenfalls der io-wait) unter Last recht hohe Werte hat
(Voll-Last=schwanken zwischen 40-80).
Verwendetes Filesystem ist: reiserfs3.6 (reiserfs kann mit
vielen files
angeblich besser umgehen als ext3 (wir haben hier ca. 5
Millionen Files)
OS auf dem Server: Debian Sarge mit nem
2.6.8-11-em64t-p4-smp Kernel.
>Am IO-Scheduler drehen bringt meist was. Fuer ein Raid wurd' ich den
>"deadline" waehlen.
># echo deadline > /sys/block/sd[abcd]/queue/scheduler
>
>
das werd ich heute mittag bzw. am weekend mal testen
>und mit "blockdev" den readahead auf 8192 setzen
># blockdev --setra 8192 /dev/[sm]d[abcd]
>Tests mit tiobench/iozone haben mich ueberzeugt.
>
>
>
Bei 3ware konnte ich dieses pdf finden
http://www.3ware.com/LinuxWP_0701.pdf
Daher hab ich bei mir den readahead auf 16384 gesetzt. Laut
hdparm komm
ich da auf folgende Werte
hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 2644 MB in 2.00 seconds = 1322.20
MB/sec
Timing buffered disk reads: 324 MB in 3.01 seconds =
107.80 MB/sec
was ja eigentlich nich ganz schlecht ist :-)
Die Festplatten Tests wie sie in dem pdf stehn, werd ich
ebenfalls heute
mittag nochmals an.
>>Habt ihr irgendwelche Vorschläge, Tipps und Tricks was sich in diesem
>>Szenario so alles anbieten würde? Bzgl. performance, cvs und nfs evtl.
>>openafs, aber auch Hardwaremäßig oder aufsplitten von Daten und
>>Dienste. Was habt ihr da so für Erfahrungen gesammelt? Bin für jeden
>>Tipp und Hinweis sehr dankbar.
>>
>>
>
>In Sachen (Kernel-)NFS hab ich hier nicht mehr viel rausholen koennen.
>Ein moderner Kernel scheint da recht gutes Autotuning zu beherrschen.
>Ob das nun fuer alle Distris gilt, kann ich nicht sagen. Im NFS-Howto¹
>kannst' da ein wenig Info finden. Einige der Eintraege
>unter /proc/sys/net² koennen auch noch etwas bringen. Hilfreich war
>scheinbar ../core/[rw]mem_default und *_max³ raufzuschrauben.
>In /proc/sys/vm koennte rumschrauben auch was bringen, aber besser
>Finger weg, wenn nicht klar ist, was was macht :) (Mir sind die meisten
>Zusammenhaenge nicht bewusst). Dazu findet sich ein wenig in der
>Kerneldokumentation.
>
>
Genau sowas hatte ich noch gemacht. Den rmem_default und
rmem_max
verdoppelt auf 262144. wmem_default und wmem_max sollte ich
da auch noch
erhoehen.
Außerdem hab ich die Anzahl der NFSD's auf 20 erhoeht (hab
gelesen, dass
man pro CPU zwischen 4 und 8 NFS Daemons verteilen koennte
(default war
8). Dank HT hab ich 4 CPU's.
- von sync auf async gewechselt und mit der r und wsize
herumgespielt.
Allerdings ist das ziemlich kompliziert, da ich hier sehr viele
verschiedene Distris habe (inklusive verschiedener Versionen
SuSE 8.0,
8.1, 8.2 usw.).
Meine Tests haben ergeben, dass ich die r und wsize nicht
global auf
z.B. 8192 setzen kann, sondern dass ich die bei jedem Client
anpassen
müsste. Getestet wie folgt.
mount -t nfs server:/pfad /mount-path -o
rw,rsize=xxxx,wsize=xxxx
dd if=/dev/zero of=/mount-path bs=16k count=10000
>¹http://www.tldp.org/HOWTO/NFS-HOWTO/performance.html
>²http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html
>³http://www-didc.lbl.gov/TCP-tuning/linux.html
>
>Generell ist aber zu sagen das proc-tuning zeitaufwendig ist und in
>vielen Faellen wenig/kaum was bringt und vollkommen vom/n
>Verwendungszweck/Umgebung/Maschine abhaengig ist.
>
>
das kann ich mir sehr gut vorstellen.
>
>
>>Achja, gestern bin ich noch zuerst über das Paket irqbalance gestolpert
>>und später hab ich dann noch von Hand die interrupts des raid
>>controllers und der netzwerkkarte auf die cpu's verteilt. (stichwort cat
>>/proc/interrupts; echo 8 (z.B.) >
>>/proc/irq/<controller-irq>/smp_affinity. Das hat performance technisch
>>sehr viel gebracht.
>>
>>
>
>Denk ich mir. Alles was gleichzeitig verwendet wird trennen.
>
>
Das dachte ich mir auch und hab von Hand eben das netzwerk
interface und
den raid controller getrennt. Jetzt ist es nur so, dass
irqbalance
zumindest für den Raid controller, dass selbst festlegt und
meine
Einstellungen überschreibt. Ne Idee wo ich das festlegen
kann?(die man
page hilft da nicht wirklich weiter :))
Vielen Dank für deine Links und die vielen Tipps. Werd mich
da gleich
mal einlesen.
Viele Grüße,
Matthias
Reply to: