SUMMARY: Dreadful Performance, but stats look fine

From: Stephen Nelson-Smith <>
Date: Tue Aug 18 2009 - 09:43:16 EDT
Hello all,

Thanks for the many helpful replies - this really is a wonderful list.

Here's the original problem:

"""We have a SunFire T5220, which serves as an Oracle 10.2.0 server.   
We have some contractors who are loading data into some databases - a  
basic dump and load.  They have a copy of the database on their  
laptop, and the dump and load takes 20 mins.  It's been running for  
over 3 hours on the Sun box.

The server is in the same building as the contractors.

I've had a look at iostat, vmstat and netstat, and I don't see  
anything at all concerning.  The CPUs are idle, there's no evidence of  
IO wait. Sar doesn't show any paging taking place.  Iostat shows low  
%b figures, and service times peak at 25 ms, but average at 1 or 2.

I'm baffled, and I've got people breathing down my neck asking how a  
laptop can be 7 times faster.

I'm wondering if there are any ZFS stats I can gather?

Any ideas - I'm a bit stuck!"""

Here's the collected wisdom:

* Niagara series machines are built for heavily concurrent loading -  
they have many threads, but each thread is very slow.  Something like  
a SQL import will be single threaded, and will obviously be very slow  
on a 1.2G SPARC core vs a 2.4G Intel.
* There seems to be a difference of opinion on whether CoolThreads  
servers are good for Oracle.  My reading of the issue is "it  
depends".  In many cases they could be ideal.  But one thing's certain  
- they're absolutely not optimal for batch-type processing.  Several  
people told tales of having to dump theirs and replace the with  
something different.  Let the buyer beware!  An interesting discussion  
can be found here:
* I was relayed the following useful analogy:

"I had someone at an opensolaris users group meeting describe the T2  
based systems as large moving trucks (say tractor trailer truck) as  
compared to a really fast AMD as, say, a fast sports car. If you just  
have one process to move across the country, the fast sports car will  
win easily. But, if you have a hundred processes to get across the  
country, the sports car will burn out while the tractor trailer easily  
completes the job."

* We're going to try to use Oracle datapump to get a bit more  
concurrency, and for future think about splitting dumps and loads into  
smaller lumps
* Several people suggested checking the health of the Oracle setup -  
I'd already done this, but there were some useful pieces of advice.
* One particularly important observation was that imports over the  
wire are very slow.  Also my NIC has autonegotiated at 100Mbps/Full,  
so I'm checking whether there's a misconfigured switch or nasty hub  
somewhere in the equation.

The problem's not solved yet, but I'll report back with any more  
useful findings.

Thanks again, as ever.

sunmanagers mailing list
Received on Tue Aug 18 09:44:27 2009

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:14 EST