Performance probleem op Linux SMB server

[Verwijderd]

Hallo, ik zou graag wat ideeen hebben over de volgende situatie: M'n lowcost samba linuxserver performed totaal niet goed
Hardware: Een v/d laatste Asus mainboards,Intel Pentium 1GHz,256MB,2 x (Promise IDE-controllers PCI,PDC20267 Rev2), 8 x Maxtor 98196H8 (80GB), 1 x Netgear GA620 (1 Gb/s NIC)
De IRQ's 3:eth0 4:ide4,ide5 7:ide2,ide3 14:ide0

LVM Informatie:

LV Size 598.00 GB
Current LE 598
Allocated LE 598
Allocation next free
Read ahead sectors 120
Block device 58:0

VG Size 598.00 GB
PE Size 1.00 GB
Total PE 598
Alloc PE / Size 598 / 598.00 GB

ReiserFS: 3.6

Linux 2.4.9 kernel met ReiserFS en LVM support.

Hehe dat is wat typen mjah, - het probleem -
Zodra er gebruik gemaakt wordt van het daadwerkelijk doen wat ie moet doen: fileserver zijn, gaat de load _enorm_ omhoog en gaat er maar iets van 1MB/s naar de Windows clients. Dus als ik 'top' draai zie ik elk smbd process 50%+ v/d cpu nemen terwijl ze bijna geen data naar de client toe krijgen. Ik heb de smb.conf al geheel 'getweaked' met buffers etc en allerlei onnodige dingen eruit.

Imo de belangrijkste lines uit smb.conf:
socket options=TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 /
dns proxy=NO / getwd cache=NO / read raw=NO / write cache size=262144

Het is samba 2.2.1a overigens..

-- Help me verder s.v.p. --


Elke hulp afwachtend
STX

[Verwijderd]

UDMA geactiveerd???

kijk eens met 'hdparm -d /dev/hdx' of ie dan wel

/dev/hdx:
using_dma = 1 (on)

zegt.
LVM ken ik niet echt, maar als dat striping gebruikt (RAID1 of RAID5) en je systeem gaan zonder dma van 8 schijven tegelijk lezen... nee dat wil niet...

Als het niet is geactiveerd kun je het activeren met 'hdparm -d 1 /dev/hdx'

[Verwijderd]

Ehm, stripes heb ik er alleen opgehad in een vroeg stadium, maar toen liet sar -I ALL 2 0 inderdaad een interrupts zien op alle controllers en kwam er helemaal geen performance uit. Over dma.. die promises zijn ata-33 maar de kabels zijn niet ata omdat ze _te_ lang moeten zijn i.v.m. het model van de serverkast.

De hdparms ( ook getweaked ):

multcount = 16 (on)
I/O support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 0 (off)
keepsettings = 1 (on)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)


(Bij vraag.. weet iemand of er een bedrijf is wat lange(!) ata-66/100 cables verkoopt? )

Nog andere ideeen?

[Verwijderd]

Zet toch die dma maar aan (staat uit nu zo te zien)
Als je 80-aderige kabels gebruikt haal je udma66 of udma100, en als je 40-aderige kabels gebruikt haal je udma33, dat is wel mogelijk iets trager, maar als je dma aanzet ontlast je de processor. Nu heb je helemaal geen udma mode maar gewoon pio4 waarschijnlijk.

[Squee]

Je hebt dus 2 IDE controllers, met dus in totaal 4 IDE kanalen.
Ik neem aan dat je met software RAID bezig bent?
Dus, op elk kanaal een Master, en een Slave.

Heb je de Software RAID Howto gelezen?

Daar staat (of in iedergeval stond, toen ik hem een jaar geleden las) in dat je namelijk NOOIT een Master en een Slave op een IDE kanaal in software RAID moet gooien, omdat dat funest is voor je performance!!

Dit... plus dat je blijkbaar geen DMA aan hebt staan, zal leiden tot een ontzettend brakke performance van je fileserver.

Dus: DMA in iedergeval aanzetten op alle schijven, ("hdparm -d 1 /dev/hda" t/m "hdparm -d 1 /dev/hdh").
Je kan ook met hdparm de performance van je RAID array testen.
hdparm -t /dev/md0 (vanuitgaande dat dat je array is natuurlijk)
Je zou dit eens kunnen vergelijken met dat van een schijf:
hdparm -t /dev/hda (bijvoorbeeld)
En dan eens kijken hoeveel snelheidswinst je nu uiteindelijk hebt.
Ik ben benieuwd of deze nog omhooggaat als je bij elk IDE channel de slave eraf zou halen... maar tsja dan is je hele array natuurlijk wel naar de klote en moet je alles opnieuw initializen.

Nou... veel succes ermee, ik hoop dat je hier wat aan hebt.

[edit: korte post in uitgebreid verhaal veranderd]

[blaataaps]

