Baan IV op MSSQL2000 op Win2003: Xeon of Opteron?

[Verwijderd]

Heren, dames, drankjes,

Ik moet binnen nu en twee weken een advies uitbrengen voor een nieuwe database server voor ons Belgisch filiaal. Omdat ze daar 4 man hebben zitten gaat alle IT support hiervandaan komen (c'est moi!) en ook de server zal in Nederland gekocht worden.

Ik ben er min of meer uit hoe de machine moet gaan werken. Het wordt in elk geval een dual CPU machine, met minstens 1.5 GB RAM en vier 10Krpm disks (raid-5 op drie disks en een losse voor de transaction logs, die zijn sneller op een losse disk dan op een RAID)
Het OS wordt Windows 2003 Server, 32bit. In verband met stabiliteits problemen die ik gewoon niet kan hebben in dit geval wil ik absoluut geen 64bit w2k3 gaan gebruiken. MS SQL Server is niet verkrijgbaar als 64bit versie voor de AMD64 versie van Windows 64bit, dus dat is lekker makkelijk: de 32bit versie is ook hier heilig.

Mijn vraag is, of het nut heeft (performance-wise) om "de gok" te nemen en Opteron processoren te bestellen ipv Xeon². Mijn uiteindelijke leidinggevende is nogal Intel fan dus ik moet wel een functioneel ontwerpje afleveren. Omdat het hier draait om een heel specifieke toepassing, leek het me handig eens bij SSA Global (eigenaar van Baan) te gaan snorren naar voorkeuren. Echter, op de Baan supportsite vind ik vooral threads van mensen die in hun specs wel noemen dat ze opterons gebruiken, maar óf het is een 8way server (en dan is het nogal wiedes dat de Opteron veel sneller is) óf het heeft helemaal niets met het topic te maken.
Op de site van Microsoft vind ik één heel topic waar iemand vraagt of de performance van een Opteron systeem beter zou zijn dan een Xeon, maar hij vertelt niet wat ie er mee wil doen én niet wat het bakkie verder voor config heeft, dus daar wordt ik niet heel erg blij van.
Een ander topic op de MS communities site gaat over of het een xeon of opteron moet worden in een high-end enterprise cluster, maar het blijkt vooral te hangen op I/O. Dat is dus ook geen zinnig draadje aangezien die user best met een kudde 500 mhz CPUs kan werken.
Op diverse sites kom je links tegen naar een review van Anandtech, maar die testen dan weer met MySQL op Linux, twee programma's die ik a) niet op die server wil hebben en b) niet representatief voor performance in MS SQL kan noemen. Ik heb het artikel wel gelezen, en gezien dat het "omslagpunt" voor Xeon² vs Opteron² weer netjes op de dual-lijn ligt. Van dit review werd ik dus alleen maar minder zeker.

Heeft er iemand ervaring met MS SQL op een (bij voorkeur dual) Opteron systeem én kan diegene toevallig iets melden over de performance in vergelijking met een plusminusongeveerus hetzelfde uitgeruste Xeon machine? Het prijsverschil is geen verkoop argument (de server heeft zichzelf met een maandje of drie, vier terug verdiend als de zaken gaan zoals ze zouden moeten, en dat gaan ze hier 90% van de tijd...)

[ Voor 6% gewijzigd door Verwijderd op 31-08-2004 17:32 ]

[Zwelgje]

als prijs geel rol speelt zou ik persoonlijk voor de xeon server gaan.

waarom das industry standard, niks ten nadele van AMD cpu's maar intel speelt al heel wat jaren mee in de high-end server markt

stel dat er iets niet goed werkt aan die server met opterons, hoe verkoop jij dat aan je baas?

en het aloude gezegde gaat ook hier weer op 'nobody ever got fired for bying IBM' waarmee ik niet wil zeggen dat je ibm moet nemen, maar dat je gewoon de grootste/meest gerenomeerde oplossing moet nemen, zo kan je jezelf tenminste indekken voor als het mis mocht gaan

[MoBi]

Even iets anders, als er alleen sql server opkomt, kan je beter 2 raid 1 sets nemen, das namelijk sneller, liever 3. Opteron is beter voorbereid op de toekomst. Ook merken als hp hebben dual opteron servers in de aanbieding. Dus dan hoef je ook niet aan zelfbouw te denken.

[Koffie]

Euh , MoBi;
Ik denk dat je RAID-2 bedoeld, RAID-1 is disk mirroring, daar worden je arrays echt niet sneller van.
Verder zou ik nooit, maar dan ook nooit een productie DB op iets anders dan RAID-5 plaatsen
Het enige wat bij mij op een hardware mirror komt, is het OS zelf.

[Brothar]

Baan ? Maar wat doen Baan-software ?
Ik heb ooit begrepen dat Baan zijn database dusdanige heeft opgebouwd dat bijn aelk veld een eigen tabel heeft. Een search betekent dan véél I/O en veel (FP ?) rekenkracht voor het sorteren van het resultaat.
Qua rekenkracht staat me bij dat de Opteron te verkiezen is ...

Kort gezegd: welke functionaliteit vereist Baan, en welke cpu biedt daarvan het meest ...

[HeepH]

ik weet verder geen kl**t van dual server dingen af, maar meen een tijdje terug bij toms hardware gelezen te hebben dat een dual opteron sneller was in mysql als een dual xeon van dezelfde ''snelheid''

[Koffie]

Da's mooi voor ome Tom, maar er staat toch echt MSSQL in de titel

[HeepH]

dat werkt toch ongeveer hetzelfde ? toch allebei database applicatie enzo...?


* HeepH is echt een complete noob

b) niet representatief voor performance in MS SQL kan noemen.

