Mike O wrote:
My ISP keeps killing the rebuildall.php script. ...it
regularly spikes
the CPU utilization to between 70% and 90%. ... The script might run
about 60 seconds max. Is there anyway to throttle it so that it works
slower or uses less CPU time? I tried forcing the priority to stay low
(using the 'nice' command and adjusted priority to 19, the lowest
possible), and even so, as I said, I think the ISP has some script
running that kills the process after a max of about 4000 articles indexed.
It might be possible to throttle it, but it probably wouldn't be
useful to.
It would be good to know whether your ISP is killing the
process because of sustained high CPU usage, or overall CPU time.
If it's overall CPU time, then throttling won't help, because it's
going to take as many CPU cycles to do the job as it takes to do
the job, and spreading them out over a longer period, though it
will obviously reduce the load average, won't reduce the overall
time.
Try running the command
ulimit -a
on the same account where rebuildall.php runs, to see if there
are any CPU time or other limits being imposed on you.
If the script is being killed because it's spiking the load
average, and even when you've niced it, this is shortsighted on
your ISP's part. It's a characteristic of the Unix (and Linux)
schedulers that if a process is 100% CPU-intensive, and if there
are no other CPU-intensive processes competing with it, it will
gobble up 100% of the CPU, even if it is maximally niced.
There's nothing wrong with this, and one shouldn't feel guilty
about "gobbling up" the CPU in this way. The CPU is there to be
used, so if no one else needs it, your process might as well use
all of it. If and when other processes start up that need some
CPU, Unix/Linux will share it with them fairly, or more-than-fairly
if you've done the polite thing and niced your process down.