adobe-photoshopmacosmemory
I'm running Adobe Photoshop CC on a Mac with 32GB RAM. I have no performance issues other than Perspective Warp. Sometimes it works immediately, sometimes after a few seconds (while I wait for the revolving rainbow wheel to stop spinning) but it seems to take longer each time I use it within a session – eventually generating an 'out of application memory' message and freezing Photoshop. Restarting the Mac usually resets the function.
Can anyone help, please?
Complementing other answers …
Mac OS X: How to start up in single-user or verbose mode
– if you start in verbose mode, then restart or shut down will be similarly verbose.
Hint: if things in verbose mode seem to not progress beyond a certain point, allow maybe five minutes before either:
If a forced restart does not succeed, that could be another clue to the cause of the problem(s).
A related question, albeit not problem-oriented: Can anyone interpret verbose shutdown messages?
The problem-oriented case here should be easier to resolve for lupincho. Fewer tea leaves.
A preference can be stored in NVRAM. Enter the following command in Terminal, and be prepared to enter your admin password:
sudo nvram boot-args="-v"
The next start of the system will be verbose.
Before each restart or shutdown, in Terminal:
sudo sysdiagnose
It's time consuming, but you need not investigate the results of all runs. Pay attention only if a problems arises.
For a case such as lupincho's:
sysdiagnose may reveal a problem before a restart or shut downMore specifically: if a run of sysdiagnose fails to progress beyond a certain point, knowing that point can help to gain a sense of the underlying problem.
During the run you can use the following key combination, repeatedly, to see whether things are progressing:
For the allmemory part of the sysdiagnose routine, Apple's two minute estimate may be wildly inaccurate. Be patient.
If you suspect that sysdiagnose fails to progress beyond a certain point, then key:
If repeated use of Control-C fails to abort sysdiagnose, then (in my experience with Mountain Lion) it's almost certain that an attempt to restart or shut down the operating system will fail.
In Finder, go to:
/private/var/log/shutdown_monitor.log
This file is typically empty, but may contain items of interest following a problematic shutdown. (I have little experience in this area.)
It's not unusual to have stray processes at shutdown. A stray can be problematic only if it is not killed.
If you suspect that WindowServer is not killed, and that this particular stray is contributory to shutdown failure: ask yourself whether any third party software makes nonstandard use of the WindowServer process.
Quick Look of a GrabFS view of WindowServer on Mountain Lion, with two displays:
If Lion is similar, then my gut feeling is that the cause of shutdown failures lies beyond WindowServer.
Whilst the machine is running normally, what response to the following command?
sudo launchctl list | grep --invert-match com.apple
Wonder whether any non-Apple software is contributory to the problem. Anti-virus, anti-malware software?
Aim for:
/private/var/log/com.apple.launchd/launchd-shutdown.system.log
It seems the default is one log per shut down, with a maximum of two so there's also:
/private/var/log/com.apple.launchd/launchd-shutdown.system.log.1
Following any forced restart or forced shut down, you might choose to set aside a copy of the most recent of the two. If force is required on any more than one occasion, you can compare files to see whether a pattern emerges.
Don't rule out the possibility of an issue with third party software, even release quality. Little Snitch may be well written and widely respected but:
I tested Build 12A269 of OS X 10.8 for around two weeks before it was released, with particular attention to shut down behaviours in difficult situations. Whilst I have not watched any videos from WWDC 2012, I do have a sense that Apple has worked very hard to prevent the need for force in all but the most difficult situations.
At least on Mountain Lion, I see the load of Little Snitch 3.0 Preview 2 (3857) very early – before shutdown logging begins. If things relating to this KEXT are similarly late around shutdown time, then maybe an issue will be not evident in the usual log files on disk.
If ever you discover the cause of the problem – with either Lion or Mountain Lion – I'll be pleased to know.
In the meantime, with big thanks for the bounty, a closing thought:
kextstat -l | grep --invert-match com.apple
In my experience, this occurs when my main system hard drive is running low on free space. Operating Systems use the hard drive for extra memory storage, called "virtual memory". (I've definitely always wished that the OS could just reserve enough space for itself, but it just can't predict how many applications we'll be running).
On top of that, it's worth noting that regular web use now requires far more memory than it did in the past. In activity monitor, you'll notice that every single tab & window (every open web page) is it's own process, taking up a significant chunk of memory. On top of that, account for all the ads, movies, flash, scripts, plugins and 360 videos etc. that we expect to run smoothly. New OS's and new web pages just use a lot of memory to provide us with the services we expect to "just work" (eg. syncing across devices, notifications, automatic updating etc. etc.).
In short, in my experience there usually isn't a single process that's suddenly taking up a huge amount of memory (although a leaky program could indeed be a culprit - Sketchup 2016 does this to me, for example). More commonly, it's the additional functionality we expect of many programs/web plugins.
I believe restarting the computer always alleviates this problem for a short while - primarily by unloading all the webpages and apps we had launched over time. But if our expectation of the computer and hardware constraints stay the same (and we run the same number of processes without changing anything else), eventually we'll run into the problem again.
Two solutions that work for me:
1) Open fewer tabs/pages and fewer programs at one time. Close some web-pages/programs before opening the hefty apps, such as MS Office, Parallels, 3D CAD, Adobe programs etc.
2) Free up more space on the system hard drive (eg. move all your music and photos to another drive), to allow the system to handle your typical virtual memory needs. For me, this means my 1TB OS drive needs >20% free space (200GB)! Your requirements may be different. If you're on an older Apple laptop or iMac or Mini, the OWC Data-Doubler is a really fantastic way to accomplish this.
Method (1) is my temporary fix, so that when I eventually enact method (2) I will have restored the snappy performance I expect while running many heavy-duty programs simultaneously.
Best Answer
You don’t actually specify what model of Mac you have, nor what you mean by within a session.
However, the perspective warp function is a rather CPU and GPU intensive task. How long it takes will depend on a number of factors, such as the complexity and size of the files you’re working with, the amount of VRAM your GPU has access to, and so on.
Also, if you’re trying to use the perspective warp function repeatedly during relatively short periods of time, you may find that your system starts heating up beyond acceptable limits and the CPU and/or GPU become throttled in order to protect them from damage.
Finally, while you do seem to have a good amount of RAM (32GB is nothing to be sneezed at), the perspective warp feature is actually more demanding of the GPU and the amount of VRAM it has access to. So you may find that’s the cause of your memory issues, especially if you’re using perspective warp repeatedly within short periods.