Compressed memory algorithms lock up my mac occasionally

Question

Created Aug ’20

Replies 4

Boosts 0

Participants 3

This is largely a bug/feature request based upon my observed behavior of memory management on mac os x.

Since covid-19 started, I've been working from home on my macbook pro with 16G of memory. I basically use chrome all day and have a ton of tabs and windows open.

When my mac starts to slow down, I'll often just close a whole window which I have not been using for a long time.

This leads to my memory pressure on activity monitor going red for a good 20 seconds to a minute where I can not do anything.

At the moment, my memory usage is:
Physical Memory: 16 G
Memory Used: 13.57G
Cached Files: 1.37G
Swap Used 7.22G
App Memory: 7.07G
Wired Memory: 4.45G
Compressed: 2.89G (It's often in the 4G+ range)

So, what I've noticed is the following:

app memory went down to about 4G
swap used goes down to 4.5G
compressed goes up to 6.5G
memory pressure spiked to yellow (in this instance which is fine)

Then, swap goes back up to 7.7G, compressed goes down to 1.3G

My understanding of the implementation here is that an unused page of ram will be compressed in memory. That will also be swapped out to disk in compressed form if need be.

Now, when I exit my program, it can't just free up the pages used on swap, it instead needs to read it into compressed memory, and then from there return it back to normal memory which can then be freed. I'm not 100% sure on this but this is the behavior I observed and read about online.

Since I basically use my work machine as a glorified web browser, I'd like to be able to turn off compression (which apparently isn't possible anymore on catalina) so that traditional swapping to my SSD will be used. This would on average allow me to actually use 3-4G more of ram for active applications at the cost of having to swap, which is generally fine for me. I have some windows which stay minimized most of the time and I'm willing to wait for them if I need to go use them.

I'd love to hear more about how compression actually works, assuming that I'm wrong somewhere, and what next steps I'd want to take to try to get in an official feature request for changing the behavior.

Thanks,

Mike (former Solaris VM expert)

Boost

Answer 1

TyngJJ OP

Aug ’20

You mentioned using Chrome, a notorious memory hog. Have you thought about splitting your work across browsers for the sites that might be compatible?
The compression algorithm is documented in WKdm_new.h (implementations are per-architecture assembly), and you may also be interested in vm_compressor_backing_store.h

0

Answer 2

mec2 OP

Aug ’20

Thanks TyngJJ, unfortunately, using chrome is required by my work. The pointers to the code are great. I'll walk through the code and see if there's anything there which would explain the behaviors I've been observing.

0

Answer 3

Etresoft OP

Aug ’20

using chrome is required by my work

Sorry, but I have to push back on this. Are all of the sites you use non-functional in Safari? What about Safari Technology Preview? What if you enable the super-secret "debug" mode (over and above the Develop menu)?

Just saying that Chrome is "a notorious memory hog" really doesn't do it justice. As you have seen, it will bring your machine to its knees. You didn't clarify which machine you have. "MacBook Pro" could mean a 2012 machine with aftermarket SSD, or a modern machine. The old SATA SSDs max out at 560 MB/s whereas the modern, built-in SSDs reach over 3000 MB/s. If you are running Chrome heavily enough to notice memory compression, then that might make a difference. Plus, a modern MacBook Pro can be configured to up to 64 GB RAM. Hey, if you have to use Chrome, why not?

One of the big open source projects I use has a dependency on the Pdfium project, which is technically part of Chromium. That has given me a little bit of insight into how Google writes code, especially memory-management code. To put it bluntly, if you use Chrome, go for the 64 GB option. Google has no clue how to manage memory. They have lots and lots of complex C++ code to use memory, even going down to low-level page management. It would be much better if they just used built-in facilities.

Trying to hack around on your system to manage memory compression is a non-starter. Just minimize your use of Chrome. If you don't need a tab, close it. Restart your computer every day. Never use any of those "memory clean up" apps.

0

Answer 4

mec2 OP

Aug ’20

I can't seem to figure out how to reply to a specific message but this is in response to Etresoft. I have a 2017 macbook pro with 16G fo memory with 3.5GHz Dual-Core Intel Core i7. This is a modern machine with everything installed by apple.

As far as using chrome, based upon where I work, it is the only browser supported and the work specific plugins are used all of the time. I am well aware that some web based tools I use are memory hogs. That said, the behavior of the system as a whole is not acceptable under these scenarios I'm describing.

Locking up my whole machine for about 5 minutes (today) dropping my App Memory from 5.5G to 3G while swapping in data to 7G of compressed memory to then just fee it up is not OK.

I am also aware that I can have better browser hygiene, closing tabs more often ... I still claim that the choices made for compressing memory are suboptimal and that apple should be looking into this. I'll likely have to reach out to someone who works over there to discuss this with them because maybe there's something that I'm missing here.

0