We could do that, but some processes spawn and die (e.g. MTS dispatchers,
servers) based on changing load, and I'm not sure they'd get the same
priority.
I had read in Steve Adams' book on internals that exploiting the real-time
scheduler is something to consider, so since I've seen him post, I thought
I'd ask. :) [Actually, a review of this material brings to mind another
set of questions about 'priority fixing facility' that I'll research on
Solaris before posting again.]
I had not heard about Oracle not wanting you to change priorities, but it
makes sense. It's sort of like the 'pin a process on a cpu' thread -- many
minds have worked on the scheduler, so why muck with the behavior of that
code? We're likely only to make things worse.
However, as a bit twiddler at heart (dare I say "h*cker"?) my curiosity is
piqued about other scheduling classes. Given we trust that Oracle's
processes are well behaved and sleep when there's no work, I think this may
have merit on CPU-starved systems or those with a huge number of processes.
thanks,
Steve
-----Original Message-----
Sent: Wednesday, June 13, 2001 10:21 AM
To: Multiple recipients of list ORACLE-L
Two comments:
1) Why not just re-NICE the shadow (or offending procs)
2) Last I heard oracle does not recommend running
their procs at differing NICE levels.
-----Original Message-----
Sent: Tuesday, June 12, 2001 6:33 PM
To: Multiple recipients of list ORACLE-L
Folks,
Does anyone know how to exploit the real-time scheduler in Solaris? I can
only find vague references to this on the web.
We're considering using the real-time scheduler for Oracle background
processes on our busiest Solaris boxes (that support 2-3k connections). We
want to make Unix bias the Oracle background processes for CPU, all other
things being equal. We had some consultants suggesting our MTS config
wasn't getting the cycles it needed after we called into question their SQL
(which is too long a story for me to get into -- I'll begin ranting about
big consulting companies. :)
Thanks,
Steve
Steve Austin
DBA for Unix-based systems
Enterprise Data Center Operations, XO Communications
email: [EMAIL PROTECTED]
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Austin, Steve S
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Mohan, Ross
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Austin, Steve S
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
