Oracle 10g and turning off/on hyperthreading while db is up

[TwoProc]

Just wanted to add a point about cio, as well as setting the scheduler threshold.

When you do both of these, and you're running a test, you'll notice cpu a bit higher, but keep in mind that that cpu is going to run higher because it *can*! If your processes aren't waiting as much on I/O, and not waiting as much on latches for block buffers, yes, you can and will use more cpu, however, our number of transactions completed during the test went up as well! Meaning that our tests, when running them transaction count based, finished faster, or if we ran them for x amount of minutes, the amount of transactions completed in that same time increased. Meaning that the server is just way more responsive queries. Just don't freak out when you make those two move and you cpu load increase, it is only increasing because it *can* do more work in the same amount of time!

[Duncan Edmonstone]

TP,

Great that you are using CIO, however I think you should review Oracle Support Doc ID ID 1231869.1

Specifically:
-------------------------
Do not use "-o cio" and "-o mincache=direct,convosync=direct" together. Use either Direct I/O or Concurrent I/O.

Using Direct I/O and Concurrent I/O("-o mincache=direct,convosync=direct,cio") may cause performance regression.
-------------------------

And:
-------------------------
Placing Oracle binaries ($ORACLE_BASE directory) on a filesystem mounted with "cio" may cause data loss and other unexpected problems.
-------------------------

And Finally:
-------------------------
Concurrent IO is not expected to provide a performance benefit over direct IO when used with online and archived redo logs.
-------------------------

So:
- use none of cio,mincahce=direct,convosync=direct on Oracle binares
- use cio on datafiles
- use mincahce=direct,convosync=direct on online/archive redo logs

That said, I don't always trust Oracle support documents when it comes to HP-UX (e.g. I'm pretty sure that article 555601.1 is just plain wrong when it comes to the flags you see for direct IO on HP-UX), so you might want to test these assertions...

HTH

Duncan

[TwoProc]

Thanks Duncan,

I'm going to look into that. However, the notes I had were that we should be using cio and direct i/o together. I plan to research that note asap however, and ask for feedback from our performance specialists.

If I had to lose one or the other, I'd lose cio. We did test them separately (direct i/o and cio), and the big bang for our buck was direct i/o. However, while we did see increased cpu costs for cio, we also saw increased throughput on the testing model. We figured the increased cpu cost was for doing more processing per unit of time, because we could, after clearing the waits after writes in I/O. You know how it goes, you clear one bottleneck to move onto the next.

Fortunately/unfortunately (that is, happily)- I'm live with both this morning. But, I will definitely investigate and pass this information on with the HPUX/Oracle performance team at HP which I procured for this conversion.

And no, binaries, report output, etc. are not mounted either cio or direct i/o.

I appreciate the thoughtfulness for the posting.

[Hein van den Heuvel]

For anyone seriously interested in Hyper Threading under HP-UX there is a MUST READ (watch/listen) session in the Knowledge On Demand presentations.

All presentations:
http://h71028.www7.hp.com/enterprise/w1/en/os/hpux11i-kod-overview.html

HT session is: Hyper-Threading on HP-UX 11i v3

The flash version did not work for me.
TheZIP file worked:
http://downloads.hpmediasolutions.com.edgesuite.net/managed/19031-1-MontecitoHyperThreadingOnHpUx11iV3_WindowsMedia.zip
The slides alone (PDF) work fine also.


The part I thought was interesting were
- slide 27: "Time Accounting on Montecito"
One key word in the is "hint@pause" which is something OpenVMS also uses.
- slide 31: "OS Scheduler change"
- slide 34: 1) Just try it! 2) probably need 75% cpu load while non-HT, 3) Potential for more throughput, not for better response time.

hth,
Hein.

[TwoProc]

Hein, good reference, I watched that presentation yesterday. And, while I wish it was updated for Tukwila, which is what I own, it was excellent information. Although, the main message was that you're not going to benefit unless you've got enough utilization coupled with spare cycles waiting on I/O, ram, etc.

What we've found here is that hyperthreading is absolutely wonderful for our big, nasty largely untuned or not-tuned-enough code that runs at night, along with lot's of maintenance code which includes, lots of accounting stuff, gathering statistics, checking index depths, updating and checking data growth, generating price books, bom trees, etc.

[TwoProc]

Oh, and I forgot to add that hyperthreading is not good at all for OLTP processing during the day.

[Alzhy]

That's why you migz should "taste" and go with Nehalems or Magny-Cours based systems running Linux64.

;^))

[Alzhy]

We have an aging rx6600 and a few rx2660s that I thought were not HT-Capable. And it turned out they are --- running Montecitos.

I turned on HT and my systems are now able to run more of our home grown perl and C short term exececution (but zillions of them) apps.