Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 559
  • Last Modified:

HW recommendation

Our server is typical OLTP (online brokerage system), current HW (dual Xeon 2.6 GHz, 5GB RAM) is under heavy load, mainly CPU and it seems that application is quite well optimized, so it seems like adding processors is way to go. So we want to upgrade to 4 way server, we want to stay on x86 and Linux OS.

As far as I know, we can choose between Intel Xeon, Intel Xeon MP and AMD Opteron. Xeon has smaller L3 cache than Xeon MP (2MB vs 4MB), but has higher bus speed (800 MHz vs 400 Mhz) and slightly higher frequency (3.6 GHz vs 3.0 GHz). Opteron has even higher bus speed (1.6 GHz), smaller cache (1 MB), I can use 64-bit ASE, but I'm not sure, if it's proven in production systems. Which option would you recommend ? What's more important for performance - bigger cache or faster CPU - RAM transfers ? Do you have experience with production systems on Opteron server ?
Jan Franek
Jan Franek
  • 2
2 Solutions
> we want to stay on x86 and Linux OS

If you want to stay on x86 architecture, then Opterons are out - they are AMD64 cpus.  More cache is generally good, but there is a point where performance increases diminish.  I would say the higher bus speed of 800 and the higher frequency more than offsets any advantage extra cache provides.  2MB cache is already a large amount, and more at the cost of the other factors works against you.

If you really want to consider Opterons, then I think you will get the most performance.  I have started experimenting with Athlon64's and can say the memory bandwidth is amazing.  I don't have any experience with Opterons, but here is an article benchmarking them against Xeons: http://www6.tomshardware.com/cpu/20040927/index.html
Joe WoodhousePrincipal ConsultantCommented:
I agree with Callandor's answer, but I'm coming at it top-down rather than bottom-up. (I'm sure I'm telling you stuff you already know, but I'm wanting a full solution here in the archives for other people who might search later.)

Batch or DSS workloads in Sybase tend to benefit more from making CPUs faster than from adding additional CPUs. These workloads are typically more concerned with reducing response times than increasing throughput. So at a hardware level, the smart choice is to go for what makes each CPU itself as fast as possible. Remember most of the Sybase tasks in this workload are single-threaded - however that that task will be handed off from one Sybase engine to another (no task affinity by default), and those engines will be switched from one CPU to another (I honestly don't know if cpu affinity is supported in Linux). Any Sybase task will tend to persist over many timeslices and will have to be handled with many context switches between engines and perhaps between CPUs.

OLTP workloads in Sybase tend to benefit more from adding additional CPUs, as these workloads care more about increasing throughput, which depends on how many tasks can run concurrently. Each Sybase task is probably small and will complete within relatively few timeslices. There weren't be all that many context switches, but without CPU affinity, Sybase engines will be constantly moved between CPUs.

So I'm saying there are three issues to tune for at the hardware level:

1) Number of CPUs.
2) Raw CPU power.
3) CPU to CPU context switching.

Point (1) isn't relevant here - all of your choices support four CPUs. (Do Opterons support more? Are there 8-way Opteron motherboards?)

Point (2) is where it gets confusing, because a higher clock speed helps raw CPU power, but so does a larger on-chip cache. There are diminishing returns here - it's a huge difference between 512Kb and 1Mb of cache, and a fairly big difference between 1Mb and 2Mb. I'm not sure that 4Mb adds that much more. On the other hand, 3.6GHz is a 20% improvement in clock speed. Remember, though, the whole issue of CPU power is more relevant to DSS/batch than to OLTP.

Point (3) is actually what decides this one for me. The higher bus speed will matter for any CPU to CPU operation (like a CPU context switch) or CPU to memory (which a database will do a lot of). This point is relevant to all Sybase environments - we'll always have engines moving between CPUs unless we're on a platform that support CPU affinity.

So Xeon (less cache, more CPU clock speed, more bus speed) seems to come out a bit ahead of Xeon MP (more cache, but less of everything else).

I hear good things about Opteron, and being able to go to 64-bit ASE would allow you to get over the current 32-bit Linux memory limit. Given Opteron has an even faster bus speed, odds are this would be even better. But, as you say, it's a newer architecture and Sybase's codelines aren't as mature. I haven't heard anything *bad* about Sybase on Opteron... I just haven't heard *anything*.

So, summary: I agree with Callandor. Opteron is likely to be the technically superior option for performance, but it is less mature. Of the more mature offerings, Xeon will almost certainly be better than Xeon MP.
Jan FranekAuthor Commented:
Thank you guys for valuable input. I have found, that 4-way server with Xeons (IBM x445) can use only 3.0 GHz Xeons with 512K or 1M cache and with 400 MHz FSB. So there's no advantage against Xeons MP (well, there is one - lower price :-). But Dell just starts it's new server line - PowerEdge 6800 - that will use new Xeon MP 3.6 GHz with 666 MHz FSB and with 1 MB L3 cache (cheap) or 8 MB L3 cache (expensive). So we are probably going to buy this one (cheap one of course :-).
Joe WoodhousePrincipal ConsultantCommented:
Good call, I think, and it gives you an upgrade path to chips with the larger cache if you need to squeeze out a bit more CPU power without a major upgrade to the motherboard.

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now