Re: 2 x quad core or 4 x dual core? - server sizing
Rafa Griman <[email protected]> Tue, 11 Jan 2011 11:12:20 +0100
| Newsgroups | gmane.linux.suse.oracle.general |
|---|---|
| Message-ID | <[email protected]> |
Hi :) On Tue, Jan 11, 2011 at 10:56 AM, Martin Berg <[email protected]> wrote: > I've thought of this - but only one of my customers have tried this and it > did not perform as > expected (each core not being as fast as cores from the quad cores). > The performance was so bad that they scrapped the server. > I didn't have an opportunity to examine this (the problem might not have > anything to do > with the CPU's) - and I'm just being cautious. Could be a problem due to CPU-Memory bandwidth. The "problem" with having many cores is that the bandwidth per core decreases as you increase the number of cores per socket so apps that require a big CPU-memory bandwidth will be affected. Depending on the DB, you can hit this issue. In the cases in which you hit this issue, you can deactivate some cores at the BIOS. Usually helps. Another options is to pin certain processes to certain cores (cpusets, ...) leaving some other cores free for the OS and whatever it has to do (logs, network, ...). Summarizing: having many cores/sockets is not always good ;) Depends on your app, workflow, ... HTH Rafa > On 01/11/2011 10:17 AM, Zhu,Chao wrote: > > Why not go with 2*6core instead since server price will be pretty much saem > (just license will be diff), and gives you 50% capacity? > > On Tue, Jan 11, 2011 at 5:13 PM, gabi draghici <[email protected]> > wrote: >> >> In addition to what Martin said (although the second point alone would be >> enogh ;) ) don't forget the size of shared cache level 3 wich is bigger for >> the quads ! >> >> Best regards >> >> D. Gabriel >> >> On Tue, Jan 11, 2011 at 10:59 AM, Martin Berg <[email protected]> wrote: >>> >>> And good morning to you. >>> >>> I would go for the 2 quad core configuration for following reasons: >>> >>> - Capacity per core: >>> I may be wrong (and I don't have time to investigate now), but as far as >>> I remember the newer >>> Intel archectures (like the Nehalem) are not available in 2-core >>> versions. >>> The newer Intel CPU architectures are according to my experiences >>> significantly more efficient >>> per clock cycle than the older architectures (and I'm not talking about >>> 10%) when using Oracle. >>> This higher efficiency results in the highest capacity per core I've seen >>> - even with the lower >>> clock frequency. >>> Staying with 2-core processors would therefore leave you with the poorest >>> performance >>> per core. >>> >>> - Licensing >>> Using the 2 quad core configuration would allow you (assuming that there >>> are only 2 sockets in >>> the server) to use the Standard Edition One license at about 5k$ per >>> socket (or 10k$ in total) >>> Using the 4 dual core configuration would require the Standard Edition at >>> about 15k$ per socket >>> (or 60k$ in total) >>> The bean counters may like this :-) >>> >>> If you have a need for Enterprise Edition functionality this point is of >>> course irrelevant. >>> >>> >>> Best regards >>> >>> Martin Berg >>> >>> >>> On 01/11/2011 08:07 AM, Vladimir Barac wrote: >>> >>> Good morning, listers >>> >>> >>> >>> We are currently sizing servers for new Oracle / SLES project. HP >>> Proliant hardware is being considered. >>> >>> >>> >>> Could somebody explain, with as much details as possible, which one would >>> better option - server with 4 dual core Xeon CPUs or server with 2 quad core >>> Xeon CPUs? The rest of the setup - memory, storage OS version - are same for >>> both options. >>> >>> >>> >>> Servers would be primarily used for OLT Oracle workload (SAP database). >>> Few hundred concurrent users at peak time. >>> >>> >>> >>> Regards, >>> >>> Vladimir Barac >>> >>> ______________________________________________________________________ >>> This e-mail message and any attachments to it are for the sole use of the >>> intended recipients and may contain confidential and privileged information. >>> This e-mail message and any attachments are the property of Yusuf A. >>> Alghanim & Sons w.l.l. or any of its subsidiaries or affiliates (“Alghanim >>> Industries”). Any unauthorized review, use, disclosure, or distribution of >>> this e-mail message or its attachments is prohibited. Any opinions expressed >>> in this message are those of the author and do not necessarily reflect the >>> opinion of Alghanim Industries. If you are not an intended recipient, please >>> notify the sender by reply e-mail and destroy all copies of the original >>> message and any attachments. >>> ______________________________________________________________________ >>> >>> _______________________________________________ >>> suse-sles-e mailing list >>> [email protected] >>> http://listx.novell.com/mailman/listinfo/suse-sles-e >>> >>> >>> _______________________________________________ >>> suse-sles-e mailing list >>> [email protected] >>> http://listx.novell.com/mailman/listinfo/suse-sles-e >>> >> >> >> _______________________________________________ >> suse-sles-e mailing list >> [email protected] >> http://listx.novell.com/mailman/listinfo/suse-sles-e >> > > > > -- > Regards > Zhu Chao > > > > > _______________________________________________ > suse-sles-e mailing list > [email protected] > http://listx.novell.com/mailman/listinfo/suse-sles-e > > _______________________________________________ suse-sles-e mailing list [email protected] http://listx.novell.com/mailman/listinfo/suse-sles-e