|well what we would like to have is the frame log with a time
|stamp for each line to compare the time our renders throw
|memory exceptions with the network spikes that we are seeing
|to be able to see if there is a relation between the 2.
You could add some code to the render scripts to append
log start/end times to a file.
Just define a function that does something like this:
require "ctime.pl";
sub LogTime($)
{
my ($msg) = @_;
open(FD, ">>/net/tmp/times.txt");
my $s = sprintf("%8s %-16s %-16s %s %s %s", $msg, $ENV{RUSH_HOSTNAME}, $ENV{RUSH_JOBID}, $ENV{RUSH_PADFRAME}, time(), ctime(time()));
syswrite(FD, $s, length($s)); # atomic write
close(FD);
}
..then just put these commands above and below the render command
in the submit script to time stamp the renders:
LogTime("Start:");
#
# render commands here
#
LogTime("End:");
You'll end up with a log for all renders on all machines
that looks something like this:
RenderHost Jobid Frm time() Date
---------- --------- ---- ---------- ------------------------
Start: feris tahoe.244 0001 1138098098 Tue Jan 24 2:21:38 2006
End: feris tahoe.244 0001 1138098103 Tue Jan 24 2:21:43 2006
Start: darwin tahoe.244 0071 1138098103 Tue Jan 24 2:21:43 2006
End: darwin tahoe.244 0071 1138098108 Tue Jan 24 2:21:48 2006
Then you can format the fields and data as you like.
I'm thinking the syswrite() in the above will 'guarantee' the data
stays synchronized (so you don't have lines of data intermingled)
Under unix anyway, syswrite() is supposed to be atomic, even over NFS.
Not sure about Windows.
|at the moment it looks as if converting maya to mi throws
|memory exception even though the ram is available. not sure
|about what it is I would like to be able to rule out the
|server performance.
Usually server performance just makes things slow,
and would hopefully not throw exceptions.
|maybe some sort of logging of the server and the frame log
|related to each other would help.
Yes; if you write a separate script that writes the server's status
into the above log, then you'd have the data all merged together already,
establishing a pattern if their is one.
--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)
|