ID 235708 - Nuke caching occasionally blocks on some machines

Problem summary

On some machines rendering simple scripts utilising the maximum amount of CPUs causes some frame renders to pause for significantly longer than others.

Using the Nuke Event Graph this looks like it is caused by Iop::get and related functions, see attached images. Annoyingly the issue disappears when you run NUKE through vTune.

Steps to reproduce

1) Open Nuke

2) Create a Read node, and read in a sequence

3) Attach a Glow node

4) Playback the Viewer, on some frames the render will take a lot longer

Workaround
Changing anything that may affect the thread timing can help the issue, this includes:

Limiting the threads Nuke can use sometimes helps. This can be done by launching Nuke via command line with the command: Nuke10.0 -m 3

Depending on the system, the thread count can be higher or lower before the issue occurs.

Set the Nuke process priority in Windows Task Manager to Realtime.

Change the Nuke process affinity in Windows Task Manager to not use all the CPUs. 

Uninstalling Quicktime, and installing a different version, so from 7.7.9 to 7.7.6 for example. Quicktime 7.7.6 can be downloaded from here: https://s3.amazonaws.com/thefoundry/support/QuickTimeInstaller_7.7.6.exe

Reproduced by support

This has been reproduced on one machine:

Nuke 10.0v4 - Windows 7

Nuke 10.0v4(Custom build) - Windows 7 

Nuke 10.0v1 - Windows 7

Nuke 9.0v8 - Windows 7

Nuke 9.0v1 - Windows 7 

Nuke 8.0v6 - Windows 7

Expected behaviour
For Nuke to generate the Viewer frames at a consistent rate.

Actual behaviour
On random frames, the time to load a frame would increase massively, and the CPU would show 100% usage on all cores in the Task Manager.