Whole computer slows to crawl while FCPX processes
Hi, I'm having a new problem where Final Cut Pro X 10.4.7 Build 354449 is grinding my system to a halt. It seems to start after working in the app for a bit, for example I opened and Shared to youtube three 1080p projects no problem, the 4th one everything slowed right down. Cursor movements became very choppy, all other apps and actions on my Mac take 5-10 seconds between clicks. I notice the same occurs when FCPX has a background render task going on, basically have to sit and wait for final cut to finish whatever it is doing before I can use the computer at all. This is new behaviour.
In the Activity Monitor app on the Memory tab, FCPX app is using nearly 90gb of memory, even after any tasks I've been waiting for have finished. Other data from that tab are: Memory Used: 20.04gb, Cached Files: 3.13gb, Swap used: 13.91gb... when I close and reopen FCPX the memory column in the Memory tab now says 685mb with the same library open.
It's almost like the memory isn't getting dumped after it's data is no longer needed, just keeps building and eventually the whole system is molasses.
This has been happening since updating to build 354449 a week or two ago... I even uninstalled the app and preferences etc. and reinstalled. Tried clearing preferences via startup keyboard command. The machine is a new MBP 10.14.6 Mojave with 32gb ram and the vega 20 card, 4tb ssd with lots of space, and the top 8 core chip available. The library and footage is on a usbc raid 0 external drive. Before upgrading FCPX to this build, everything was flying... with the same computer, external drive, library, project, events, etc., now.. not so much.
I'm not seeing anyone else complaining about this regarding build 354449 so I'm suspecting it's a local issue. Does anyone have recommendations on further troubleshooting steps i can take?
Do you have all background processes in FCPX Prefs turned off?
BTW build 354449 is just the regular release version of 10.4.7. It can be seen inside version.plist inside Final Cut Pro.app. I am running that on Mojave 10.14.6 on a 10-core Vega 64 iMac Pro, and so far it runs fine. Certain aspects are considerably faster than 10.14.6, esp GPU-related items.
Are you running Chrome? That can negatively impact FCPX behavior, causing extreme slowdowns and crashes.
The Activity Monitor, the parameters "Memory Used", "Cached Files", etc are global, not per process. To see how much memory FCPX is using, double click on Final Cut Pro in Activity Monitor. That will show real, virtual, shared and private memory.
Another possibility is you have a plugin which is misbehaving and causing a memory leak.
You mentioned you exported three projects with no problem but the 4th one caused it. What if you duplicate the project, open it, select all timeline clips with CMD+A then strip out all effects by doing Edit>Remove Effects. If you then try to export that project without effects does it work?
To the previous poster... I do not have background render turned off (assumed it was on for good reason)... but in my quick tests turning it off instantly has a positive effect. Will have to toggle that back and forth as I keep working to confirm.
@Joe Marler thanks for the info... didn't realize this build is thee build. Does this mean there aren't multiple builds per app version? ie. the next time the build changes we will move up a version to 10.4.8?
Thanks for the Chrome tip; I tossed Chrome after years of usage just one month ago for it being a general resource hog all the way around (plus the privacy problems didn't help its case).
Re: Activity Monitor... I was aware that the Used, Cache, etc. were global... that's why I also posted the value in the FCPX Memory column... at +90gb and climbing it seemed out of sorts with the global values. However, I think I now realize that value is referring to total data processed by the app... so +90gb and climbing shouldn't have made me think it was a problem. That was my misunderstanding. There was never any red or orange in the Memory Pressure readout so I don't think it was a RAM issue now, but I'll keep an eye one that.
Your point about the plugins is something I hadn't looked into. The only plugin I have is the Coremelt Everything Bundle (SliceX/TrackX etc)... they sent me a dropbox link to an unreleased version 507 'a' on Sept. 25, but I see now they have a new version out as of Oct 11. on their website 507 'n'.... wow, 'a' to 'n' sounds like lots of versions in a short time! Anyway, I'll try this new version too.
Let me see if these few changes make a difference... thanks for all the help!!
[Dave Smith] "... I do not have background render turned off (assumed it was on for good reason)... but in my quick tests turning it off instantly has a positive effect. Will have to toggle that back and forth as I keep working to confirm."
I suggest you leave it off, delete all cache files, then do a one-time render of the timeline via CMD+A to select, CTRL+R to render. They will gradually become unrendered as you edit. Then (only when needed) you can manually re-render. When background render is enabled, FCPX does not delete the old render files and they can build up, taking space and apparently causing some overhead.
[Dave Smith] ...Does this mean there aren't multiple builds per app version? ie. the next time the build changes we will move up a version to 10.4.8?
Yes in general there are not multiple builds for the same app version, at least once it's released. If you were a beta tester maybe that's different.
[Dave Smith] There was never any red or orange in the Memory Pressure readout so I don't think it was a RAM issue now, but I'll keep an eye one that.
That is a good thing to check. In general it implies there is no out-of-control memory leak.
[Dave Smith] "...The only plugin I have is the Coremelt Everything Bundle (SliceX/TrackX etc)... they sent me a dropbox link to an unreleased version 507 'a' on Sept. 25, but I see now they have a new version out as of Oct 11. on their website 507 'n'.... wow, 'a' to 'n' sounds like lots of versions in a short time! Anyway, I'll try this new version too..!"
It is very difficult if not impossible to easily and quickly verify what version of CoreMelt utilities you have. The version number listed within plugin UI can be different from the version number on their download page. Your only recourse is download the latest version. CoreMelt is trying to improve this.
This is a major issue since plugins run within the FCPX process context. Misbehaving plugin code can crash or destabilize FCPX, yet developers do not have the same testing resources Apple has. Ideally plugins should be sandboxed in another process but there are architectural and performance factors which make this difficult.
It is further difficult for developers because there are no Apple standards or UI guidelines for stating version numbers in a plugin. IOW there is no plugin equivalent of Help>About in macOS. In the real world this is significant problem but you don't see things like this discussed at WWDC or listed on top 50 needed FCPX improvements.