AMD/SQL performance vraagstuk.

[Verwijderd]

Vraagstuk.

Ik heb hier een aantal SQL/2000-SP3a dozen. Twee daarvan zijn "bijzonder" te noemen. Het gaat hier om de volgende bakken;

• HP DL580, 4x Xeon 2.iets GHZ HyperThreaded, 16GB mem, 2 x SA6400/320MB dual Channel, 2x Disk encosure (Elke controller eentje) met respectievelijk 6 x 300GB/10k Raid-1 (SQL-DATA) en 6x 72GB/15k Raid-1 (SQL-LOG)
• HP DL585, 4x Opteron 2.iets GHZ Single Core, 16GB mem, 2 x SA6400/320MB dual Channel, 2x Disk encosure (Elke controller eentje) met respectievelijk 6 x146GB/10k Raid-1 (SQL-DATA) en 6x 72GB/15k Raid-1 (SQL-LOG)

Beide dozen draaien Windows 2003/SP1 ze hebben hot add memory dus zijn automatisch PAE, de boot.ini is eveneens gezet op PAE en /3GB zoals Microsoft ons voorschrijft

De SQL server versie is SQL2000/SP3a (SP4 nog ff niet, dat is nog te instabiel, zeker met AWE) SQL is gezet op Dynamic mem allocation , Reserve to SQL. En AWE is enabled binnen SQL server (SP_Configure 'AWE enabled','1')

Leuke bakjes zou je denken. Nu onze fustratie;

We hebben een Databasje (test dingetje, test2 genaamd), 1.8GB groot, 200.000 records, twee velden ID, en NVARCHAR(4000)

We doen op de SQL server zelf, SELECT * from Test2 (vanuit en net opgestarte SQL, dus geen cache aanwezig)

Onze Intel doos gaat vrolijk aan de slag en spuugt de data binnen 2 minuten uit (average 1:42)

Onze AMD doos gaat minder vrolijk aan de slag, en spuugt de data binnen 5 minuten uit (average 04:53)

Doen we de Query vanuit een secondary SQL/Query Analyzer (dus niet op de server zelf) duurt het grapje op beide servers rond de 5 minuten, (de AMD is dan zelfs gemiddeld 10 seconden sneller)

We hebben van alles geprobeerd, maar niets helpt de AMD vooruit, iemand enig idee

[wizl]

Zit er verschil in de query execution plans als je die bekijkt?

[Rolfie]

Het eerst waar ik aan denk is kijk eens of je de laatste BIOS versies op de array controller / Disken en Servers hebt draaien. Kijk eventueel ook eens naar je Disk IO met perfmon als je de query draait.

[TheekAzzaBreek]

Als je een select * doet, en dus 200.000 records over het scherm laat rollen, gaat er veel tijd naar de scherm opbouw. Krijg je hetzelfde beeld als je select max() doet? (Max op een ongeindexeerde kolom, natuurlijk)

[ Voor 12% gewijzigd door TheekAzzaBreek op 25-07-2006 07:37 ]

[richard_kraal]

ff een beetje offtopic

heb inmiddels al wat dozen neer gezet die wel SP4 + AWE patch enabled waren

draait supers, geen storingen of instabieliteit

(dl360 g4p, dual dual core cpu, 12gb ram, 1x 6402/512mb 6x72gb 15k)

[Verwijderd]

wizl schreef op dinsdag 25 juli 2006 @ 07:13:
Zit er verschil in de query execution plans als je die bekijkt?

Nope (bijna) exact het zelfde.. ook de IOSTATS zijn ongeveer identiek als het gaat om reads,

[Verwijderd]

richardkraal schreef op dinsdag 25 juli 2006 @ 14:57:
ff een beetje offtopic

heb inmiddels al wat dozen neer gezet die wel SP4 + AWE patch enabled waren

draait supers, geen storingen of instabieliteit

(dl360 g4p, dual dual core cpu, 12gb ram, 1x 6402/512mb 6x72gb 15k)

I know, maar onze DBA's zijn erg kritisch, er zitten wat dingetjes in SP4, die niet helemaal goed zijn, dus voor hun is het een No/Go. En dus zitten wij met SP3a in onze maag.. thats life in the corporate world,..

[Verwijderd]

Rolfie schreef op dinsdag 25 juli 2006 @ 07:16:
Het eerst waar ik aan denk is kijk eens of je de laatste BIOS versies op de array controller / Disken en Servers hebt draaien. Kijk eventueel ook eens naar je Disk IO met perfmon als je de query draait.

Alle firmwares en biossen (Array controller / Server ) zijn naar het meest recente nivo geupdate (-Duh-).

