Timeslice Poll: How high is high?

[doug mielke]

In running Oracle 8i w/ apps 11.03 on an 8 way N class w/ 24 gig Ram. Probably a fairly common config.

I've raised times slice from 5 to 10 to 15, with performance improvement each time.

We face a constant battle against inefficient code, and still have many long running jobs. I'm thinking raising timeslice more will help. ( after all, Unix does almost the same for me as it raises these priorities to max after a while)

My question is, What are some of the longer time slice settings that you folks are using?

[Steven E. Protter]

There will come a point where you don't get any more benefit from increasing the timeslice.

There are other performance moves you can make that can really bump up oracle performance. I know about your battle, it gets worse here with every upgrade from Redwood.

Take a look here:
http://www2.itrc.hp.com/service/cki/search.do?category=c0&docType=Security&docType=Patch&docType=EngineerNotes&docType=BugReports&docType=Hardware&docType=ReferenceMaterials&docType=ThirdParty&searchString=UPERFKBAN00000726&search.y=8&search.x=28&mode=id&admit=-1335382922+1066917098030+28353475&searchCrit=allwords

Document id: UPERFKBAN00000726

I'm attaching the performance data collection scripts that can help you decide what other things to change.

To directly answer your question, our timeslice is set to 10. I do not recall changing it. Oracle 8.1.7.4.0 ias 1.0.2.2 pl 12. Currently upgrading to 9.0.2.x database server.

SEP

[Jeff Schussele]

Hi Doug,

Personnally I've never had to move off the default of 10.

You may also want to consider nicing/renicing the important processes with a negative value to give them a higher priority instead of adjusting the timeslice. That way you guarantee that only they get a priority bump and that bump remains for their life.

My 2 cents,
Jeff

[A. Clay Stephenson]

If given a choice between long and short then always choose long. There is very little reason to drop it below 10 and I would never go below 5. The real problems occur when it is dropped to 1; under ever moderate loads, the system does context switches and very little else.

I've run timeslice as high as 100but, of course, there is a trade-off. To interactive users, the system can appear "sluggish" but the batch processes are happy. In general, the consensus for most "typical" boxes running a mixture of interactive and batch processes is to leave it at 10. If your box does mainly batch stuff (e.g. a pure database server) then you might find that 20-30 is a good reasonable value.

[Patrick Wallek]

I have yet to have a valid reason to move from the default of 10.

I would *NEVER* go below 10.

[John Poff]

Hi,

I've never had it above ten, but it sounds like you are doing it the right way by moving up a little at a time and trying it.

I'd be curious to hear what results you find as you continue to move it up. I'm guessing you will eventually reach a value where your performance gains start to flatten out.

JP

[doug mielke]

Clay, Thanks for the number. Next time I'm in the kernel I'll try 30. I'm not worried too much about the possibility of sluggishness you mention, since at busy times I can have a dozen or two top priority jobs fighting for the 8 processors, and a low prioity task just waits.

Jeff, I consider nice a temporary measure, and doubt it will help much on a long running job, as Unix will raise the priority to max after a time.

Steven, Thanks for the doc. I've been through that one and more. It's what I've spent my time on now that I've given up wild women (okay, they gave up on me, but same result)

[Jeff Schussele]

Hi (again) Doug,

Well to be realistic you'd have to consider timeslice to be a temporary measure as well.

What you really need to do is break out the Get A Clue Bat & thump a few developers to fix the crappy code, wouldn't you think?

The problem I perceive with timeslice is that ALL processes will be getting that extra time on the CPU.

You have to remember that the nice value is used to calculate process priority value. Setting a negative nice causes that process to regain priority more quickly. So a negative niced process will be higher prioritized on average than a normally niced process. And will therefore get *more* CPU time.

Rgds,
Jeff (feisty as ever I guess)

[Jean-Luc Oudart]

Well the code should be investigated !
Once was blamed for poor performance on server and fought back with TRACE and co (statspack, ...) as I found that one of the main piece of code did not use bind variables.

Just an example.

Time slice is kept to default.

http://www.ixora.com.au/tips/

Rgds,
Jean-Luc

[Pete Randall]

Doug,

Please excuse this OT post, but you really should go over here:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=238431

and congratulate Patrick. It was your 4 points that put the salad on his head (20,000 exactly, by the way). I'm sure he'd like to thank you!


Pete

[Tim Sanko]

On an 8 way N4000 we have a time slice of 20.

We are running visibility as an ERP!!!

It has many long running jobs and Oracle Apps I used to hate seem efficient to me...
on a 16 Way V-2600 BOX time slice is 2...

Tim

[Pete Randall]

Thanks, Doug!

[doug mielke]

Pete,
Lets get you started quickly on that next 20K.