Had a bit of a weird problem yesterday when the WindowService process was eating up 22+GB of RAM, which was particularly interesting since my M2 MBA only has 8GB of RAM. I've been manually checking off and on all day, and it's been creeping its way back up (currently 5+GB) in a way it never did before upgrading to macOS 15. So I want to write a macro to check on it periodically and send an alert notification to reboot before it goes ludicrous again.
My first thought was to use a shellscript ps x -o vsz,command | grep WindowServer, but I don't know if I'm going crazy or what. The vsz keyword is supposed to output the And I've just realised the likely problem after rereading the man ps page. The vsz keyword returns the virtual size in KB, which probably explains the discrepancy I was about to describe between the shellscript output and what was reflected in Activity Monitor. But either way, I'm still stuck on how to proceed. If I can get the memory usage for the process by (actual?) size, then finishing the macro should be relatively straightforward and just have it trigger every few hours or so. I'm just not sure how to get at that data. Though maybe there's a better way to keep an eye on this process that I haven't considered?
In your last screenshot, the number 83216 and the name of the WindowServer process are visible. Isn't that what you wanted? Before you added the -a option, that information wasn't displayed.
No, I don't think I need the PID for anything (not yet at least). I'm trying to get it to return the actual size of the ram it's eating as opposed to the virtual size, and I would've thought rss would do that, but it doesn't seem to want to show anything like vsz does. Oh wait, that isn't the PID...is that what I want? Oh, hm, no I don't think it can be the size of the RAM being eaten. It doesn't correspond to what's shown in Activity Monitor.
If you remove the "grep" from your command, and look at the headers on the output of your ps command, you will see that the first number is labelled RSS not PID. E.g.,
The activity monitor is reporting virtual memory, I think, not physical memory. I wouldn't expect the two values to align. Maybe if you replace RSS with VSZ they might align.
Oh, I didn't know Activity Monitor reports virtual memory. And I started out with VSZ, but the values didn't match then either. The man page says VSZ gives total virtual size in KB, right? Now admittedly, I'm terribly sleep deprived today, but I don't think 410733024KB = 6.24GB.
Also apologies if I've confused the matter since we've just gone in a circle; just for clarification I'll reiterate what I'm trying to do: I want to grab the total RAM (size in GB/MB/KB/whatever-is-fine) being consumed by the WindowServer process so I can have Keyboard Maestro send me a notification if it goes above a certain amount so I can safely close all my work and reboot my machine. My first thought was to use a shellscript, but maybe there's a better/easier/just-another way?
To me it seems obvious that it must be virtual memory, because the values are often larger than my physical memory.
Well, that's another problem. Memory is a complicated subject nowadays, because there are so many different measures of it. It's no longer just virtual and physical.
That sounds reasonable. Based on what you've said, I would just recommend that you just schedule your Mac to reboot each night. This would be much easier and solve the problem rather than notify you of the problem.
By the way, that process you are dealing with gets cleared/reset every time you logout/login. You don't actually have to reboot.
This is my first experience seeing (or noticing maybe) the reported RAM usage being higher than my physical memory, but then again I don't spend much time in Activity Monitor. Even when I'm in btop, it's almost always to drill down on specific processes.
Unfortunately, rebooting every overnight isn't ideal for me. A daily reboot at another time may end up being the necessary solution though, which is a little frustrating because this was never a problem before Sequoia (though upgrading to Sequoia turned out to be necessary to resolve an even worse bug—very fortunately I didn't need to format the disk and do a fresh install). Obviously all of this is out of our control, I just wanted to have a little grumble about OS bugs. Although it didn't start happening immediately after the upgrade, so it seems odd that it should happen randomly yesterday. Perhaps it will resolve itself randomly as well. It being odd was another reason I would've liked to keep tabs on it with a macro, but c'est la vie. Maybe I'll keep watching it with my actual eyeballs for a day or so, just to see.
Ignore the headline number. Is WindowServer's memory usage actually a problem? If you double-click the WindowServer entry in Activity Monitor, what's the "Real Memory Size"? And while you are looking at Activity Monitor, how's the "Memory Pressure" and does that increase as WindowServer's headline number increases?
If you do want to monitor a number -- as @Airy says, look at "real memory" (rss) or even percentage use (%mem).
IMO, you're better off trying to find out which app is causing WindowServer's "excessive" (if it actually is) memory usage. It might be an OS bug, many people have reported such over many OS versions, but it's more likely to be an app -- or even a particular web page -- and the way it interacts with WindowServer.
And more than likely, there's nothing you can actually do about it, short of rebooting for the benefit? of seeing lower RAM figures.
Over the years, the OS has gotten ridiculously good at managing RAM. I used to watch RAM usage intently, even had a couple of macros to alert me to things. But that's because it used to cause horrendous issues.
Now? For the most part, the OS just handles it. Even on an original M1 laptop with 8GB, I could open more apps than I ever would have thought possible without any noticeable slowdowns. On the 16GB laptops now? I don't even think about RAM usage. If the OS is telling me it's using 2TB of RAM with 1.8TB of that being virtual, even though I only have a 1TB disk, I don't care—as long as the OS is doing what I want it to do, that's all I care about.
So I've learned to stop worrying about the RAM details and just let the OS do its job. The only time I care—and I haven't had to care in quite a while now—is if the OS starts to feel slow or out of sorts. Then I'll take a look at Activity Monitor to see what's up. When I do, RAM isn't usually the issue, but some process that's decided it needs 100% x 6 CPUs.
The improvement in memory management in macOS over the years is one of Apple's better accomplishments. Now if they could just apply that same focus to annoying, long-standing UI glitches and issues………………
The Mac prompted me several times in succession with the Force Quit Applications window telling me that it was out of RAM and to close some apps. Usually when this happen, Firefox is the main culprit using several GBs of RAM, but this time the Mac prompted me again that was out of memory. I quit Firefox again, even though it usually takes some decent time before it becomes a problem for the RAM again. When it prompted me again that it was out of RAM, I quit everything and opened Activity Monitor to see what was going on. That's when I saw WindowServer being wild.
You know, I never knew you could double-click on processes in Activity Monitor...this makes what was reported in Terminal make so much more sense. Memory pressure is currently above 65%—I want to say it isn't usually that high, but I'm not actually certain because I don't usually look at that. What even is the number Activity Monitor in the headline? It doesn't seem to correspond to anything, which makes me wonder what use it is.
I'll try, but I'm not using any new programs, and I don't think any of my daily-use apps have been updated recently. Maybe there's a rogue webpage somewhere like you said. When I'm able to, I'll start by closing all tabs and windows in Firefox and start from scratch and see if that has an effect.
I don't tend to worry about RAM, but this problem was weird and seemed to come out of nowhere, which is why I wanted to try to keep an eye on this process. The way I work means I do hit the walls of my 8GB somewhat regularly, but as I mentioned it's usually enough to close Firefox for a minute. I almost never have RAM issues on my Intel MBP with 64GB of RAM, but it often sounds like it's trying to take flight.
Thanks for all the info and suggestions, everyone!
Last year when I had an 8 GB Mac, I had memory problems like yours at least once a week. Now that I've upgraded to a 24 GB Mac, the problems are less than one per month. Sometimes the issues were with the WindowServer app, sometimes they were with the KM Engine, and sometimes a different mac app.
This is fascinating, as I've not had a memory issue in so many years, even when I had an 8GB machine. However, perhaps related is that my main Mac hasn't been 8GB in many years, and I don't push the laptops as hard as I do the desktops, as I work at home and use the laptop only when traveling (and for testing).
That's not unusual for a device with only 8GB of RAM.
It's kinda-sorta "memory footprint of the app". AFAIK that doesn't include virtual memory, but does include private, shared (recorded against every app that shares it), and real and is the "uncompressed" value. Honestly, it's pretty meaningless -- at least to us mere mortals!
The things that really matter are memory pressure and, obviously, out-of-memory alerts. The latter are usually caused by some process gone rogue when, even if you quit that process, the memory isn't properly de-allocated (perhaps because it is shared with other processes? Just a guess) and you have to quit any other "associated" processes as well -- and WindowServer is associated with just about anything with a GUI.
So, on to the (hopefully!) useful bit...
If memory pressure is the best indicator of overall memory "health" and can be used to warn of pending disaster, let's use that. Luckily there's the (surprisingly well-named) memory_pressure command which gives that value as the last line of output -- albeit as the "free percentage" so we'll have to inverse it. Long form, with guessed-at alert boundaries:
So you could, for example, set that on an "every 5 minutes" periodical trigger (disabling the "everything's fine" alert). Add an action that logs the memory pressure to a file every time and you'll have record that could be useful in troubleshooting the actual problem...
