Nicolas Calimet <pov### [at] freefr> wrote:
> (i) you simplify your run script; e.g. I don't get why you sleep for many seconds
> before you start the next megapov job in bg, assuming all jobs are independent.

Well, that's just the script I happened to be running; it was custom-tailored to
the specific "environmental conditions" and other constraints of that render:

- I had three other render processes running already, which I wanted to finish
before starting renders "B" through "D" to limit the number of "CPU-hungry"
processes to one per core.

- I had a deadline to meet, so there was not much time for developing a smarter
script, nor any room for risky experiments.

- When running a previous batch of renders for the same scene, I had started all
renders simultaneously, but checking after some minutes I had found the CPU load
highly unstable and at roughly 75% only, accompanied by heavy disk activity. I
attribute this to high physical RAM requirements (allocated memory was 1.1GB
per process), causing the render processes to waste time kicking each other to
swap space instead of peacefully crunching their numbers. After pausing one of
the processes, disk activity and CPU utilization slowly settled down to a
stable level, and re-starting the paused task later did not raise the issue
again, indicating that the high memory requirements were mainly limited to the
startup phase.

So all in all, I guess using those "sleep" statements was the smartest thing to
do.


> (ii) use nohup for each megapov run, or, much better, redirect stderr for all of
> them; redirecting stdout as well should be useless provided you use +oFILE.

I see the "just to be safe" benefit of wrapping each megapov run in its own
"nohup" statement, and redirecting stderr for the "A" render as well, both
which come at virtually no cost (although I'd have to introduce yet another
logfile, because otherwise I wouldn't be able to log errors spit out by the
script itself).

However, if I understand you correctly, this still doesn't shield my megapov
runs from SIGINTs, right?

Post a reply to this message