Although Nuke Studio is capable of rendering frames internally, running the Frame Server on an external machine can accelerate the process considerably by sharing work across a network of machines.
NOTE: The Frame Server requires a Nuke Studio license (nukestudio_i) on the main workstation, but only a Nuke render license (nuke_r) on the slave machines.
If you want to use an interactive license (nuke_i) on the slave machines, add the --useInteractiveLicense argument to the runframeserver.py command described below.
Nuke Studio's Frame Server can be set up on an external machine (or a number of machines) to render from your Nuke Studio session. To do this, you need to run the runframeserver.py script on the external machines, found inside the Python site-packages, with specific command line arguments.
WARNING: In order for everything to work smoothly, you'll need to ensure that both your external slave machines and main Nuke Studio session can read and write files to a shared location, such as an NFS share.
Depending on platform this can be done by manipulating your default umask setting, but be aware that this alters the permissions of the created files.
Additionally, Mac OS X and certain Linux distributions, such as RHEL, can not function as the main workstation if the firewall is blocking the communication port 5560. You can configure the firewall to allow certain ports through the firewall using the iptables command, but use caution when doing so. For example:
sudo iptables -I INPUT -p tcp --dport 5560 --syn -j ACCEPT
Please refer to the documentation on firewalls for your particular platform for more information.
The Frame Server uses a number of worker processes on the external machine, each of which requires allocated resources, such as threads, memory, and so on. There are a number of arguments that you must pass to runframeserver.py for the server to work correctly:
• --numworkers - this is the number of concurrent Nuke processes that are launched when you run this server render node.
• --nukeworkerthreads - the number of threads that each worker is allocated. This is similar to setting the -m argument when running Nuke from the command line.
• --nukeworkermemory - the amount of memory, in MB, allocated to each frame server worker.
• --workerconnecturl - the TCP port address of the main workstation you want to serve. For example:
tcp://bob:5560
where bob is the resolved hostname of a machine you which to serve. You can also use an IP address.
TIP: To ensure that you're entering a valid URL, try using the ping command to see if you get a response.
• --nukepath - the path to the Nuke application on the slave workstation.
TIP: On Windows, if there are spaces in the file path, remember to place the path in quotes.
For example, --nukepath="C:\Program Files\Nuke9.0v10\Nuke9.0.exe"
On a Linux slave machine, an example command prompt entry running from the install directory might look like this:
./python ./pythonextensions/site-packages/foundry/frameserver/nuke/runframeserver.py --numworkers=2 --nukeworkerthreads=4 --nukeworkermemory=8096 --workerconnecturl=tcp://bob:5560 --nukepath=./Nuke9.0
On a Windows slave machine, an example command prompt entry running from the install directory might look like this:
python.exe pythonextensions\site-packages\foundry\frameserver\nuke\runframeserver.py --numworkers=2 --nukeworkerthreads=4 --nukeworkermemory=8096 --workerconnecturl=tcp://bob:5560 --nukepath=Nuke9.0.exe
In the examples, we specify that the slave uses two Nuke workers, with four threads and 8 GB RAM each, and are slaved to the main Nuke Studio workstation running on bob.
TIP: If your slave machines run a different OS than your main Nuke Studio machine, you can use the --remap command line argument to convert file paths between them. The host file path is read first followed by the slave file path. Nuke Studio expects all file paths to use / (forward slash) between directories. For example:
--remap "P:/,/mnt/renders/"
converts host paths beginning with P:/ (Windows style) to slave paths beginning with /mnt/renders/ (Linux style).
You can check that the Frame Server and workers are connected by running the following lines in the Script Editor on the main workstation:
from hiero.ui.nuke_bridge.nukestudio import frameServer
print [worker.address for worker in frameServer.getStatus(1).workerStatus]
Successful connections should report something similar to the following in the output panel:
['Worker 0 - henry.local - 192.168.1.11', 'Worker 0 - bob.local - 192.168.1.111', 'Worker 1 - henry.local - 192.168.1.11']
Where henry.local is the name of the remote slave, and bob.local is the name of the main Nuke Studio session.
NOTE: If the workers cannot contact the Frame Server, an exception is printed in the Script Editor's output panel.
Broker and Worker logging can to help diagnose Frame Server issues. The logs are written to NUKE_TEMP_DIR/logs by default, and take the form:
broker.log
worker-0.log
worker-1.log
worker-2.log
NOTE: Running the Frame Server using Python, as described above, always writes log files to the specific OS temporary directory. For example, on Windows C:\temp is used.
TIP: You can use the FRAMESERVER_LOG_DIR environment variable to force Frame Server logs into a different location. See Setting Environment Variables for more information.
|
|