Erfahrungsberichte heterogenes Entwickler-Netzwerk
Hallo zusammen,
ich hab hier ein recht buntes Netzwerk bestehend aus verschiedenen Linux
Distributionen in verschieden Versionen (Debian Potato, Woody, Sarge,
SuSE 7.3 - 9.3, Redhat 8-9, Fedora 1-4). Die Art der Nutzung ist
hauptsächlich Software Entwicklung. D.h. cvs zur Revisions Verwaltung,
nfs als verteiltes Dateisystem für die homes und nis zur zentralen
Benutzeranmeldung.
Da es immer mehr Leute werden, wachsen natürlich auch immer mehr die
Anforderungen an die IT-Infrastruktur bzw. die Belastungen auf den
Servern nehmen zu.
Die cvs checkouts erfolgen in das gemountete home (was natürlich sehr
auf die performance geht; ssh, cvs, nfs übers Netz). (gibts hier bessere
Möglichkeiten? openafs(inkl. das in Kauf nehmen von 20-30% geringerem
Datendurchsatz (laut iX10/2002)?
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).
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.
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.
Viele Grüße aus Karlsruhe,
Matthias
Reply to: