[2003 x64]Quickpar traag op snelle server

[FireDrunk]

Beste Tweakers,

Ik heb een vrij dikke thuisserver:
2x Xeon E5320 1.86Ghz Quad-core,
6GB FB-Dimm,
Intel S5000VSA (2 x Socket 771)
een HP SmartArray P400 Controller met 256MB Cache en een batterij eraan.

Ik heb als temp volume (waar de downloads op binnenkomen) een RAID10 volume van 4 x 15k 36GB SAS schijven

Als storage heb ik 4 x Seagate 7200.11 1.5TB schijven in RAID5

Ik heb er last van dat Quickpar tergend langzaam is.

Om te onderzoeken waar dit aan ligt, heb ik de Performance Monitor van Windows er even op los gelaten, en gekeken waar het probleem in zit.
Nu is mijn Avg Disk queue 50~70, wat mij vrij normaal lijkt tijdens het parren. Dus het lijkt niet aan mijn IO doorvoer te liggen.
Het rare is alleen dat het aantal Page Faults tijdens het parren geregeld tot boven de 150000 komt. Terwijl er maar 7000 pages/sec worden doorgevoerd.

In alle synthetische benchmarks die ik per onderdeel gedaan heb, zijn alle individuele snelheden prima in orde...
Iemand een idee waarom Quickpar zo langzaam is of waarom mijn pc zoveel Page Faults kan staan te genereren?

- Thijs

[Twazerty]

wat is langzaam? (Tijd)

[ Voor 17% gewijzigd door Twazerty op 02-09-2009 19:40 ]

[FireDrunk]

half uur nakijken op 5GB, even zolang op repareren...

[ Voor 3% gewijzigd door FireDrunk op 02-09-2009 19:41 ]

[Twazerty]

thijs_cramer schreef op woensdag 02 september 2009 @ 19:41:
half uur nakijken op 5GB, even zolang op repareren...

Repareren moeten we even buiten beschouwing laten omdat dat een slechte graadmeter is. (Per repair verschilt de tijd) Zo kan het bij mij tussen de 30 seconden en de 40 minuten duren voor 5GB afhankelijk van het aantal missende/beschadigde blokt. Het controleren van 5GB zou vlugger moeten gaan. (Enkele minuten op een single disk). 30 minuten is dus enorm traag. Misschien last van een trage bus tussen je cpu en de harddisks?

[FireDrunk]

Nope, alle synthetische benchmarks laten meer dan 200mb/s zien, en met een beetje queue erop 300mb/s.

Edit: na wat gerommel met andere downloads en andere versie van Quickpar (originele ipv ingebouwde versie van SabNZBd) haal ik 10GB controleren in 3-5minuten...

Wat uitkomt op 27mb/s, terwijl mijn systeem het 10 voudige aan zou moeten kunnen....

[ Voor 55% gewijzigd door FireDrunk op 02-09-2009 19:56 ]

[Twazerty]

10 GB in 3-5 minuten is denk ik redelijk normaal. Volgens mij zou het bij mij ook sneller moeten kunnen maar de disk is toch echt aan het zweten. Kan niet eens normaal een andere file afspelen. Ik denk dat Quickpar zelf gewoon niet optimaal is of dat de schijven op een andere manier worden gelimiteerd. Ik heb ook het gevoel alsof quickpar telkens kleine stukjes leest. Als je wat benchmarks doet met kleine files (<4MB) veel en snel achter elkaar. Wat haal je dan voor een snelheden? (Geen idee of dat wel te testen valt)

[FireDrunk]

RAID10: 210MB/s
RAID5: 285MB/s

[Yalopa]

Persoonlijk vind ik je disk queue erg hoog. Je disk IO is IMO de bottleneck. Kan je eens de opsplitsing posten tussen read en write?

[A3_h]

Is de accu van je HP Controller wel opgeladen/vol? Anders wordt de caching namelijk temp. disabled totdat de accu is opgeladen

[ Voor 47% gewijzigd door A3_h op 02-09-2009 21:27 ]

[FireDrunk]

