Search TipsUsing the Frame Server on Render Machines
Although Nuke Studio is capable of rendering frames internally, running the Frame Server on a render 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 render machines. Local Frame Server processes use ports 5558-5662.
If you want to use an interactive license (nuke_i) on the render machines, add the --useInteractiveLicense argument to the runframeserver.py command described below.
Configuring the Frame Server on Render Machines
Nuke Studio's Frame Server can be set up on a render 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 render machines, found inside the Python site-packages, with specific command line arguments.
Warning: In order for everything to work smoothly, you need to ensure that both your external render 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 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 render 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 wish 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 render machine.
Tip: On Windows, if there are spaces in the file path, remember to place the path in quotes.
For example, --nukepath="C:\Program Files\Nuke13.2v4\Nuke13.2.exe"
On a Linux render machine, an example command prompt entry running from the application directory might look like this:
./python3 ./pythonextensions/site-packages/foundry/frameserver/nuke/runframeserver.py --numworkers=2 --nukeworkerthreads=4 --nukeworkermemory=8096 --workerconnecturl=tcp://bob:5560 --nukepath=./Nuke13.2
On a Windows render machine, an example command prompt entry running from the application 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=Nuke13.2.exe
On a macOS render machine, an example command prompt entry running from the application directory might look like this:
./python ../Resources/pythonextensions/site-packages/foundry/frameserver/nuke/runframeserver.py --numworkers=2 --nukeworkerthreads=4 --nukeworkermemory=8096 --workerconnecturl=tcp://bob:5560 --nukepath=/Applications/Nuke13.2v4/Nuke13.2v4.app/Contents/MacOS/Nuke13.2
In the examples, we specify that the render machine uses two Nuke workers, with four threads and 8 GB RAM each, and are linked to the main Nuke Studio workstation running on bob.
Tip: If your render 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 render machine 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 render machine 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.FnNsFrameServer 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 render machine, 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.
Frame Server Logs
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
