som6ra wrote:
I started to get the same issue after latest update.
I've installed the "memory clean" software and it shows over 3Gb of free app memory, I don't get it...
I keep getting the same issue over and over, and I constantly use the same apps with the same frequency and it never run out of app memory before.
My mac: MacBook Pro (15-inch, Late 2011)
Processor: 2.5 GHz Intel Core i7
Memory: 8 GB 1333 MHz DDR3
Storage: 256 SSD
Uninstall "memory clean" as this is NOT a RAM usage problem, it is a "Virtual Address" problem.
You either have no more disk space to create /var/vm/swapfile(s) -OR- you have a process (or set of processes) that have requested more Virtual Address space than OS X is capable of managing. Virtual Address space is a "Promise" to give you RAM the program touches that region of address space, but until then the operating system may keep the data on disk. But to keep that promise, the operating system needs tables to manage this, and those tables are not infinite, so eventually if a process asks for too much address space, the operating system will run out of table space to make the promise, -OR- it will not be able to create more /var/vm/swapfiles(s) and issue the message "Your System has run out of Application Memory".
So if you are getting these errors and you have lots of free disk space, then chances are you have a process that is trying to use lots and lots of virtual address space, and that may or may not show up as RAM usage, as any data mapped into the process address space, but currently sitting on the disk, will be taking up virtual address space, but will not be showing up as process memory being used.
And things like your program code is memory mapped directly to the program file, and a process can use memory mapped files to access files, instead of using traditional file system read/write routines. These memory mapped files will NOT affect your /var/vm/swapfile(s) usage either, so you cannot always just look at how much space you are using there either.
From an Applications -> utilities -> Terminal session you can try issuing the
ps -o rss,vsz,ucomm -ax | sort -k2
command. This will display each process' real memory (RSS), then the Virtual Memory (VSZ). The sort will be against virtual memory usage, so you will get the largest consumers at the end of the list.
This DOES NOT mean the largest consumers are at fault, as it could be a collection of processes, such as a web browser that uses lots of subprocesses to display pages, and if there are enough of them , they add up.