Tijdens het checken van die 10GB file is na het aanpassen van mijn scale mijn disc queue length 2.5 Dus daar zal het aan gelegen hebben. De gemiddelde leessnelheid is 35~50MB/s tijdens quickpar checken.

Edit: Ja accu is vol

Edit: uitpakken gaat met 70MB/s (schrijven dus)

[ Voor 15% gewijzigd door FireDrunk op 02-09-2009 21:50 ]

[Yalopa]

als het geen disk IO is moet je op zoek naar een volgende bottleneck

CPU bvb. 1 core die 100% doet terwijl de andere cores op 0 staan? eventueel?
pagefile die zeer veel gebruikt wordt?

[nIghtorius]

je 2003 servert.. draait ie een active directory? (iaw: is het een domain controller?)

zo ja, dan heb je al de reden gevonden waarom de performance zo zuigt.. alle vormen van diskcaching worden uitgeschakeld op een 2003/2008 server wanneer het een domain controller is.

[FireDrunk]

Nope geen domaincontroller...

Yalopa schreef op woensdag 02 september 2009 @ 22:04:
als het geen disk IO is moet je op zoek naar een volgende bottleneck

CPU bvb. 1 core die 100% doet terwijl de andere cores op 0 staan? eventueel?
pagefile die zeer veel gebruikt wordt?

Heb 6GB geheugen, dus Pagefile lijkt me stug... geheugen is half vol (of half leeg )
Als ik de affiniteit van Quickpar op 1 core zet haalt ie ong 50/60% cpu...

[ Voor 69% gewijzigd door FireDrunk op 02-09-2009 22:18 ]

[Razwer]

je server kan nog zo tof zijn, maar quickpar is single threaded... dat is je bottleneck.

Deze PAR2 is multicore, maar wel commandline.
http://chuchusoft.com/par2_tbb/index.html

edit: je synthetische schijf tests laten wel stoer 150 mb/s zien maar dat is sequentieel schrijven, PAR2 is dat dus absoluut niet. PAR2 gebruikt ook veel CPU kracht (1 thread maar, als je OS het spreid over meerdere cores is het lang niet zo effectief) en wat RAM.

Daarbij vraag ik me ook af welk OS je draait, gezien als voorbeeld winrar gewoon bar slecht performed op server 2003 in vergelijking tot XP. Ik weet daar het fijne niet van, alleen uit ervaring dat er een grandioos verschil zit in performance.

edit2: had naar topic titel moeten kijken, server 2003 dus... nuff said...

edit3: die bak heb je vast niet thuis staan toch niet stiekem spullen van de baas gebruiken heh?

[ Voor 70% gewijzigd door Razwer op 03-09-2009 00:19 ]

[FireDrunk]

Razwer schreef op donderdag 03 september 2009 @ 00:06:
je server kan nog zo tof zijn, maar quickpar is single threaded... dat is je bottleneck.

Deze PAR2 is multicore, maar wel commandline.
http://chuchusoft.com/par2_tbb/index.html

edit: je synthetische schijf tests laten wel stoer 150 mb/s zien maar dat is sequentieel schrijven, PAR2 is dat dus absoluut niet. PAR2 gebruikt ook veel CPU kracht (1 thread maar, als je OS het spreid over meerdere cores is het lang niet zo effectief) en wat RAM.

Daarbij vraag ik me ook af welk OS je draait, gezien als voorbeeld winrar gewoon bar slecht performed op server 2003 in vergelijking tot XP. Ik weet daar het fijne niet van, alleen uit ervaring dat er een grandioos verschil zit in performance.

edit2: had naar topic titel moeten kijken, server 2003 dus... nuff said...

edit3: die bak heb je vast niet thuis staan toch niet stiekem spullen van de baas gebruiken heh?

Die bak is echt van mij en staat echt bij mij thuis
WinRAR x64 editie performed nagenoeg hetzelfde op XP als op 2003 x64.
Maar als ik de affiniteit op 1 core zet, is de belasting nog steeds niet 100% op 1 core wat wel zou moeten...

[Verwijderd]