of niet natuurlijk

[ Voor 37% gewijzigd door HeepH op 31-08-2004 23:46 ]

[Verwijderd]

Koffie schreef op 31 augustus 2004 @ 23:26:
Ik denk dat je RAID-2 bedoeld, RAID-1 is disk mirroring, daar worden je arrays echt niet sneller van.
Verder zou ik nooit, maar dan ook nooit een productie DB op iets anders dan RAID-5 plaatsen

Ik adviseer mijn klanten altijd 3 x raid 1 ( 1 set OS, 1 set DB en 1 set logfile)
Als ze geld teveel hebben, die set nog een mirroren (raid 10 heet dat geloof ik)

Liefst met 15k disks en een dual channel controller met voldoende geheugen met battery write cache erop.

Raid 5 roept bij mij altijd de associatie met een fileserver op, niet met een snelle database server.
Smaken verschillen, of moet ik terug naar school

[ Voor 12% gewijzigd door Verwijderd op 01-09-2004 01:19 ]

[Verwijderd]

Verwijderd schreef op 01 september 2004 @ 01:15:
[...]


Ik adviseer mijn klanten altijd 3 x raid 1 ( 1 set OS, 1 set DB en 1 set logfile)
Als ze geld teveel hebben, die set nog een mirroren (raid 10 heet dat geloof ik)

Liefst met 15k disks en een dual channel controller met voldoende geheugen met battery write cache erop.

Raid 5 roept bij mij altijd de associatie met een fileserver op, niet met een snelle database server.
Smaken verschillen, of moet ik terug naar school

Je praat niet over de boekhouding van een bedrijfje van 30 man... dat zou ik ook wel op losse disks willen doen. Maar bij gegarandeerde uptime werkt men in het algemeen en ikke in het bijzonder met RAID-5. Nobody ever got fired for using RAID-5, zogezegd. Je kunt RAID-1 niet expanden, als er een disk sterft moet het hele ding plat, schijf recoveren na installatie nieuwe disk, en dan booten. Met een beetje beschaafd RAID controllertje aanboord kun je ene RAID-5 array tijdens uptime recoveren. Het hele ding wordt zo traag als dikke stront, maar je database blijft up.


RE Brothar:
Baan bouwt inderdaad 's een flink overpopulated database bij installatie. Ik meen dat er per administratie (er komen er om te beginnen vier) iets van 1500 tabellen gebruikt worden om te beginnen, en dat daar nog een setje tabellen bij komt voor ons maatwerk (sowieso al 900 stuks, zonder het nog te bouwen stukje). 1500+900 x 4 = 9600 user tables.
Dit spul wordt niet heel erg I/O dependent, dat is dan ook de reden dat de logfiles (overigens samen met het OS) op een losse 15K disk of RAID-0 gaan komen. In de tables zelf maakt het niet zoveel uit of het ding alles in één tabel duwt of alles in aparte tabellen. De praktijk heeft al uitgewezen dat de datamining kit die we geschreven hebben het met onze NL database (die is wat groter dan deze nieuwe, nu 18 administraties, met bij elkaar een goeie 4 miljoen klantjes) er aan te pas moet komen om de NL server met 1x 10k losse disk en 1x RAID-5 van 3 10k disks vol te belasten. Het is me dus voornamelijk te doen om de processoren.

