Richard Mittendorfer wrote:
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.
Einen schönen guten Morgen,
ich hab meine Probleme jetzt endlich in den Griff bekommen. Wie? Durch
das Ersetzen meines alten Raid Controller (3ware 8506-4 (2Mb Speicher))
mit einem 3ware 9500S (128Mb Speicher), das hinzufügen einer 4ten Platte
(beides zusammen hat mir einen Performance Boost von Faktor 2 verpasst).
Da mir das alles aber immer noch zu langsam war (ich hab ein paar
intensive tests mit time, dd, tar, cvs und rm gemacht), hab ich mein
Raid 5 in die Tonne getreten und mich für ein Raid 10 entschieden (jetzt
ist es ca. um Faktor 4 schneller als ursprünglich).
Seit dem hatte ich keine load höher als 2 (bei einer Vollauslastung),
keine hängende Editoren oder Programme (/home wird bei uns via nfs
exportiert), eine richtig schnelle Netzwerkübertragung mit Gigabit
(bacula Backups 45Gig zu sichernde Daten in ~16 min :-) (vorher waren es
ca. 35min, sprich auch hier war der Flaschenhals der zu niedrige disc io)).
Ich bin zufrieden, meine Kollegen sind zufrieden, alles ist super :-).
Viele Grüße aus Karlsruhe,
Matthias
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
