Re: Parallel Application Processing

Holger Baer wrote:

> That goes without saying. But the point is, that in a typical batch environment
> CPU and disk usage aproximately level out, so while one process is using
> CPU the other one is waiting for disk.

Granted. But I have not seen anything typical over here for many years. :-)

> And I talked *specifically* about
> batch processing, which means the processes are actually doing something -
> not some threads that are just hanging around. :-)

Sometimes you do want them to hang around at times..

Many years ago I write a motionsink DLL for use with a simulator and it worked just fine on Windows ME. It hit WinNT so hard that it alone redlined the CPU. The reason that the main loop was using non-blocking calls to check for the availability of UDP data. On WinME the kernel ran with this loop without issues. That non-blocking sycall was very light despite the tight loop. Negligble overheads. On WinNT I had to add a delay in the loop to give the NT kernel a breather between loop iterations and syscalls. Very weird. It seemed that NT just loved that tight loop and really hit it very hard and very fast despite the priority of the thread running the loop - even at the lowest priority mode this thread still attempted to consume 99% CPU resources. Only by adding a dealy into it, forcing the some idle time during the tight loop, the kernel got a breather to do some other work.

Point is that you're never sure upfront just how the o/s (or even Oracle) will treat a tight loop - until you run and monitor it. And a loop being slightly lazy may just be worthwhile at times. :-)

> As for the scalability of this solution: You just have to break it up into
> enough pieces, set the job_queue_processes accordingly and Bob's your
> uncle.

Bob? I hope he's a rich uncle? I sure can do with one.

--
Billy