SBS 2003 SP1 met Avg. Disk queue length 300+

[CasGas]

Bij een klant van ons hebben we sinds de migratie van Windows Server 2000 naar SBS 2003 (in april) met vlagen last van een trage server. De average disk queue length schiet soms naar 300+ bij de performance monitor, de server word zeer traag waardoor er echt soms gewoon niet te werken valt. Men kan dan geen verbinding meer krijgen met de exchange server, shares etc. Logisch natuurlijk want hij is rete druk bezig.

Sindsdien veel contact gehad met HP en ook een aantal dingen geprobeerd, waaronder het vervangen van de raid controller + disken, zelfs de SATA kabels, nieuwe drivers + software voor de raid controller. Zelfs alle switches vervangen binnen het netwerk helpt niet. HP is al op het moment gekomen dat ze zeggen dat het niet aan de hardware kan liggen en leveren dus ook geen support meer.

Ondertussen ook al virusscanners bekeken, sommige applicaties die men gebruikt geexclude, maar schijnbaar maakt het allemaal niks uit. Zelfs wanneer iedereen gaat lunchen en alleen de pc heeft aanstaan waarbij ze niet even iets aanzetten, maar bijvoorbeeld alleen hun outlook + IE open heeft staan begint de server te bokken, terwijl er dus niks word uitgevoerd.

De server is een standaard HP ProLiant DL145 G2 met 2GB geheugen, er worden geen spannende dingen gedaan op deze omgeving van ongeveer +/- 15 mensen.

Op het moment weet ik dus niet meer waar ik het moet zoeken of waar ik naar moet kijken, hoe kan ik nou precies zien wat de disc queue length veroorzaakt, met filemon.exe zie wel activiteit, maar niet echt wat het veroorzaakt.

Iemand enige suggesties?

[silvans]

Heeft je RAID-controller een battery backupped cache, en staat die goed ingesteld? Kan stukken schelen.

[holoX]

Probeer eens met Diskmon ipv filemon en kijk eens of daar iets opvallends te zien is. Heb je dit al sinds de migratie van de server in april of is het pas kort geleden opgetreden?

[paulhekje]

en heb je al een poging gedaan het proces te identificeren dat de disk op dat moment wil gebruiken?

met taskmanager en het toevoegen van de kolommmen I/O writes I/O reades kom je een heel eind.

[CasGas]

silvans schreef op dinsdag 25 september 2007 @ 13:17:
Heeft je RAID-controller een battery backupped cache, en staat die goed ingesteld? Kan stukken schelen.

Aan de controller zelf is niks veranderd, het is sinds de migratie mis gegaan. Controller is daarna ook vervangen.

pjaminon schreef op dinsdag 25 september 2007 @ 21:59:
Probeer eens met Diskmon ipv filemon en kijk eens of daar iets opvallends te zien is. Heb je dit al sinds de migratie van de server in april of is het pas kort geleden opgetreden?

Sinds de migratie dus, en met Diskmon zie ik wel dat het een en ander word weggeschreven, maar meer dan dat kan ik er niet uithalen..

paulhekje schreef op woensdag 26 september 2007 @ 07:46:
en heb je al een poging gedaan het proces te identificeren dat de disk op dat moment wil gebruiken?

met taskmanager en het toevoegen van de kolommmen I/O writes I/O reades kom je een heel eind.

Dat had ik ook al aangezet maar dan springt er dus niet wat bovenuit wat aangeeft dat er iets fout gaat.


Sommige dingen heb ik er dus niet bijgezet of dat al geprobeerd is, maar ondertussen heb ik al zoveel geprobeerd dat ik niet meer precies weet of ik het gedaan heb of niet

[paulhekje]

Settler schreef op donderdag 27 september 2007 @ 20:21:
(taskmgr)
[...]
Dat had ik ook al aangezet maar dan springt er dus niet wat bovenuit wat aangeeft dat er iets fout gaat.

Dat is toch erg nuttige info: we kunnen nu uitsluiten dat een software probleem of een bokkende applicatie de problemen veroorzaakt.

Het moet dus in de hoek zitten van os/driver/raidcontroller/firmware

Heb je de virusscanner al eens helemaal disabled? en welke scanner/versie gebruik je?

Kun je het probleem zelf veroorzaken door intensieve schrijf/leesacties bijvoorbeeld met de tool "sqlio"?
http://www.microsoft.com/...53442d9e19&displaylang=en
(msi hoef je niet te installeren op server, alleen even de executable eruit halen met install op een pc)

[ Voor 33% gewijzigd door paulhekje op 28-09-2007 08:16 ]

[Gé Brander]

Settler schreef op donderdag 27 september 2007 @ 20:21:
[...]


Sinds de migratie dus, en met Diskmon zie ik wel dat het een en ander word weggeschreven, maar meer dan dat kan ik er niet uithalen..

Heb je in taskmanager gekeken bij Processen, als je daar in het menu kiest voor Beeld, Kolommen Selecteren en dan I/O gelezen bytes, I/O geschreven bytes en I/O overige bytes aanzet, dan kun je zien welke processen heel veel I/O genereren op het moment dat het plaatsvindt.

Als je een virusscanner actief hebt, en je hebt SQL Server draaien, dan zou het kunnen zijn dat je niet de juiste bestanden exclude in je virusscanner. Voor SQL Server moet dat zijn .mdf/ndf/ldf.

Als dat wel goed staat dan kan het nog zijn dat er verschillende onderhouds jobs draaien op SQL Server of backup van de database, dan wel transactie log backup van de database draait op die momenten. Een herindex of backup veroorzaakt ook heel veel I/O.

