I've seen permission issues with the Nuke cache causing freezes such as this. Nuke defaults the cache in /var/tmp on osx which is owned by root/wheel and typically defaults to 755. You might be having similar issues on linux?
I would move it somewhere else and make sure the permission are kosher for the user. On Thu, Mar 10, 2016 at 1:44 PM, Marten Blumen <mar...@gmail.com> wrote: > Initial testing shows that the 1 cpu lockup for 40+ sec is fixed by > removing the 'tilecache' folder that the RotoPaint node creates and uses. > > For example a 'bad' tilecache directory had 285K items in it, the new > 'tilecache' folder that is created automatically works perfectly. > > OsX, nuke 9.08. > > On 8 March 2016 at 07:20, Nathan Rusch <nathan_ru...@hotmail.com> wrote: > >> Something about the way node relationships are tracked and recalculated >> was changed in Nuke 9 (I think... maybe it was 8), which has resulted in a >> lot of of strange performance hits from nodes that are out of the >> evaluation tree. One of the most obvious side-effects of this is that the >> `Node.dependent()` Python method is now orders of magnitude slower, to the >> point that it's actually faster to call `.dependencies()` on every single >> node in the script and intersect their inputs with a given node to find >> downstream nodes. >> >> I've also got an outstanding bug related to all of this performance >> stuff: Bug 50719 - 3D system causing UI lockups on upstream nodes >> >> -Nathan >> >> >> *From:* Daniel Hartlehnert <dah...@gmx.de> >> *Sent:* Monday, March 07, 2016 4:04 AM >> *To:* Nuke user discussion <nuke-users@support.thefoundry.co.uk> >> *Subject:* Re: [Nuke-users] Nuke locking up with 1 cpu busy >> >> I understand. But i have seen it when opening standard grade or merge >> nodes. These definately didn’t have expressions on them. >> >> >> > Am 07.03.2016 um 09:48 schrieb Ben Dickson <ben.dick...@rsp.com.au>: >> > >> > The expressions can be in unobvious places, like inside gizmos. >> > >> > The bug Elvis Au mentioned sounds similar to "Bug 35703. Expressions >> force tree to validate unnecessarily, when changing unrelated parts of the >> tree", which I reported as such: >> > >> > On 06/05/13 20:24, Ben Dickson wrote: >> >> Attached another example, which doesn't involve the RotoPaint: >> > > >> >> The ImagePlane gizmo (available from Nukepedia) contains an "width" >> >> expression in a crop. This combined with the motionblur option in >> >> the Card3D causes the same UI sluggishness >> > > >> >> Adjust the slider in the Keyer node, or try and type something in a >> >> label - it is noticably laggy. >> > > >> >> If the motion blur is setting is set to 0, it is much quicker. >> > > >> >> The UI slowness gets progressively worse the more copies of the >> >> ImagePlane there is, to the point the comp was not workable.. >> > > >> >> I haven't tested in older versions, but this behaviour would very >> >> much explain many of the slowdowns we have experienced in the past.. >> >> Especially because we automatically create a Crop node above our >> >> Write nodes, and this contains input.width and input.height >> >> expressions (to prevent writing out EXR's with oversized bbox) >> > > >> >> It seems like a relatively serious bug, as it will exacerbate any >> >> inefficiencies in any nodes - worse as it can be very hard to track >> >> down as the cause of a slow script.. >> > >> > Attachment was essentially this script: >> > https://gist.github.com/dbr/2f3faff433d59f58be7d >> > >> > Reported for 7.0v5 in 2013 - but remains same in all current Nuke >> versions. >> > >> > Some variant of this is usually the cause of a majority of "my script >> is slow" complaints I've seen here - some slow node is upstream of a >> time-based node (TimeEcho or lots of TimeOffset's, transform with the >> "motion blur" setting enabled, ScanlineRender with many motion subsamples >> etc) >> > >> > The only way I have found to narrow it down is to delete half the >> script, see if it speeds up or not, then repeat (using the Keyer slider as >> a good way of checking - it's easy to see if the slider control tracks >> quickly with the mouse cursor or not) >> > >> > This doesn't exactly sound like the original problem Daniel described >> (particularly "i can sometimes work in the same script for hours, then >> suddenly the symptons start to show up"), although it can be made sometimes >> seem quite random if the slowness is in part due to network file access >> slowdowns. >> > >> > Something similar also happened with a script containing a lot of >> ReadGeo nodes loading Alembic .abc geometry with a relatively complex scene >> hierarchy. >> > >> > >> > On 07/03/16 18:34, Daniel Hartlehnert wrote: >> >> @Lucy: >> >> another question though: if it really is the expressions that are >> >> causing this. how is it possible that nodes that do not have >> expressions >> >> in them are causing this behavior? >> >> Thats the way it was happening for me. I have scripts with many >> >> expressions in them, but even opening nodes that have none may cause >> the >> >> freeze. >> >> Oh and sending you a scrlpt is unfortunately not possible. NDA reasons >> >> and its not really reproducable. >> >> >> >> Daniel >> >> >> >>> Am 04.03.2016 um 17:39 schrieb Lucy Wilkes <l...@thefoundry.co.uk >> >>> <mailto:l...@thefoundry.co.uk <l...@thefoundry.co.uk>>>: >> >>> >> >>> Hi Daniel, >> >>> >> >>> I've answered on your forum thread. I also wondered whether >> >>> expressions might be causing this >> >>> ( >> http://community.thefoundry.co.uk/discussion/post.aspx?f=189&t=120025&p=1008064 >> ). >> >>> >> >>> If you have a script and repro steps, please do send them in to our >> >>> Support team so that we can take a look. >> >>> >> >>> Regards, >> >>> Lucy >> >> >> >> >> >> >> >> _______________________________________________ >> >> Nuke-users mailing list >> >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> > >> > -- >> > ben dickson >> > 2D TD | ben.dick...@rsp.com.au >> > rising sun pictures | www.rsp.com.au >> > _______________________________________________ >> > Nuke-users mailing list >> > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
