SUMMARY: Dreadful Performance, but stats look fine

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: http://kevinclosson.wordpress.com/2006/11/30/marketing-efforts-prove-sunfire-t2000-is-not-fit-for-oracle/
* 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.

S.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers