Also sprach Matthias Albert <[EMAIL PROTECTED]> (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