RE Zwelgje:
I never got fired for doing anything
Maar, ik weet dat de Xeon de veilige keuze is. Echter, ik heb de NL server nu draaien op Xeon² 2.2Ghz en de processorbelasting is met name tijdens boeiende acties (facturatie aan 50.000 klantjes ineens, even een contractverlenginkje doorboeken bij zo'n aantal, enzovoorts) de absolute bottleneck. Omdat we in België niet verwachten over vijf jaar al even groot te zijn als in Nederland hoeft er geen 4-way systeem naartoe. Maar dat wil niet zeggen dat ik dan maar gewoon de standaard dingen haal zonder dat ik eerst heel goed gekeken heb of het allemaal wel optimaal gaat werken.
Als het níét optimaal functioneert vind ik dat zonde, en natuurlijk m'n eer te na. Bovendien heben "Wij van de ICT afdeling" heel graag een systeem draaien waarvoor ik niet elke week naar Hoeghaarden hoef te racen. Tegenover de brouwerij zitten werken in een heet stoffig gebouw is toch wel een beetje erg hard voor mijn tere kinderzieltje.

[ Voor 7% gewijzigd door Verwijderd op 01-09-2004 07:11 ]

[Equator]

Volgens mij worden alle aanpassingen aan een MSSQL database weggescreven in je transaction log's. Pas wanneer de server dit wil, wordt dit naar de database zelf geflushed.
De database files hoeven dus niet op een hele snelle disk/raidset.

De transactionlog's het liefst op een aparte disk. (Zo snel mogelijk dus geen RAID5 of MIRROR.)
Een RAID10 kan, maar kost veel centen.

Koffie schreef:Het enige wat bij mij op een hardware mirror komt, is het OS zelf.

Mee eens

Smiley schreef:Ik adviseer mijn klanten altijd 3 x raid 1 ( 1 set OS, 1 set DB en 1 set logfile)

Het nadeel van een RAID1 (MIRRORSET) is dat je deze niet uit kan breiden. Stel dat je database enorm gaat groeien, kan je bij een RAID5/RAID-ADG nog disken bijplaatsen om zo je array te vergroten.

Ik zelf zou kiezen voor MIRRORSET voor OS,
RAID5/RAID-ADG voor DATA
single disk voor LOG's Eventueel zou je hier ook voor een RAID0 of een RAID10 kunnen kiezen. Maar ik ben geen fan van RAID0 in een prod. server, en RAID10 is meestal te duur.(Minimaal 4 disken. Probeer je klant maar eens te overtuigen.;) )
Als je je LOG's toch reddundantie wilt geven kies ik denk ik toch voor een MIRRORSET.

KnetterGek schreef:Nobody ever got fired for using RAID-5, zogezegd. Je kunt RAID-1 niet expanden, als er een disk sterft moet het hele ding plat, schijf recoveren na installatie nieuwe disk, en dan booten. Met een beetje beschaafd RAID controllertje aanboord kun je ene RAID-5 array tijdens uptime recoveren. Het hele ding wordt zo traag als dikke stront, maar je database blijft up.

2 Zielen 1 gedachte.
Echter: Ook een RAID1 set draait door bij een crash van een disk. En bij hotswappable disken kan je (Sterker nog MOET je) de kapotte disk gewoon vervangen door een nieuwe.
Een RAID5 wordt inderdaad trager bij verlies van 1 disk, omdat hij de data van de verloren disk online moet rebuilden. (RAID ADG is dan en oplossing)
Een MIRRORSET wordt niet trager bij verlies van 1 disk.

[ Voor 27% gewijzigd door Equator op 01-09-2004 07:29 ]

[Jazzy]

Wat adviseert je hardwarelevarancier? Dat advies zou ik zwaar laten meewegen als ik jou was.

Zelf ben ik klant bij HP en in de range waarin ik koop (DL360 tot ML370) worden geen Opterons aangeboden, dat betekent dat mijn servers een Xeon processor hebben. Maar mocht je een server in de klasse van de DL580 overwegen dan is het wel interessant om eens naar een DL585 te kijken. Wie weet ga je hem over een jaar of 2, 3 toch nog 64-bits inzetten. HP kan je prima adviseren wat het beste presteert onder MS SQL Server.

Leuk topic trouwens, zelf moet ik beslissen of we Baan IV op AIX blijven draaien of naar Windows 2000 Server gaan halen. Ik overweeg die laatste optie trouwens.

O ja, mirror die losse disk. Je logfiles op een enkele disk is een geweldig single point of failure. Schijven gaan stuk.

[ Voor 9% gewijzigd door Jazzy op 01-09-2004 07:29 ]

[Jazzy]

CyberJ schreef op 01 september 2004 @ 07:24:
Het nadeel van een RAID1 (MIRRORSET) is dat je deze niet uit kan breiden.

Nee hoor, je kunt die met een fatsoenlijke controller gewoon uitbreiden. Wel met 2 schijven teglijk natuurlijk.

[Verwijderd]

Er zijn een aantal reviews, niet veel helaas, te vinden over SQL Server performance tussen de Xeon's en de Opteron's:

http://www.aceshardware.com/read.jsp?id=55000260
http://www.anandtech.com/...s/showdoc.aspx?i=1816&p=4

In de PC Magazine van juni 2003 stond ook een review hiervan. Kan deze op internet niet echt vinden, dus hierbij:

Configuratie	Select query	Select + Order By	Select + Order By + Or
Dual Xeon 2.8 HT off	15,1s	11,4s	11s
Dual Xeon 2.8 HT on	10,8s	11,8s	12,2s
Dual Opteron 1.8	15,9s	12,9s	11,5s

[Gé Brander]

Is de opteron met de bus naar het geheugen toe niet sneller dan de intel? Of hangt dat helemaal van de gebruikte chipset af op het intel/opteron bord en is daar geen verschil in?

[Abom]

Wij hebben Baan IV op HPUX draaien, dus over de CPU kan ik niet zoveel vertellen, maar ik zou persoonlijk voor XEON's gaan (hoewel ik een AMD fan ben ).

Wij hebben een aantal jaren geleden de database (informix) op RAID5 gehad, dit heeft gigantische performance problemen met zich meegenomen.
Maar aangezien het om een hele kleine groep medewerkers gaat, waar jij de machine wil plaatsen, denk ik niet dat het een probleem zal zijn.

[P_de_B]

O ja, mirror die losse disk. Je logfiles op een enkele disk is een geweldig single point of failure. Schijven gaan stuk.

Ik ben dus niet de enige die het vreemd vind dat hier niet voor gekozen is. Ik zou toch die logdisk mirorren.

[MoBi]

Koffie schreef op 31 augustus 2004 @ 23:26:
Euh , MoBi;
Ik denk dat je RAID-2 bedoeld, RAID-1 is disk mirroring, daar worden je arrays echt niet sneller van.
Verder zou ik nooit, maar dan ook nooit een productie DB op iets anders dan RAID-5 plaatsen
Het enige wat bij mij op een hardware mirror komt, is het OS zelf.

Ik bedoel dus echt wel raid 1. Ik weet niet wat voor raid controller erin komt, maar raid 1 is dus echt wel sneller als raid 5. Kost alleen iets meer diskspace.

[Ooyevaar]

Ik lees een heleboel posts over raid-dit en raid-dat, maar wat mij altijd verteld is over databases (en speciaal over Oracle) is dat er zoveel mogelijk spindels moeten zijn. En voor redundantie dan maar gemirrord.
Dus een mirror-set (al dan niet met stripe) voor OS, swap, progs, roll-back, tmp, en data. Dus minstens 12 schijven (?). Ons BaaN-systeem draait er perfect op. Welliswaar een Sun/solaris maar toch.

Wat betreft de processor moet je je echt afvragen wat voor besturingssysteem er op draait. Ga je voor Linux of Windows64 dan kan je het beste Opteron nemen. Die zijn echt sneller voor dezelfde prijs. Draai je gewoon w2003 dan maakt het echt geen moer uit.

En trouwens ... wat bepaalt nu echt de totaalprijs van een server ? raidcontroller en de noodzaak voor veel schijven !

Dus in volgorde van snelheidsbeinvloeders : de juiste raidcontroller, hoeveelheid schijven (stripe EN mirror), veel geheugen en dan pas processoren.

Succes met de keuze !

[Abom]

MoBi schreef op 01 september 2004 @ 08:36:
[...]


Ik bedoel dus echt wel raid 1. Ik weet niet wat voor raid controller erin komt, maar raid 1 is dus echt wel sneller als raid 5. Kost alleen iets meer diskspace.

We raken een beetje off-topic, maar RAID1 is helemaal niet sneller dan RAID5 (wanneer je een normale RAID controller gebruikt).

RAID1 kan vanaf elke mirror lezen, maar schrijven kan alleen op de snelheid van een enkele disk.

[Ooyevaar]

Abom schreef op 01 september 2004 @ 08:57:
[...]
RAID1 kan vanaf elke mirror lezen, maar schrijven kan alleen op de snelheid van een enkele disk.

Gelukkig hebben we het hier over een ERP-pakket die het meeste van de tijd databases doorzioekt om gegevens te presenteren. Schrijven gebeurd maar weinig of in nachtelijke jobs. Mirror is dus geen probleem maar juist een aanrader !

[Abom]

Ooyevaar schreef op 01 september 2004 @ 09:02:
[...]


Gelukkig hebben we het hier over een ERP-pakket die het meeste van de tijd databases doorzioekt om gegevens te presenteren. Schrijven gebeurd maar weinig of in nachtelijke jobs. Mirror is dus geen probleem maar juist een aanrader !

Ik had het niet over de situatie met een ERP pakket.

Wat ik aanraad is een striped mirror (RAID 1+0 dus).

[ Voor 13% gewijzigd door Abom op 01-09-2004 09:10 ]

[Arfman]

Verwijderd schreef op 01 september 2004 @ 07:09:
[...]
Je praat niet over de boekhouding van een bedrijfje van 30 man... dat zou ik ook wel op losse disks willen doen. Maar bij gegarandeerde uptime werkt men in het algemeen en ikke in het bijzonder met RAID-5. Nobody ever got fired for using RAID-5, zogezegd. Je kunt RAID-1 niet expanden, als er een disk sterft moet het hele ding plat, schijf recoveren na installatie nieuwe disk, en dan booten. Met een beetje beschaafd RAID controllertje aanboord kun je ene RAID-5 array tijdens uptime recoveren. Het hele ding wordt zo traag als dikke stront, maar je database blijft up.

Zeker nog nooit met de wat nieuwere HP servers gewerkt ?
Die bouwen hun RAIDset gewoon weer op, hardwarematig via de controller, terwijl het OS draait. Geen last van .

[Verwijderd]

Arfman schreef op 01 september 2004 @ 10:01:
Zeker nog nooit met de wat nieuwere HP servers gewerkt ?

Dat klopt, ik heb ervaring met Compaqs en kloontjes. Met name de Proliants die we bij mijn vorige werkgever gebruikten hadden de onhandige neiging voor een RAID-5 diskswap gewoon up te kunnen blijven maar met het swappen van deen mirrorred disk moest het spul down. Don't ask me why, ik beheerde daar alleen werkplekken, switches en routers.

Ooyevaar schreef op 01 september 2004 @ 09:02:
Gelukkig hebben we het hier over een ERP-pakket die het meeste van de tijd databases doorzioekt om gegevens te presenteren. Schrijven gebeurd maar weinig of in nachtelijke jobs. Mirror is dus geen probleem maar juist een aanrader !

Onze klantenadministratie stuurt elke dag honderden mensen facturen, elke dag komen er tig klanten bij en wekelijks mutaties worden er mutaties op de klantendatabase uitgevoerd voor controle en datamining. Een klant factureren bewerkt 19 tabellen. Een dealer factureren, 30+ tabellen. Een keten factureren, voor de vuist weg 10 tabellen per filiaal (gemiddeld!). Dit zijn UPDATE queries.
Wij schrijven overdag ook wel eens in de database dus...
Het rapporteren eruit, dát is een incidenteel gebeuren. Maar databases waar je de hele dag alleen maar in leest en die ja alleen sporadisch of 's avonds een keer beschrijft, die hebben wij hier in elk geval niet. Ik moet eerlijk zeggen dat ik ook maar één applicatie ken waarin het patroon wat jij beschrijft voorkomt, en dat is een leerlingen database op een scholengemeenschapje. Daar wordt echter de hele dag ook niet veel mee gedaan want de overgrote meerderheid van de klanten in die database blijft erin zonder wijzigingen, behalve aan het eind van het jaar wanneer de helft over gaat, een kwart blijft zitten en een kwart ophoepelt.

Jazzy schreef op 01 september 2004 @ 07:28:
Wat adviseert je hardwarelevarancier? Dat advies zou ik zwaar laten meewegen als ik jou was.

Wat weet een hardwareboer van deze Baan server, het doel, hoe Baan tekeer gaat in MSSQL, en wat voor plannen wij hebben? Ze weten bij TCP echt heel veel van computers maar dat maakt ze nog geen experts op software gebied, helaas. Ik neem zijn adviezen (en het assortiment) natuurlijk mee in de overweging, maar uiteindelijk is hij gewoon de winkel waar de spullekes vandaan komen, niet de adviesgroep Baan.

Men schreef in dit topic:
RAID, RAID, RAID, RAID, RAID, RAID, RAID, RAID, RAID, RAID, RAID, RAID, RAID

Maar, het ging over Opterons of Xeons. Het schijven gebeuren is al besloten, eigenlijk, want we weten vrij zeker dat we de bestaande (fijn werkende) configuratie van de NL server gewoon gaan kopieëren naar de Belgische. Met discussie over RAID, hoe leuk en leerzaam ook, komen we helaas nergens.

offtopic:
CyberJ: dat heb ik dus ook heel vaak bij jouw posts... ben jij mijn bij de geboorte kwijt gemaakte broertje?

[ Voor 12% gewijzigd door Verwijderd op 01-09-2004 11:56 ]

[JackBol]

even buiten technisch standpunt, je geeft al aan dat je baas Intel-fan is. Dan moet je zeker een xeon halen.

Haal je toch die opteron en gáát het mis, dan krijg jij het op je dak, omdat je hebt gekozen voor een opteron.
Heb je een xeon en het gaat mis, zal je baas eerder de xeon de schuld geven, omdat hij denkt dat het een goede proc is.

[Gé Brander]

Dirk-Jan schreef op 01 september 2004 @ 11:59:
even buiten technisch standpunt, je geeft al aan dat je baas Intel-fan is. Dan moet je zeker een xeon halen.

Haal je toch die opteron en gáát het mis, dan krijg jij het op je dak, omdat je hebt gekozen voor een opteron.
Heb je een xeon en het gaat mis, zal je baas eerder de xeon de schuld geven, omdat hij denkt dat het een goede proc is.

Inderdaad, daar zit wat in... Maar het verschil zal toch niet dusdanig groot (plusminus 10%) zijn dat je systeem onderuit knalt. Dan heb je in het begin al een niet zo een goede inschatting gemaakt. Als je inschatting al op 90% van de maximale load zit...

[Sosabowski]

Dirk-Jan schreef op 01 september 2004 @ 11:59:
Heb je een xeon en het gaat mis, zal je baas eerder de xeon de schuld geven, omdat hij denkt dat het een goede proc is.

Als het dan mis gaat ligt het natuurlijk aan TS niet aan de xeon

[SSH]

Je hebt je toch laten adviseren door Tweakers? De Opterons zijn nieuw, sneller en goedkoper aldus ons, zeg je tegen je baas. Als het fout gaat moet je gewoon ons de schuld geven

[Jazzy]

SSH schreef op 01 september 2004 @ 16:47:
Je hebt je toch laten adviseren door Tweakers? De Opterons zijn nieuw, sneller en goedkoper aldus ons, zeg je tegen je baas. Als het fout gaat moet je gewoon ons de schuld geven

Was het je ook opgevallen dat hij het vraagt in PNS? Overigens is de prijs van een DL580 en een DL585 ongeveer gelijk, de laatste is iets duurder.

[sebastius]

SSH schreef op 01 september 2004 @ 16:47:
Je hebt je toch laten adviseren door Tweakers? De Opterons zijn nieuw, sneller en goedkoper aldus ons, zeg je tegen je baas. Als het fout gaat moet je gewoon ons de schuld geven

Ja en draag jij dan ook verantwoording voor de schade die dan geleden wordt? Zo'n servertje kost een paar knaken, en dan nog de software er op inrichten...

[Femme]

Ik kan zo snel geen goede MS SQL benchmarks van de Xeon en Opteron bedenken. De benchmarks van AnandTech lijken nogal beperkt te worden door I/O en eenkele zware SELECT query zoals in de benchmarks van Ace's Hardware lijkt me niet echt representatief voor de performance van een Baan database-server die veel queries tegelijkertijd gaat doen.

Het algemene beeld is wel dat de Opteron veel beter presteert in servertoepassingen dan de Xeon (zie bijv. dit artikel). Dat is niet vreemd omdat de Opteron-architectuur zich veel beter leent voor servertoepassingen en multi-processor configuraties. Je zou verwachten dat het snelheidsvoordeel van de Opteron ook in MS SQL tot uiting komt. Het prijsverschil tussen een dual Xeon en dual Opteron zal niet groot zijn. Bij 4-way configuraties worden Opterons wel stukken goedkoper.

Over de stabiliteit van de Opteron zou ik me geen zorgen maken, zeker niet als het bak van HP wordt. Onze eigen dual Opterons draaien prima (147 versus 97 dagen uptime) en presteren erg goed in vergelijking met de dual Athlon MP's die eerst werden gebruikt.

Wat betreft de RAID 5-discussie: ik kan me wel voorstellen dat mensen die Adaptec-rommel gebruiken of met low-end HP Smart Array's (zonder write-back cache en BBU) hebben gewerkt slechte ervaringen hebben met RAID 5. Moderne controllers hebben er veel minder moeite mee. Een LSI MegaRAID SCSI 320-2X / Intel SRCU42X is bijna net zo snel in RAID 5 als in RAID 10. Het hangt dus nogal af van de controller.

[Zwelgje]

SSH schreef op 01 september 2004 @ 16:47:
Je hebt je toch laten adviseren door Tweakers? De Opterons zijn nieuw, sneller en goedkoper aldus ons, zeg je tegen je baas. Als het fout gaat moet je gewoon ons de schuld geven

wat ga je dan zeggen :

'ja eh, volgens 'captain iglo' en 'ssh' van tweakers was dit de goed keuze'



denk dat je baas dat niet echt gaat pikken

[JackBol]

aan de ondertitels te zien hebben zwelgje en femme toch allebei een andere mening...

[Verwijderd]

Femme schreef op 01 september 2004 @ 17:48:
Het algemene beeld is wel dat de Opteron veel beter presteert in servertoepassingen dan de Xeon

Klopt voor veel serverprodukten. Vooral serverproducten als Apache zullen sneller werken op een Opteron. Echter SQL Server is *erg* sterk geoptimaliseerd voor Intel CPU's (snelheid is belangrijk in een dbms en Microsoft heeft er alles aan gedaan om met de ontwikkeling van SQL Server ervoor te zorgen dat deze geoptimaliseerd is voor Intel (Xeon) cpu's) . Pas bij de komende 64bit versies van SQL Server zal Microsoft optimalisaties gaan toepassen voor de Opteron. Aangezien SQL Server in zijn huidige vorm en de Xeon al enige tijd bestaan zal het lastig voor de Opteron zijn deze te "outperformen".