En daar komt nog bij dat smb gewoon een traag en slecht protocol is (:

[Verwijderd]

Weet je zeker dat IRQ 3 alleen gebruikt wordt voor et0, of misschien ook nog voor COM2 of een ander apparaat? Mijn ervaring is dat IRQ's nooit geshared moeten worden, ook al wordt dit ondersteund door de hardware en de software.

Is et0 de enige netwerkinterface in deze machine? In smb.conf is op te geven welke netwerkinterfaces door Samba gebruikt worden, je zou kunnen proberen om daar et0 als enige interface op te geven.

[Squee]

Hmm... heb nog eens opgezocht wat je nou bedoelde met LVM, en dat is dus "Logical Volume Manager", waarmee je partities aan elkaar knoopt?

Maar gaat dit dan dus net zoals RAID0, als striping... of meer eigenlijk als RAID-Linear dat je ze gewoon achter elkaar plakt en geen performance winst hebt...

Als het Linear is zal namelijk dat master/slave gebeuren waar ik het over had waarschijnlijk amper impact hebben op je performance. Volgens mij is dat namelijk alleen van toepassing als dus alle schijven tegelijk/vlak na elkaar geaccessed worden, zoals in een RAID opstelling.

[RG]

dat ligt waarschijnlijk aan het feit dat je IDE gebruikt. Die promise controllers kun je vergelijken met WinModems. Ze hebben zelf niet echt veel logica aan boord. Dus je processor moet dan erg hard werken. Maar 1 MB/sec is wel erg sloom, kan misschien ook liggen aan de netwerkkaart?? benchmark eens het hdparm -t /dev/md0 en hdparm -T /dev/md0 hoe de raw performance is.

[Coen Rosdorff]

Ik heb hier net eens getest:
PII 400 128MB
10GB IBM DTLA
3c905
RedHat 7.2 default install (upgrade naar RedHat build kernel 2.4.9)


Zonder ook maar iets aan de samba config te veranderen haal ik 7MB/s (Gemeten met snmp op de switch) naar een win98se client.

Samba gebruikt volgens top ~ 17 % cpu.

Links zijn 100Mbit halfduplex. (De switch hangt met 100Mbit poort aan de 100Mbit-only hub.)

[easydisk]

Ik zou je kernel eens upgraden, met 2.4.9 had ik ook last van hogere loads en vooral heel veel geswap.
De 2.4.12 is wel OK, en 2.4.13 ook.

De 2.4.9 kernel van RedHat is niet gelijk aan de 2.4.9 kernel van de ftp site/Linus. (er zitten veel verschillen tussen, o.a. de hele ac patch serie)

[Verwijderd]

Imo de belangrijkste lines uit smb.conf:
socket options=TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 /
dns proxy=NO / getwd cache=NO / read raw=NO / write cache size=262144

als ik jou was zou ik de "getwd cache" en de "read raw" maar wel aanzetten. lees het "Samba Performance Tuning" uit het "Using samba" boek wat samba zit eens.

[Verwijderd]

Bedankt voor de reacties, ik ben vandaag over gestapt op FreeBSD. Wat een ontzetend proffesioneel aanvoelend os is dat zeg, complimenten. Het probleem met de hoge load ligt inderdaad aan het hele IDE-gebeuren, _vooral_ het schrijven is het probleem. Ik ben nu VINUM (http://www.vinumvm.org) aan 't gebruiken op een andere manier qua striping.

Ik heb nu alle master disks in 1 volume gezet en alle slave disks in een tweede volume. Zodat bij het schrijven de IDE kabels vol zitten met data naar maar 1 disk per controller. Zodra natuurlijk ook het andere volume veel gebruik wordt dan gaat 't natuurlijk minder, maar ik zal jullie op de hoogte houden van de resultaten.

Alvast wat config spul van de Vinum Volume Manager:
1 plexes: P masterstripe.p0 S State: initializing Subdisks:4 Size:305 GB 4 subdisks:
S masterstripe.p0.s0 Size: 76 GB
S masterstripe.p0.s1 Size: 76 GB
S masterstripe.p0.s2 Size: 76 GB
S masterstripe.p0.s3 Size: 76 GB

Wat ik verder direct wil vertellen is dat de automatische loadbalacing / cachemanagement van FreeBSD erg goed werkt, ben benieuwd hoe 't servertje straks draait..

2-b-continued,
Leroy

[Verwijderd]

Kleine update: de Vinum stripe doet nu 36 MB/s op gewoon dma, krijg morgen of overmorgen speciale lange ata kabels.

[Verwijderd]

Op vrijdag 26 oktober 2001 19:41 schreef easydisk het volgende:
Ik zou je kernel eens upgraden, met 2.4.9 had ik ook last van hogere loads en vooral heel veel geswap.
De 2.4.12 is wel OK, en 2.4.13 ook.

De 2.4.9 kernel van RedHat is niet gelijk aan de 2.4.9 kernel van de ftp site/Linus. (er zitten veel verschillen tussen, o.a. de hele ac patch serie)

Even offtopic: Kernel 2.4.13 is niet oke, na een nachtje console weer terug in X zie ik dat kswapd 99% van de CPU resources gebruikt op een P3 1000 met 512 MB en nog zat mem free. Nu twee keer in twee dagen gebeurd en het enige dat helpt is reboot. Inmiddels over op 2.4.13-ac4 (ongewijzigde config) en eens kijken of het morgenvroeg weer zo is.

[Verwijderd]

FreeBSD gaat t worden voor mij denk ik

[Infern0]

FreeBSD rulez idd
Er is ook nederlandse pagina over freebsd in aanbouw
http://www.bsdfreaks.nl

[Verwijderd]

Okay dan, hier de performance:
read Cusl95OI5.pqi
Read speed for file Cusl95OI5.pqi (403098427 bytes)
Please wait while reading file...
Readspeed 76.88 MB/sec

ZEER ZEER GOED IMO!!