C
ChUIMonster
Guest
Even "slow" internal disks are fast compared to a "high performance SAN" (which is an oxymoron... sort of like "jumbo shrimp" only worse). Ordinary "SAN storage" is, of course, simply pathetic when it comes to disk performance. Solaris and ZFS have lots of knobs to twist and provide plenty of rope to hang yourself with. From your description it sounds like something might have been adjusted in your Solaris 10 configuration but has been overlooked in Solaris 11. But I have no idea what that might be. You might try some IO performance tests that take OE out of the equation -- that can often help the storage people to get past the "blame Progress" phase and start to take the problem seriously. Sometimes you just have to live with bad IO performance. In that case you might have some success by tuning Progress to avoid IO as much as possible. Which means that you will needs lots of RAM. This is where the 32 bit executables are killing you. That limits you to 2GB of RAM for the buffer pool (the -B db startup parameter). In this day and age and with datyabases that large 2GB is minuscule and it is no wonder that you have poor performance that is sensitive to the performance of the underlying disks. Avoiding IO is a good idea in any case but it is really critical when IO performance is sub-par. The main IO reducing tunable available from the db perspective is -B. Since you mention that the issue seems to be reading records under load that is probably your best bet. (If the issue is actually CPU rather than disk IO then -lruskips might be useful.) Depending on how the clients doing the reading connect and what they do you might also benefit from tuning some of the client startup parameters, especially -Bt if temp-tables are part of the problem. If the clients are connecting with -S then you should also look into -Mm and the -prefetch* parameters. And ensure that all of the Solaris network settings are optimal. "Jumbo frames" can be helpful.
Continue reading...
Continue reading...