Kijk eens wat Microsoft over HTT zegt: http://www.microsoft.com/sql/howtobuy/SQLonHTT.doc

Blabla verhaal van Intel over Xeon's voor SQL Server:
http://h71028.www7.hp.com...wnloads/16287_Xeon_r5.pdf

Maar goed, effe gezocht en verder nergens een goede review kunnen vinden. Wel een hoop SAP performance reviews. Vraag daarbij is natuurlijk hoe deze verhouden tot "echte" database performance reviews.

[Ooyevaar]

Verwijderd schreef op 01 september 2004 @ 11:46:
Onze klantenadministratie stuurt elke dag honderden mensen facturen, elke dag komen er tig klanten bij en wekelijks mutaties worden er mutaties op de klantendatabase uitgevoerd voor controle en datamining. Een klant factureren bewerkt 19 tabellen. Een dealer factureren, 30+ tabellen. Een keten factureren, voor de vuist weg 10 tabellen per filiaal (gemiddeld!). Dit zijn UPDATE queries.
Wij schrijven overdag ook wel eens in de database dus...
Het rapporteren eruit, dát is een incidenteel gebeuren. Maar databases waar je de hele dag alleen maar in leest en die ja alleen sporadisch of 's avonds een keer beschrijft, die hebben wij hier in elk geval niet....

