Sun T2000 As DB Server

I have a customer running 9.1E on that platform. No problems or issues have arisen. I wouldn't expect OE10 to be a problem.

-Progress 10.0B

-Sun-Fire-T2000
-SO Solaris 10 6/06 s10s_u2wos_09a SPARC
-118833-17, sun4v sparc
-RAM 8GB

We are comparing our overall application performance (host-based self-service app) on this box against a small HP server using RH Linux and 10.0B , both with no significant user load).

Differences are 1 to 5 in favor of Linux.

Anyone willing to share some advice on where the problem could be, if any?

We have little experience in Sun Solaris (SPARC) platform.

Thanks,

Ariel.

If the Linux box is new and the T2000 is of a vintage in line with 10.0B then the explanation is probably quite simple -- Moore's Law.  You're comparing 3 or 4 year old technology to today's technology.  In that case (to the degree that your tests are CPU bound) the Intel chip is going to kick the Sun chip's butt.

Hi Tom, not really. Both servers are equally aged (2005), my initial idea was that the SUN server should offer much better performance than the HP. Something must be wrong on the SUN box.

It is okay to compare SPARC against X86 for Progress applications?

I ask this because I found some references to performance problems on the T2000 for single-threaded operations compared to the X86 platform:

The T1/T2 range is fine for low-power, high-throughput workloads where there are lots of largely independent threads. The T1./T2 hardware threading effectively treats the core resources as a system in its own right and despatches

different parts of different hardware threads onto the core resources. A sort of multi-tasking within the core (for instance, the T1 has 4 threads per core and one integer unit whilst the T2 has 8 hardware threads and two integer processors per core). Now this is very efficient as resources that would otherwise be unused due to thread stalls for things like memory access can be used. However, it comes at the cost of seriously slower single-thread speed, especially so when the underlying core resources are over-committed (which, incidentally, means that CPU utilisation as reported by the operating system is seriously non-linear as the OS sees the hardware thread, effectively a virtual CPU, as the resource and not the core utilisation).

The T1/T2 is not a competitor to Power. Either a shop has committed itself to AIX (in which case Power is a done deal). The real competition to T1/T2 comes from the x86 side where sheer volume (and better single thread speed) is the real challenge from the latter.

Apart from this, is there any tuning test you recommend on Solaris?

Like the article says... the T2000 is a fine small server but it's nothing terribly special.  As I recall at the time it was roughly comparable to run of the mill Intel servers and it was probably being targeted to Sun customers who were considering switching to Intel.  Sun was almost giving away the T2000s to anyone who whispered "Dell" within earshot of a sales weasel...

Why do you expect it to be "much better" than the HP?

As for tuning it...  I'm not aware of any specific magic tuning options for that particular server.  All of the usual stuff would apply.  There are some goofy things with Solaris to watch out for.  They've got some funny ideas about things that don't work so well with db servers in their more recent releases.  I forget what they call it (Sun is mostly fading away with my customers) but what little I remember this morning has to do with virtualization and some crazy defaults that limit an instance to something like 25% of installed RAM (or something like that) that effectively turns the server into a boat anchor.  As I recall all you have to do is upgrade -- and Solaris imposed these crazy limits whether you want them or not.  Perhaps someone else recalls the details?

Not that I expected to be it much better, just to be similar or a litter better performant but it is 5 to 10 times slower than X86 technology from the same year.

I just have to guess something must be wrong on the SUN box or there are significant changes to be made in the configuration at OS level, because I doubt it that the problem (5x slower) can be Progress tuning.

I don't have e clue where to start however.

Any guideline?

It could be something simple -- perhaps you're running the ATM bechmark and the T2000 has RAID5 while the HP is attached to an EVA.

The problem description is kind of vague...  What tests are you running and what results are you getting?  What is the detailed configuration of the two environments being tested?  Why is it worth pursuing this issue?  (It seems kind of silly...)

The simplest way to go from not having a clue to being clueful would be to engage a good consultant to come in and mentor you.

No, the T2000 has no RAID configured.

Our Progress app runs mostly on Linux over X86 platforms, no problems there.

A client of us has a T2000 server with Solaris 10 so we are running the same application over that kind of platform which is unknown by our DBA.

As stated in previous mails, the app runs 5x slower (ore more) on the T2000 than any of the other X86 platforms (including very small "servers") so before we get into the configuration details our first question that arised was if this kinf of architecture has any general and known problems with Progress when compared to similar aged X86 environments. If as I understand your answer is "NO, the results should be similar" then we should get detailed configuration information and a good consultant with SPARC experience to detect and fix the problem we are having.

I may sound like a broken record but you really need to get more specific about what it is that is slower.

An application is a big thing and it is extremely rare that an entire application would be uniformly 5x slower on one platform compared to another.  Certain reports might be consistently 5x slower, various inquiry screens might be 5x slower, keystroke echos might be 5x slower, screen refreshes after the "ok" button might be 5x slower, an MRP run with certain conditions might be 5x slower.  And it is likely that in reality there is lots of variation even within these sorts of groupings.  Just knowing the nature of what, specifically, is slower and what the specific measurements are can very often provide a strong indication of where to look for the problem.

Yes, it is possible that there is something Solaris specific.  Unlikely, but possible.  There is certainly no magic bullet for Solaris that fixes a well known "it's 5x slower than arbitrary x86 hardware" problem.  It is much more likely that there is a significant undisclosed (and probably unknown) difference between the configurations being compared.  I tossed out RAID as an example -- not as the definitive difference.  The list of possibilities is endless (and the prioritization depends a lot on the specifics of what, exactly, is slower).

As for consultants, we can do that   As I said, we see much less Sun than we used to but we do have Solaris experience and I even have a customer with a T2000 that performs well for their purposes.

unfortunately, we face the same problem with this.

T2000 Soloris 10 with Progress openedge 10.1c have a low performance out of my expectation.

We use Fire V240 solaris 9 with progress openedge 9.1d, its performance seems ok. Buying T2000 is for upgade and backup. But it seems a bad choice.

For tuning, after consulting with SUN and trying all measurement, nothing have been improved.

So we are thinking to replace it with Intel+Linux.