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.