Heb je in de config van je SabNZBd toevallig ook aangevinkt dat hij multicore mag parren? Dit is (iig bij de versie die ik heb draaien thuis) een vinkje welke je specifiek moet aanzetten, deze staat default uit.
Even voor de check: Heb je SabNZBd hier op een VM draaien of rechtstreeks op de fysieke bak?

[Razwer]

thijs_cramer schreef op donderdag 03 september 2009 @ 10:41:
[...]
Maar als ik de affiniteit op 1 core zet, is de belasting nog steeds niet 100% op 1 core wat wel zou moeten...

probeer die par2cmdline multicore maar eens. je zal het verschil merken. en zo niet, is het je disk config.
Ik zie trouwens dat je 7200.11 schijven hebt, heb je die jumper er wel af getrokken die hem locked in SATA1 mode?

Verwijderd schreef op donderdag 03 september 2009 @ 10:52:
Heb je in de config van je SabNZBd toevallig ook aangevinkt dat hij multicore mag parren? Dit is (iig bij de versie die ik heb draaien thuis) een vinkje welke je specifiek moet aanzetten, deze staat default uit.
Even voor de check: Heb je SabNZBd hier op een VM draaien of rechtstreeks op de fysieke bak?

Ik ken SabNZBd niet maar las wel ergens dat die ook par2.exe gebruikt. Die kun je vervangen met de par2.exe van de link boven gepaste door mij. Schijnt echt ontzettend performance verschil te maken.

[ Voor 40% gewijzigd door Razwer op 03-09-2009 11:05 ]

[FireDrunk]

Razwer schreef op donderdag 03 september 2009 @ 11:04:
[...]


probeer die par2cmdline multicore maar eens. je zal het verschil merken. en zo niet, is het je disk config.
Ik zie trouwens dat je 7200.11 schijven hebt, heb je die jumper er wel af getrokken die hem locked in SATA1 mode?


[...]


Ik ken SabNZBd niet maar las wel ergens dat die ook par2.exe gebruikt. Die kun je vervangen met de par2.exe van de link boven gepaste door mij. Schijnt echt ontzettend performance verschil te maken.

Die jumper moet ik even kijken, zou best kunnen dat die er nog op zit...

Die Par2.exe ga ik gelijk vervangen Bedankt voor de tip!

[Verwijderd]

Razwer schreef op donderdag 03 september 2009 @ 11:04:
Ik ken SabNZBd niet maar las wel ergens dat die ook par2.exe gebruikt. Die kun je vervangen met de par2.exe van de link boven gepaste door mij. Schijnt echt ontzettend performance verschil te maken.

Dat zou kunnen, maar ik ging er vanuit dat die al wel de snelle versie zou hebben omdat hij al multicore parren ondersteunt. Maar het proberen kan nooit kwaad natuurlijk

[FireDrunk]

Er is een verschil iig, en de par2 uit sab is iig niet x64, en deze wel... bestandsgrootte van origineel was 188KB en de nieuwe 288KB dus is wel verschillend..

De jumpers zaten iig niet op mijn schijven...

[FireDrunk]

Problem fixed
Verified in 1000MB in 4.3s

[Verwijderd]

En dat puur en alleen door de par2.exe te vervangen? Dan ga ik thuis ook maar s rap aan de slag

[Razwer]

thijs_cramer schreef op donderdag 03 september 2009 @ 17:33:
Problem fixed
Verified in 1000MB in 4.3s

dat lijkt er meer op ja
quickpar is van 2004 dus duidelijk niet gebouwd op multithreaded/multicore. Heel veel apps hebben hier last van. Jammer genoeg zijn veel apps nog steeds niet optimized voor multicore opstellingen. Microsoft probeert het op te lossen via het OS maar zoals je hebt gemerkt is dat bij lange na niet efficient en dus een lachertje.
Ik baal dat newsleecher niet multithreaded is met RnE

[FireDrunk]

Misschien ook eens overstappen naar SabNZBd?

[Razwer]

newsleecher heeft andere voordelen en gemakken waar ik wel blij mee ben, dus de trage par feature neem ik maar voor lief.