Als ik een benchmark doe op disk IO zijn de controllers 'gewoon' snel, 120MB+..

[Verwijderd]

TheekAzzaBreek schreef op dinsdag 25 juli 2006 @ 07:35:
Als je een select * doet, en dus 200.000 records over het scherm laat rollen, gaat er veel tijd naar de scherm opbouw. Krijg je hetzelfde beeld als je select max() doet? (Max op een ongeindexeerde kolom, natuurlijk)

Dat heeft idd een veel beter resultaat, doet een return in ongeveer 20 seconden, (en 2 seconden de tweede keer, vanuit de Cache..)

[Verwijderd]

Verwijderd schreef op dinsdag 25 juli 2006 @ 15:44:
[...]


I know, maar onze DBA's zijn erg kritisch, er zitten wat dingetjes in SP4, die niet helemaal goed zijn,

zoals? of bedoel je de applicaties van ons gebruiken undocumented features en die zijn veranderd in sp4...

[TheekAzzaBreek]

Verwijderd schreef op dinsdag 25 juli 2006 @ 16:26:
[...]


Dat heeft idd een veel beter resultaat, doet een return in ongeveer 20 seconden, (en 2 seconden de tweede keer, vanuit de Cache..)

Ok, dus we hebben het over video performance, niet database performance, of zie je met max() nog steeds grote verschillen?

[Verwijderd]

TheekAzzaBreek schreef op dinsdag 25 juli 2006 @ 21:49:
[...]


Ok, dus we hebben het over video performance, niet database performance, of zie je met max() nog steeds grote verschillen?

ik denk niet zo zeer video perfomance, de ISQLW voert eerst alles uit, en dumpt het daarna op het scherm. Ik denk eerder dat 1.8GB aan data niet lekker gaat op een Windows 2003 server die getuned is also Database server. Het OS heeft maar 1GB ram, de rest is voor SQL.

Met de Select MAX gaat het vlug ~20 seconden, de AMD is ietsje sneller dan de intel bak. maar dat mag geen naam hebben. Met complexe queries zal het zich moeten bewijzen. De zijn nu bezig een kopie van de produktie database op de servers te planten en dan wat SQL profiler replays te doen om te zien of het allemaal houd.

J.

[TheekAzzaBreek]

Kijk, dat is nou een test waar je wat aan hebt. 1.8 GB aan platte data door een client spoelen is geen veel voorkomend scenario.
Je vorige test was voornamelijk een client test,en of de beperking nou zit in de snelheid waarmee de client al die data kan verwerken of waarmee hij het kan presenteren weet ik eigenlijk niet. Bij de Oracle client SqlPlus is het het laatste, als je het window minimized, of er een ander window overheen legt die Sqlplus grotendeels bedekt, gaat alles enkele malen sneller. Dat zou je ook een kunnen proberen, maar erg interessant is het allemaal niet. Ik ben veel benieuwder hoe die servers zich onder echte database belasting houden.

[Verwijderd]

Verwijderd schreef op dinsdag 25 juli 2006 @ 17:53:
[...]
zoals? of bedoel je de applicaties van ons gebruiken undocumented features en die zijn veranderd in sp4...

Er schijnt nog al wat te zijn met Replicatie (ik ben geen DBA, dus erg diep ga ik niet in deze materie). als je wilt kan in een van de DBA's wel vragen wat nu precies de 'problemen' zijn.

[Verwijderd]

TheekAzzaBreek schreef op woensdag 26 juli 2006 @ 06:39:
Kijk, dat is nou een test waar je wat aan hebt. 1.8 GB aan platte data door een client spoelen is geen veel voorkomend scenario.
Je vorige test was voornamelijk een client test,en of de beperking nou zit in de snelheid waarmee de client al die data kan verwerken of waarmee hij het kan presenteren weet ik eigenlijk niet. Bij de Oracle client SqlPlus is het het laatste, als je het window minimized, of er een ander window overheen legt die Sqlplus grotendeels bedekt, gaat alles enkele malen sneller. Dat zou je ook een kunnen proberen, maar erg interessant is het allemaal niet. Ik ben veel benieuwder hoe die servers zich onder echte database belasting houden.

Ben ik helemaal met je eens, maar toch is het vershil van gedrag tussen de twee dozen 'vreemd' te noemen. Momenteel worden er 'real life' scenario's op de dozen los gelaten, Ik ben benieuwd hoe een en ander zich verhoud tot de normale productie omgeving (HP / Blade BL45 / 4xO -DC 16G mem met FC geknoopt aan een EVA 8000)