[ Voor 14% gewijzigd door Gé Brander op 28-09-2007 08:21 ]

[Wirehead]

Inderdaad, ik zou toch bij de virusscanner nog eens kijken. Welke virusscanner wordt er gebruikt? Ik heb hetzelfde gezien op een fileserver 2003 SP1 met McAffee. Zonder reden opeens traag en load de hoogte in.

[CasGas]

Bij het uitvoeren van sqlio krijg ik het volgende:

E:\Data\ICT\Test_Software>sqlio
sqlio v1.5.SG
1 thread reading for 30 secs from file testfile.dat
using 2KB IOs over 128KB stripes with 64 IOs per run
initialization done
CUMULATIVE DATA:
throughput metrics:
IOs/sec: 5817.93
MBs/sec: 11.36

Geen abnormale waardes en ook de disk queue length blijft ongeveer bij 1 tot 1.5, word dus niet overschreden.


Enige wat gebruik maakt van SQL service op de server is BackupExec en die draait alleen maar om 10 uur in de avond.. daar worden overdag totaal geen jobs op uitgevoerd..

[ Voor 17% gewijzigd door CasGas op 01-10-2007 10:11 ]

[Gé Brander]

Maar zijn de SQL Server files ge-exclude in de virusscanner?

[CasGas]

c70070540 schreef op maandag 01 oktober 2007 @ 10:47:
Maar zijn de SQL Server files ge-exclude in de virusscanner?

Die stonden er niet in, maar nu wel ge-exclude:

mdf
ndf
ldf

[Gé Brander]

Settler schreef op maandag 01 oktober 2007 @ 11:06:
[...]


Die stonden er niet in, maar nu wel ge-exclude:

mdf
ndf
ldf

Heel goed, maar vergeet de .bak en .trn niet. Dit zijn de backup files. Is de Avg. Disk queue length nu lager?

[ Voor 6% gewijzigd door Gé Brander op 01-10-2007 16:15 ]

[CasGas]

c70070540 schreef op maandag 01 oktober 2007 @ 16:14:
[...]

Heel goed, maar vergeet de .bak en .trn niet. Dit zijn de backup files. Is de Avg. Disk queue length nu lager?

Die staan er allemaal wel in nu, maar ik kan daar niet meteen een antwoord op geven aangezien het met vlagen gaat, word dus nog even afwachten..

[CasGas]

Settler schreef op dinsdag 02 oktober 2007 @ 17:02:
[...]


Die staan er allemaal wel in nu, maar ik kan daar niet meteen een antwoord op geven aangezien het met vlagen gaat, word dus nog even afwachten..

Nou, de problemen melden zich weer. (alweer een tijdje)
Weer met vlagen dat het traag gaat waardoor de server weer naar 300+ schiet..

Iemand nog suggesties voor andere oplossingen?

[MADG0BLIN]

Ik zie dat je wel dingen hebt geexclude in je virusscanner, maar als je hem disabled of een andere probeert?

[CasGas]

MADG0BLIN schreef op woensdag 02 januari 2008 @ 15:05:
Ik zie dat je wel dingen hebt geexclude in je virusscanner, maar als je hem disabled of een andere probeert?

Zelfs een paar dagen de virusscanner ge-disabled op de server maar dat had ook geen effect

[raymondw]

De eerste reactie die ik zie is ook meteen mijn idee.

Hoe zit het met de cache instellingen van de controller?
Uit behoorlijk wat benchmark runs weet ik inmiddels dat de volgende gegevens ERG belangrijk zijn
- Cache op de RAID controller
- BBU (Cache backup batterij)
- RAID settings en blocksize van de raidset
- Zit de kaart in een PCI(-e) slot met hoge prioriteit

Om even een voorbeeld te geven :
- Sata RAID-5 zonder cache 5/11MB per sec
- Zelde als hierboven maar dan met cache enabled 60MB ! ! (Maar dan is een UPS aan te raden...)

Aangezien ik bij een post van je voorbij zie komen dat de performance op 11MB ben ik nieuwsgierig naar je controller

[_H_G_]

Misschien een log maken met de performance monitor, zodat je ook een idee hebt van de frequentie? (wellicht geeft dat iemand een aanwezig als je weet dat het bijv. precies elk uur gebeurt).

[ Voor 5% gewijzigd door _H_G_ op 03-01-2008 07:35 ]

[HiepHoi82]

Heb zoiets ook wel eens gehad, bleek een apple die niet lekker was die middels IMAP de exchange server plat trok. IMAP connector uitgezet, probleem verholpen. Apple werkstation nagekeken, daarna nooit meer het probleem gezien.
In het taakbeheer zou je ook wat kolommen extra aan kunnen vinken, zodat je ziet welk proces er zoveel IO pakt.

[smartsys]

Controlleer even of er niet een paar gebruikers zijn die nu PST (outlook archieven) op een netwerk share hebben staan.

PST's op een netwerk kunnen een exclusive lock op het filesystem veroorzaken en hierdoor ALLE overige IO op dat filesystem doen stoppen. Dit zorgt voor een excessieve stijging van de disk queue length en soms zelfs in buffer overflows met BSoD's als gevolg.

[Verwijderd]

Hoe zit het met het ram geheugen ? is dat nog binnen de grenzen of gaat dat dat ook swappen ?

[AlterMann]

Mensen.. dit topic is al meer dan een jaar oud..

[Koffie]

Oud