Tuesday, February 07, 2006

Should I get a T2000?

So I'm looking at the new Sun T2000 boxes, and I tried the test program to see if my workload is suitable.

Now, this is a web server. That's all it does. And it's running coldfusion (ie JRun, as in Java), and Oracle, so first thoughts are that it should match pretty well. So I give pfp a whirl.

# /var/tmp/pfp -p 10
We observed 407247665 instructions separated
in 11.17% floating point and 88.83% others.

This workload is not recommended for UltraSPARC T1 systems.

That's not good!

OK, so that was an isolated incident. But this machine tends to stick at about the 1.5% grey area. This is typical:

# /var/tmp/pfp -p 10
We observed 1960035483 instructions separated
in 1.61% floating point and 98.39% others.

This workload is a potential fit for UltraSPARC T1 systems
and need to be tested.

Now, what I don't know is whether there's something odd about this machine, or Oracle, or Coldfusion, or the CMS sitting atop it, or the versions (oldish), or something about the fact that this is an old V880 running an old version of Solaris that pfp can't handle properly. But in any case, the T2000 doesn't look like a given.

I also tried looking at one of the machines I built myself recently, with an Apache/Tomcat/Postgres combo:

# /var/tmp/pfp 60
We observed 2132762256 instructions separated
in 0.05% floating point and 99.95% others.

This workload is recommended for UltraSPARC T1 systems.

That's what I expected. (And I get the same sort of thing on one of my Domino boxes.)

So I'm still unclear as to whether a T2000 would be a good bet for the old webserver.


Jaimec said...

Humm, Are you using a lot of blob structure types in Oracle? Are you sure you have proper indexes created? for your workloads, I really can't understand why you're getting such an high value of float ops. I've been doing profilling in several workloads and, I didn't gor anywhere near your values in a machine that's running a logistics Database (a lot more messy than your's should be)
Confirm those levels with a simple "kstat |grep fpu" and see if the results add up. Anyway, that's one of the advantages of the Try and Buy instead of the Buy and Try :)

On an unrelated issue, you now have 140 GB SAS disks for the Galaxy systems. I know it's not the same thing as having more disk bays but, It kind of solves your issue with the 100GB Web site (and leaving you with the issue of the 150GB Web site, ...).

Jaimec said...

Almost forgot (or why is it that I keep double posting in your weblog, ...)
with "kstat |grep fpu" you get a break down on the FPU instructions. in the Sun blueprints, in the "tuning apps for the T1" docs, you have there a list of the instructions that were moved from the FPU to the core and what instructions were left in the FPU. that's a nice way to try to guess your expected performance

Peter Tribble said...

Thanks! I don't understand it either, hence the blog entry.

I tried the kstat thing, and that doesn't really help - the fpu numbers are too low to be relevant. But as I recall these are the emulated instructions, not the ones that are done in hardware.

Looking more closely, it's all coming from the add pipe, which is a signature of memcpy done with VIS.