Greg Ercolano wrote:
over to that machine and look at 'top' and/or the output of eg. 'vmstat 3'
BTW, I should add the 'vmstat 3' command is linux specific.
The equiv on a Mac would be, IIRC, "vm_stat 3".
These commands are useful if you suspect renders are taking up too much
cpu by thrashing the box with eg. swapping/paging activity.
If, however, rushd is busy (ie. is taking up >90% of the cpu, and showing
at the top of the top(1) report), then don't bother using vmstat/vm_stat.
In that case let us know, and we can debug from there to determine why
rushd is so busy. (Maybe jobs are invoking 'rush' commands during rendering
that are beating up the server. A common problem is when custom render scripts
are used that invoke commands like 'rush -lf' or 'rush -notes' commands
before or after every rendered frame, invoking excessive TCP connections
back to the job server, causing the job servers to appear 'slow')
If rushd is busy, do you have job serving distributed to several machines (good),
or are all jobs being submitted to a single machine (bad)?
--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)
|