Je heb vast wel gelijk dat je veel in de database schrijft. maar ik ben waarschijnlijk net zo op de hoogte van hoe de BaaN-database-structuur in elkaar zit als jij. En dat houdt in dat voor een eenvoudig invoerschermpje er al tientallen andere tabellen gevraagd is om defaultwaarden en keuzelijstjes te leveren. Veel geheugen en leessnelheid is dan een must.
Met het toevoegen/wijzigen van een aantal regels zijn er relatief veel meer records gelezen (inclusief alle controleslagen die BaaN over jouw ingevoerde gegevens doet).

Enne Abom ... ik had je eerdere post niet goed gelezen sorry.

[Arfman]

Verwijderd schreef op 01 september 2004 @ 11:46:
Maar, het ging over Opterons of Xeons. Het schijven gebeuren is al besloten, eigenlijk, want we weten vrij zeker dat we de bestaande (fijn werkende) configuratie van de NL server gewoon gaan kopieëren naar de Belgische. Met discussie over RAID, hoe leuk en leerzaam ook, komen we helaas nergens.

We zitten hier in PNS. Daar posten allerlei mensen die nogal graag advies geven over het e.e.a.
Wel het budget hebben voor een vette Xeon, om er vervolgens een dikke vette SPOF in te bouwen wil dan nog wel eens raar vallen. Zet er alsjeblieft voor die paar extra knaken een RAID 1 config bij in.

[Verwijderd]

OK, dan. Om de discussie over disks nu echt kop-voor de grond in te duwen:
Ik, zijnde de poster van dit postje, beloof plechtig zonder m'n vingers achter me gekruisd te houden, dat ik een extra diskje voor het OS zal gebruiken om een mirrortje te runnen, op dit mirrortje komen ook de logs.
OK?

OK dan!

Ik heb deze discussie en de documentjes aan m'n baasje gegeven, met wat onderbouwing. Het 64bit stukje vind hij wel heel spannend: hij wil in 2006 in Nederland op 64bit draaien, mits Baan dat handlen kan.
Of het wat gaat worden met Opterons ipv Xeons...
I dunno.

[Jazzy]

Succes, laat maar eens horen. Overigens verwacht ik van jou wel die eerste goede review.

[Verwijderd]

Verwijderd schreef op 02 september 2004 @ 09:26:
OK, dan. Om de discussie over disks nu echt kop-voor de grond in te duwen:
Ik, zijnde de poster van dit postje, beloof plechtig zonder m'n vingers achter me gekruisd te houden, dat ik een extra diskje voor het OS zal gebruiken om een mirrortje te runnen, op dit mirrortje komen ook de logs.
OK?

OK dan!

Ik heb deze discussie en de documentjes aan m'n baasje gegeven, met wat onderbouwing. Het 64bit stukje vind hij wel heel spannend: hij wil in 2006 in Nederland op 64bit draaien, mits Baan dat handlen kan.
Of het wat gaat worden met Opterons ipv Xeons...
I dunno.

Het leuke van een Opteron is dat tie NUMA kan draaien met een 64bit OS, misschien dat dat ook nog scheelt in de toekomst. Plus dat MS MSSQL ook nog gaat optimaliseren voor de Opteron, kan ook nog interessant zijn.

Maarja dat zijn dingen voor de toekomst, je wilt nú een systeem wat goed draait

[Verwijderd]

er speelt iets heel anders: als de volgende NL bak er kotm wordt ie vermoedleijk quad CPU... dat worden dus sowieso geen Xeons als die dan nog altijd met z'n allen één memorybus moeten gebruiken.
Maar idd, dat duurt og een jaar of twee, met een beetje geluk zijn we dan van dat brakke Baan af en gebruiken we een échte database, Access ofzo.

edit:
Als m'n baas dit leest gaat ie flippen

[sanfranjake]

Verwijderd schreef op 02 september 2004 @ 22:44:
er speelt iets heel anders: als de volgende NL bak er kotm wordt ie vermoedleijk quad CPU... dat worden dus sowieso geen Xeons als die dan nog altijd met z'n allen één memorybus moeten gebruiken.
Maar idd, dat duurt og een jaar of twee, met een beetje geluk zijn we dan van dat brakke Baan af en gebruiken we een échte database, Access ofzo.

edit:
Als m'n baas dit leest gaat ie flippen

Van Baan overstappen op een Access database MS Access is niet bedoeld voor db's op de schaal waar je over het algemeen met Baan op werkt ....

[Zwelgje]

sanfranjake schreef op 04 september 2004 @ 11:11:
[...]

Van Baan overstappen op een Access database MS Access is niet bedoeld voor db's op de schaal waar je over het algemeen met Baan op werkt ....

denk dat ie dat niet serieus bedoelt

toch

[Verwijderd]

zwelgje schreef op 04 september 2004 @ 13:42:
[...]


denk dat ie dat niet serieus bedoelt

toch

Ik mag het hopen, maar gezien de toonzetting denk ik het wel

Overweeg anders gelijk even SQLite ofzo

[ Voor 9% gewijzigd door Verwijderd op 04-09-2004 13:45 ]

[Verwijderd]

Eh, ja, hoor. Ik ga serieus overwegen een Access beestje te bouwen. Uhhuh.
Lees het topic eens goed. Er komt iemand dit thread lezen, en die gaat flippen als hij dat las. Leuk dat jij ook flipt maar m'n chef ging al een beetje schuimbekken dus het was niet meer nodig.

[Verwijderd]

Maar dicht enzo