ernsthaftes Server Problem
Hallo zusammen,
vielleich erinnern sich manche noch an diesen Beitrag vor ein paar Wochen
Hallo zusammen,vor ein paar Monaten hab ich hier nen neuen Server mit
Debian Woody und nem 2.4.22 Kernel aufgesetzt.
Hardware Ausstattung
********************
AMD Duron 1200 Mhz
RAM 512 DDR
Adaptec 2120S Raid Controller mit 3 x 60 Gig IBM SCSI Platten.
(Raid 5 amlaufen).
Mein Problem ist jetz folgendes. Auf dem Server läuft nfs, nis, cvs, samba
etc. Zentrale Benutzeranmeldung und verteiltes Dateisystem.Insgesamt
hängen ca.20 Rechner in dem Netz(18linux kisten + ne sparc + ein powermac+
2 windowskisten -darum Samba) die das ganze nutzen.
Möcht ich mich auf dem Server per ssh einloggen -> dauert das schon nen
kleinen moment (5-10 sek)Möcht ich was per cvs aus/ein checken das
gleiche.Vorher lief ein Suse 7.3 mit IDE System -> da ging das wunderbar.
Ich habkeine Ahnung woran das liegen könnte.Was ich festgestellt habe ist
folgendes. iptraf zeigt mir dass derNetzwerktraffic ein wenig merkwürdig
ist. Meist liegt er unter 500kbyte...Schieb ich ne grosse File auf den
Server -> geht es hoch bis max 10 Mbyte <- das hab ich einmal gesehen,
war absolute spitze, abereinmalig...im schnitt würd ich aber sagen liegt
er bei 3 Mbyte. Das ganze aber nicht konstant sondern mit grossen
Schwankungen.Jemand ne Idee was es sein kann? Was ich heute abend
ausprobieren werdeist ein neuer Kernel (2.6.1)Ansonsten aber recht
ratlos. Vielleicht is die Netzwerkkarte auch defekt(die Schwankungen) aber
dass is nur ne Vermutung.Könnte es am SCSI Raid liegen?Bin für jeden Tipp
dankbar.
Den 2.6.2 Kernel hab ich getestet, da gabs leider ein Problem mit lvm da
es ab dem neuen eben nur noch lvm2 und kein lvm1 mehr gibt. Man könnte es
konvertieren, aber das will ich erst mal auf nem Testsystem versuchen :-).
Der Write Cache auf dem Raid Controller hat eine erhebliche Performance
Steigerung gebracht. Den langsamen ssh/cvs login hab ich über die
/etc/hosts lösen können, indem ich alle hosts eintrug (reverse lookup hat
nicht so geklappt wie ich mir das vorgestellt habe).
2 Tage später dann das.
01:19:45 duke kernel: init_special_inode: bogus imode (167107)
01:19:45 duke kernel: init_special_inode: bogus imode (53243)
01:19:45 duke kernel: init_special_inode: bogus imode (76015)
01:19:45 duke kernel: init_special_inode: bogus imode (151322)
+ ganz viele ext3 errors
fsck.ext3 -n /device -> gaaaanz viele Fehler.
Alle User vom System weg. init s -> fsck.ext3 /device und mal 5h (110 Gig)
laufen lassen.
Der hat sich dann die ganze Zeit ausgekotzt wo es denn hagt. Wie gesagt
nach 5h war er fertig.
Danach war ein paar Tage ruhe und seit vorgestern hagelt es wieder
01:19:45 duke kernel: init_special_inode: bogus imode (167107)
01:19:45 duke kernel: init_special_inode: bogus imode (53243)
01:19:45 duke kernel: init_special_inode: bogus imode (76015)
01:19:45 duke kernel: init_special_inode: bogus imode (151322)
mit diesen Teilen hier.
fsck sagt allerdings clean (noch)
Vor dem SCSI Raid hatten wir wie oben schon erwähnt ein Suse 7.3 IDE
System. Als der plattenplatz zu ende ging wollten wir mit ner 200 gig
platte aufrusten...
Darauf hatte das Suse allerdings keine Lust. Da dachte ich optimaler
Zeitpunkt um auf Debian umzusteigen. Neues System mit Debian -> läuft.
Dann 5 Wochen später -> Festplatten schaden -> Wechsel auf SCSI Raid und
jetzt dass.
Kurz um ich hab hier nen Server der eigentlich nicht wirklich zu
gebrauchen ist.
Doch mal mit nem aktuellen Suse versuchen? Vielleicht sieht es mit ihrem
120 patches gepatchtem Kernel besser aus -> jemanden Fragen der sich damit
auskennt.
Bin für jeden Tipp dankbar. Dazu gleich noch ne Frage bzg. Backup -> wie
würdet ihr das ganze sichern (ca. 100 gig) -> per Band, externes SCSI
Gehäuse -> übers netz auf einen rechner der eine grosse platte drin hat?
Viele Grüsse aus Karlsruhe,
Matthias
Reply to: