Re: Erfahrungsberichte heterogenes Entwickler-Netzwerk
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).
Am IO-Scheduler drehen bringt meist was. Fuer ein Raid wurd' ich den
"deadline" waehlen.
# echo deadline > /sys/block/sd[abcd]/queue/scheduler
und mit "blockdev" den readahead auf 8192 setzen
# blockdev --setra 8192 /dev/[sm]d[abcd]
Tests mit tiobench/iozone haben mich ueberzeugt.
> 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.
¹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.
>
> 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.
> Viele Grüße aus Karlsruhe,
>
> Matthias
sl ritch
Reply to: