Best CPU for MS-SQL

jeancwb

n00b
Joined
Mar 26, 2008
Messages
1
Hi!
I have two Servers and I need to run Ms Sql.
What´s the best choice to run a database?
a) Dell - 4 x XEON MP 3.16GHz - 1Mb Cache L2
b) IBM - 2 x Xeon QuadCore E5320 1.6 GHz 8Mb Cache L2

That´s it !
 
uh.. it really depends on more than just this... but i would go w/ option 2 based on the limited information..
 
You want IBM. Period.
IBM's the only one with X4, which really is that much better than the stock Intel crap. Secondly, the Dell is a powersucking memory bottlenecked smoking (as in on fire) pile of crap.
However, get your pocketbook open and get at least 2.33GHz.
 
MySQL's bottleneck is usually Disk I/O.

Make sure you get a good disk sub system with a good NIC (and good drivers).
 
better way is to run only os in raid raid1
but the datas of db, indexes to run in raid 10 and raid 5
external storage ibm ds4xxx is good solution but shut be careful with the model of limitations of LUN's
for better r/w

RAM?
 
i think the IBM will be better choice b) IBM - 2 x Xeon QuadCore E5320 1.6 GHz 8Mb Cache L2
 
thats a little under-par as far as DB specs go. For our transactional DB we recommend:

Main Processor: Quad Core Intel Xeon X7350, 8MB Cache 2.93 GHz, 1066 MHz FSB or faster
3 Additional Processors: Quad Core Intel Xeon X7350, 8MB Cache 2.93 GHz, 1066 MHz FSB or faster
 
thats a little under-par as far as DB specs go. For our transactional DB we recommend:

Main Processor: Quad Core Intel Xeon X7350, 8MB Cache 2.93 GHz, 1066 MHz FSB or faster
3 Additional Processors: Quad Core Intel Xeon X7350, 8MB Cache 2.93 GHz, 1066 MHz FSB or faster

I don't even want to see the design of that database. I seriously don't.

I could nearly run PeopleSoft for 500+ users on that config.
 
Well to answer the question posed in the title, I'd have to say Itanuim. But since you don't have one of those, I'd have to say you need to figure in the ram, disk space/acess speeds, and bandwidth as well instead of just basing the desicion off of proc type.

 
Ram and disk i/o would be the deciding factor between them.

I run some huge DB's(2x 750GB) for clients on hardware smaller than both of those and rarely is the cpu the limiting factor.
When it is 99 times out of 100 its a bad query that needs to be redone in a more efficient manner.
 
the answer is realy tied to your database size, the types of queries that are typical, amount of transactions, type of connection to the database for the majority of people hitting it (i.e. lan, wan, internet) etc...

for example if it's a database for a 200-500 person office mostly lan based with small data transactions, and a small database size you'd be best served by the most power efficient machine with the best backup option for on the fly backup such as 2 cheaper low power cpu server boxes running in a redundant cluster.

for 500+ on a lan, lots of transactions, several tables covering different querys, large database size; go with lots of ram, fast disk i/o, dual quad cpu, segmented lan access by dept/floor w/ seperate nics to handle traffic from each.

what is better totally depends on your existing setup and needs. maybe the database isn't the most critical thing to worry about and you need the bigger server for something else more mission critical.
 
MySQL's bottleneck is usually Disk I/O.

Make sure you get a good disk sub system with a good NIC (and good drivers).

He isn't using MySQL, its MS-SQL, Microsoft. Either way, DB queries do not require a quadcore. The MySQL server for my department is a Dell Celeron 700 with 256 ram and a 30 gig hard drive running Arch Linux. Nay an issue. Select statements just aren't that taxing unless you have like a TB database to plow through.
 
If you have to use per-CPU licensing, then your costs will be much much less going with the quad core option.
 
If you have to use per-CPU licensing, then your costs will be much much less going with the quad core option.
licensing is per cal not cpu, unless your talking enterprise version vs. standard inital cost.

what is most important is assesing your needs and available resources and targeting what goes where based on that.

he may be fine with a domain controller w/ sql running on it on a single quad and the second box as a backup server. he may need both boxes for the database load.

it all depends on what he's got load wise as to what the better box is going to be for him to use.
 
and if you'd read a bit further or investigate a bit more that processor license is per workload not socket, and it makes no sense at all to go that way as it ends up being far more expensive than cal licenses per user.

there is a loophole in the per person cal that allows you to buy your cals for the expected maximum workload at any given time if it's for anonymous web based traffic. for example your maximum expected locked records is 500 at any given moment, you only buy 600 cals to have some leeway.

the per processor cal is always maximum ability for sql to process transactions on moderate enterprise level hardware per core (it's based on threaded workload, not processor socket). it's priced so that you need to spend higher margin on hardware to gain against the processor cal vs. the user cal method so you lose not gain in the long run.


also i used to work for the big redmond machine, the per processor license is only there for enterprise customers using volume licensing, and special cases like a few partners etc... to qualify for it in the first place requires a hoop dance on the part of your reseller or existing enterprise agreements with xxx amounts of sql cals already purchased. it is basically only in place for orginizations to use "true up" to purchase overkill licensing ahead of time and at the end of the agreement ot get a refund based on what they didn't use in their envirornment. as volume licensing is all about the more you buy the cheaper the products get in the agreement, so enterprises buy a lot at the right moment to record a loss and get the refund at the right time when they need a gain.
 
and if you'd read a bit further or investigate a bit more that processor license is per workload not socket, and it makes no sense at all to go that way as it ends up being far more expensive than cal licenses per user.

It's per physical socket, not per core, and certainly not some bizzare number or threads/utilization or whatever.

Here's what Microsoft says-

"Multicore processors, which consist of multiple processing execution units or “cores” on one chip, are seen as a promising way to boost computing power. Microsoft has been driving thought leadership in this area by charging the same amount per processor, regardless of how many cores are in the processor"

Seems pretty clear to me.

there is a loophole in the per person cal that allows you to buy your cals for the expected maximum workload at any given time if it's for anonymous web based traffic. for example your maximum expected locked records is 500 at any given moment, you only buy 600 cals to have some leeway.

Thank god I can select records without causing locks- you just saved me a ton of money in CALs

SELECT * FROM SOMETABLE WITH (NOLOCK)

...or not. Since that's not how the licensing works.

the per processor cal is always maximum ability for sql to process transactions on moderate enterprise level hardware per core (it's based on threaded workload, not processor socket). it's priced so that you need to spend higher margin on hardware to gain against the processor cal vs. the user cal method so you lose not gain in the long run.

That's funny. Hilarious even. Even under the open business license, a SINGLE user CAL runs about $150... now multiply that by your 600 number. So besides being LESS cost effective than buying a CPU license, you still wouldn't be in compliance with your licensing requirements. Microsoft is pretty clear about the ability to transfer CALs between users and what a "user" is (and it's not some anonymous web user)- this is from their FAQ section. No digging required.

"A device CAL allows any number of users to gain access to licensed server software from a particular device. A user CAL lets a particular user gain access to licensed server software from any number of devices. In other words, a user CAL covers a particular user's access to the server software from work computers and laptops, as well as from home computers, handheld computers, Internet kiosks, and other devices. A device CAL covers access by multiple users to server software from a single, shared device."

Oh, and if you just went "ah ha!" about the device CAL thinking that perhaps your firewall using NAT runs everyone thourgh a single device.... read up about multiplexing.

also i used to work for the big redmond machine

The garbage man technically works for microsoft, but that doesn't make him qualified to dispense licensing advice.


the per processor license is only there for enterprise customers using volume licensing, and special cases like a few partners etc... to qualify for it in the first place requires a hoop dance on the part of your reseller or existing enterprise agreements with xxx amounts of sql cals already purchased. it is basically only in place for orginizations to use "true up" to purchase overkill licensing ahead of time and at the end of the agreement ot get a refund based on what they didn't use in their envirornment. as volume licensing is all about the more you buy the cheaper the products get in the agreement, so enterprises buy a lot at the right moment to record a loss and get the refund at the right time when they need a gain.

Nope. No special arrangement is needed with Microsoft for processor licensing. Just cash.

Here, i'll even give you a link to buy one-

http://www.newegg.com/Product/Product.aspx?Item=N82E16832102538

Not a big deal.

Remember- advice you receive over the internet is only worth what you paid for it.
 
there is a loophole in the per person cal that allows you to buy your cals for the expected maximum workload at any given time if it's for anonymous web based traffic. for example your maximum expected locked records is 500 at any given moment, you only buy 600 cals to have some leeway.

BLOODY HELL klergy!!!! Please don't tell me you work in IT buying software. Have you ever checked the price of your little 'trick'? I couldn't believe you contemplated buying 600 CALs so I had a look myself. A pack of 10 CALs for sql server works out about £2k so times that by 60 and you get £120,000! Kind of steep when 4 sockets will run around £10k

If you want a nice rule of thumb: If you expect less than 25 users to access the server, go with CAL's, if it is more than get sockets of devices.
 
wow coupla thoughts and then i'm done trying to convince you guys that you're being stupid...
first off...
never meant to infer the licensing per processor isn't based per socket, was saying PRICING was based per workload, damn editing i did took out the distinction sorry about that. was trying to say that the per processor license is priced to be more expensive based on a dual core at 2.4 Ghz workload than the per person licensing mode. that's what the second part of the sentence was trying to infer but upon reading it agin it's a bit hazy so i'll clarify.

secondly,
if you are using lookups on a webserver with anymous access and not locking the record during an edit you are looking at a disaster. for a straight web server serving static content it's fine, for a forum it will cause lockups. and especially where sql server is really used, on a transaction processing basis it's a sure fire way to have dropped orders. nobody in their right mind uses sql server on a web site unless they have to tie in to a backend database that is also based on sql server, they just use my sql for it's free aspect, and plethora of web based toolsets. sql server is for the backend and most especially for transaction processing. and the licensing isn't based on locks, i was trying to point out that you can purchase cals based on a per simultaneous workload to use on a web server, and just used a record lock as an example, it can be for simultaneous read and write access or whatever else you wanna use. basically it just needs to have enough cals to cover any expected peak usage at any given time to avoid having the database reject the front end server's requests.

the microsoft article you linked to also doesn't override the licensing inside the sql processor cal. it specifically states you need to have a processor license for each instance of a virtual sql server you're running. that equates to some hefty pricing for a virtualized environment as most vm products only allow 2 virt processors per machine. so your dual quad core ends up under a virt machine envirornment costing 4x to run on those cores.

and you linked a retail copy of sql server standard that also includes 1 processor license, aka it will run on one processor. the processor cal is seperate and available only through volume licensing, not in a retail box.


and lastly...
if you are paying 200 per cal you are being ripped off. 2k per 10 pack is a bit high... on the order of 4x too high. you can get cals for 50 a pop. under a vl agreement you can get them for as low as 25 depending on the agreement and the amount purchased undet the agreement in total. granted for pricing that low you'd need to be a non-profit with greater than 1000 purchased products, but that isn't that rare to find for a large non-profit like the united way or salvation army etc... average is around 40 a pop for a vl agreement for a decent sized enterprise.
 
It's per physical socket, not per core, and certainly not some bizzare number or threads/utilization or whatever.

Here's what Microsoft says-

That's funny. Hilarious even. Even under the open business license, a SINGLE user CAL runs about $150... now multiply that by your 600 number. So besides being LESS cost effective than buying a CPU license, you still wouldn't be in compliance with your licensing requirements. Microsoft is pretty clear about the ability to transfer CALs between users and what a "user" is (and it's not some anonymous web user)- this is from their FAQ section. No digging required.

"A device CAL allows any number of users to gain access to licensed server software from a particular device. A user CAL lets a particular user gain access to licensed server software from any number of devices. In other words, a user CAL covers a particular user's access to the server software from work computers and laptops, as well as from home computers, handheld computers, Internet kiosks, and other devices. A device CAL covers access by multiple users to server software from a single, shared device."

Oh, and if you just went "ah ha!" about the device CAL thinking that perhaps your firewall using NAT runs everyone thourgh a single device.... read up about multiplexing.

The garbage man technically works for microsoft, but that doesn't make him qualified to dispense licensing advice.

Remember- advice you receive over the internet is only worth what you paid for it.

and on these fine points...

under an open agreement you get charged whatever your reseller thinks he can get away with charging you. there is no set price other than what you and your reseller agree to above the minimum (which i can't tell exactly what that is due to nda but... it's somehwere above $55 for an open agreement). you can seriously find them in retail box for less than an open agreement sometimes. enterprise agreements are completely a different beast, and are carefully watched by microsoft district reps to ensure they don't get too out of hand. there are a few large resellers that have had their enterprise agreement abilities revoked for charging too much when the enterprise in question calls microsoft to ask why they got screwed and the district rep then had to go back and do all kinds of refunds and future discounts because of it.

and yes you haul garbage for your company and are reading up on sql that's nice, nolock still chuckling about that.

and as to the licensing per person cal issue...
try it, call microsoft, and ask them if you can do it. you'll probably be shocked by the answer when it comes back yes, as long as it's for anonymous access and you don't have a bastion in place to serve as an anonimizer to hide the concurrent amounts of transactions. the licensing cal requirements for web servers is totally under it's own section and isn't governed by the regular cal license section. microsoft won't say it on the website as it means a loss of sales if they advertise the fact, but will let you know if you call them on it.

by the way, i used to have to deal with enterprise and open agreement discrepancies when i worked for the company. it wasn't my main job but i ended up having to do it anyway to process my real job at times.
 
Keep an eye on socket based licensing. With the looming 8-16 core CPUs this could turn into a very interesting time. Certain vendors have already instituted a per core licensing structure.

Depending on how each vendor handles the technology this could sway platform decisions enterprise wide.
 
http://www.newegg.com/Product/Produc...82E16832102538
Microsoft is getting more and more money.......lol............:D

IBM and Oracle charge per core, not per socket....

And volume license resellers do not try to rip you off. In fact, they compete to try to get your business.


And LOL@$25 SQL Standard CALs

under a vl agreement you can get them for as low as 25 depending on the agreement and the amount purchased undet the agreement in total.


And no, licensing is not based on workload or concurrent locks.
 
also i used to work for the big redmond machine, the per processor license is only there for enterprise customers using volume licensing, and special cases like a few partners etc...
SQL Server licensing simply doesn't work the way you're describing. It turns out that per-socket licenses are available to anyone who wants to buy one, and that SQL Server licensing has nothing to do with record lock counts.

As such, I'm curious to learn: in which group did you work, and who did you report to?
 
IBM and Oracle charge per core, not per socket....

This is wrong.

Oracle's "per socket, hooray dual cores" crap lasted about a year, if that, for those who are curious. (They made a big deal about it when the first dual-cores were introduced.) List for Oracle 10g Enterprise is $40,000 per core. Before you get into needed features and support agreements.

IBM charges based on Processor Value Units, or PVUs typically. Certain DB2 editions are per user, per application, or per connection.
On PVUs; A processor family is assigned a number of PVUs per core; this is to accommodate real hardware like iSeries, pSeries, POWER, etcetera, where you can allocate fractions of cores down to tenths. The average is 100 PVUs per core; POWER6 is 120 per core, Sun Niagra junk is 40 per core.
MSRP on DB2 Enterprise v9.5 is $175 per named user or $51.75 per PVU, or $5,175.00 per core per year; this includes all licenses and support agreements.
 
IBM and Oracle charge per core, not per socket....

This is wrong.

Oracle's "per socket, hooray dual cores" crap lasted about a year, if that, for those who are curious. (They made a big deal about it when the first dual-cores were introduced.) List for Oracle 10g Enterprise is $40,000 per core. Before you get into needed features and support agreements.

IBM charges based on Processor Value Units, or PVUs typically. Certain DB2 editions are per user, per application, or per connection.
On PVUs; A processor family is assigned a number of PVUs per core; this is to accommodate real hardware like iSeries, pSeries, POWER, etcetera, where you can allocate fractions of cores down to tenths. The average is 100 PVUs per core; POWER6 is 120 per core, Sun Niagra junk is 40 per core.
MSRP on DB2 Enterprise v9.5 is $175 per named user or $51.75 per PVU, or $5,175.00 per core per year; this includes all licenses and support agreements.


I don't understand - you said I was wrong and then you seem to confirm what I said is true by presenting some numbers - could you elaborate?
 
I don't understand - you said I was wrong and then you seem to confirm what I said is true by presenting some numbers - could you elaborate?

IBM does not charge per core. Read. Comprehend.
IBM charges by PVU or named user, period. It is not semantics. PVUs are not equal to cores; PVUs are PVUs. You buy as many as you need, which does NOT have to be 1:1 even for a single core. I have a 60 PVU DB2 instance on a p550; I could split this to two DB2 instances at .25 per LPAR or 3 at .1 per LPAR.

EDIT: Let's get into some advanced configurations here, just for the hell of it. Let's say I have an IBM POWER 550 with 8 CPUs. Because they're POWER6, that's 120 PVUs per total core, for a total of 960 PVUs. So I license one system for 960 PVUs. I'm finding that my problem isn't CPU, but disk bandwidth for some reason, so I buy another 550, but I only put 4 CPUs in this one. I reduce the LPAR on my first 550 to 4 CPUs, and now have two systems properly licensed.
But let's get really advanced. I'm DYING for bandwidth. So I have 960 PVUs already; need more systems. So I purchase another 40 PVUs for a total of 1000 PVUs. I then distribute these across 20 p510's with POWER5's, each with a single 2.1GHz core. I create an LPAR on each with .5 CPU (50%), and I'm appropriately licensed.

NOW, by comparison, if I were on Oracle, my first configuration of a single 550 is valid. So is my second, because I'm enforcing a hard cap. My third, is NOT. Even though I am limiting myself to half the CPU, under Oracle I need to license the entire physical core.

Forgot to throw up the Oracle numbers, but I don't have them handy, but per-named-user is still available there too.
 
Back
Top