Sun Fire T2000 vs. Sun Fire V440

SunFireT2000Thanks to the diligence of my coworker Scott Maziarz we have been able to run some practical performance tests on the new Sun Fire T2000 we got on a try and buy program from Sun.

About our environment

While we’re not truly equipped for traditional load testing here at Plymouth State University I decided early on that our daily datamart scripts would be a good test of this system’s capabilities. These scripts are a combination of vendor supplied and homegrown code which create datamarts for reporting. The scripts run separately take between a minute and several hours to complete. They rely heavily on joins and functions so, while there is a fair amount of disk I/O, the speed of the processors and memory should play a large role.

Oracle 9iR2 was used for the testing on both systems. The database configuration was not altered, so despite the point that the T2000 has twice as much memory as our V440s (16GB versus 8GB) Oracle will be using the same amount of memory on both systems. We also unfortunately did not have the opportunity to do any performance tuning on the T2000. As such I consider this a comparison with a straight out of the box T2000. With some careful system tuning the T2000 would probably perform even better.

The two systems

Sun Fire T2000

  • 8 core 1.0GHz UltraSparc T1Processor
  • 16GB memory
  • 2 * 73GB 10K RPM SAS hard disk drives

Sun Fire V440

  • 4 * 1.0GHz UltraSparc IIIi
  • 8GB memory
  • 4 * 73GB 10K RPM Ultra320 SCSI hard disk drives

While these two systems are different in many ways they are comparable in price (the V440s are actually quite a bit more expensive, but this one is around two years old now.) All testing was done on internal disks making the results dependant on the entire system performance.

Oracle was not reconfigured to take advantage of the extra memory in the T2000.

The tests

For the testing we chose a set of 19 datamart creation scripts which we run daily in our production environment. To assure that there is no additional load on the V440 we ran the tests on our reporting instance which is on a relatively idle system.

The first test is to run the 19 datamart scripts staggered. This is how we run them in production. Four scripts are started every half hour to spread out the load on the server. There’s a lot of overlap, but the staggering is enough to keep the system responding normally.

Scripts running staggered

The graph above represents the runtime of each job individually. A shorter line represents a quicker runtime and we can see that the T2000 consistently outperformed the V440 often running n a quarter the time!

The total runtime for all 19 jobs was 2915 minutes on the V440 and 847 on the T2000. On average it took only 29% as long for the jobs to run on the T2000!

For the second test we ran all 19 jobs at once.

Scripts running simultaneous

We still see a significant improvement in performance, but not as high as when these were run staggered. Here the T2000 completed the tasks in 59% of the time of the V440. I attribute this to contention for disk on the T2000.

Thanks to Scott Maziarz for running the bulk of these tests and compiling the results for me.

Conclusions

The Sun Fire T2000 has certainly proven its worth. Some may be put off by the relatively low processor speed (the model tested was a mere 1GHz) but it is clearly not an impediment. The 8 core CPU seems to be up to the challenge and I’m sure with additional tuning I’m sure they’d scream.

With increased performance and higher efficiency than the comparably priced V440, the T2000 will definitely be in our future. The lower energy consumption and lower heat output would be a welcome change in our already taxed data center and the compact 2U size should be an easy fit in any rack.

Check out more details at Sun’s website and if you’re still not convinced apply for your own free 60-day trial!

sun, sun fire t2000, t2000, server, systems administration, database administration, dba, oracle, rdbms, sysadmin, sun microsystems

Oracle Prefers Solaris 10

It looks like Oracle is re-aligning themselves with Sun Solaris as their preferred 64-bit platform. In the March issue of Oracle Magazine they have a short announcement on the topic:

Oracle has chosen the Solaris 10, Sun Microsystems’ multiplatform, open source operating system, as its preferred development and deployment platform for most 64-bit architectures. Solaris 10 will be used throughout Oracle’s development organization, and Oracle will release and ship 64-bit versions of all Oracle products on Solaris prior to, or simultaneously with, release on other operating systems.

Check out the whole article here or sign up to get your free copy of Oracle Magazine.

Thanks to Jon G. for sending this on to me.

oracle, database, database administration, dba, systems administration, sysadmin, solaris, sun, sun microsystems, UNIX, open source, 64-bit

Oracle on Solaris: 32-bit or 64-bit

It is important for optimal performance to make sure you match up your Oracle RDBMS installation with your OS. Running a 32-bit version of Oracle on a 64-bit OS is may not give you peak performance, but also will not be able to address large segments of RAM and large files. So how do you know what your OS supports? How can you tell if that Oracle install from before you started is 64-bit? Here’s how:

Is my Operating System 64-bit?

In Solaris, from the command line (you don’t have to be root in most cases) run this command:

/usr/bin/isainfo -kv

If your OS is 64-bit, you will see output like:

64-bit sparcv9 kernel modules

If your OS is 32-bit, you will get this output:

32-bit sparc kernel modules

For Linux users

If you are running Linux, you can check your distribution with the uname command:

uname -m

The output will read x86_64 for 64-bit and i686 or similar for 32-bit.

How about this Oracle install? Is it 64-bit?

The question here is weather your Oracle binaries are 64-bit. While some of the binaries associated with Oracle may be 32-bit, the important ones will be 64 bit. To check those, follow these steps from the command line:

cd $ORACLE_HOME/bin
file oracl*

This will display the file type of your oracle binaries. If you are running 64-bit binaries, the output should look like this:

oracle: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped
oracleO: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped

If your binaries are 32-bit, the output will look like this:

oracle: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped

If you find you are running 32-bit and decide to go to 64 be careful. The switch can be a bit tricky. Read the documentation closely and make sure your service contract is payed up!

oracle, dba, database administration, database, solaris, linux, sun, sun microsystems, 32-bit, 64-bit