Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Handle growing SystemUIServer memory usage System
iStat is a great program for keeping track of your system by displaying menulings showing CPU usage, memory usage etc. In Mac OS X menulings (also called menu extras) are managed by a program called SystemUIServer.

iStat appears to have a memory leak where over time, the REAL memory used by SystemUIServer grows basically without bound. Memory usage that should be around 40MB balloons to 300MB then to 1.3GB over a few weeks of never rebooting. This would be bad enough if it was the virtual address space that was being used up this way, but this is real memory, causing real memory pressure and real swapping.

Obviously the ideal would be for Bjango to get on the case and fix this bug. Since they appear unwilling to do so, I have come up with a workaround.

The following facts are relevant to the workaround.
  • A separate copy of SystemUIServer runs on behalf of each user, owned by that user, when the user has a GUI login. This is very convenient because it means we can kill this program without requiring passwords and suchlike.
  • SystemUIServer appears to have been very nicely cordoned off by Apple from the rest of the system so that you can kill it at any time and nothing bad happens. The menulings all disappear, then launch restarts SystemUIServer, and the menulings all reappear (in a much smaller memory environment).
  • So the simple one-off solution to the problem is to type in Terminal:
    killall SystemUIServer. And this works, but only once --- you will need to do it again in a week or so.
  • The possibility I chose is to have launchd execute this command once a day, at a time when I'm probably not using the machine, namely 4:00am. (If your machine is asleep at that time, launchd in Snow Leopard performs the task when the machine is wakes up, and this works out OK --- we see just one more flash in the UI as the menulings are killed then restart, to accompany the various other flashes in the UI that occur when a wake occurs.
To make this all happen is not too hard. You need to create a launchd script, I called mine my.SystemUIServer_cleaner.plist, and populate it as follows:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>my.SystemUIServer_cleaner</string>
  <key>ProgramArguments</key>
  <array>
    <string>killall</string>
    <string>SystemUIServer</string>
  </array>
  <key>StartCalendarInterval</key>
  <dict>
    <key>Hour</key>
    <integer>4</integer>
    <key>Minute</key>
    <integer>0</integer>
  </dict>
</dict>
</plist>
Put this in /Library/LaunchAgents, and make sure it is owned by root:

cd /Library/LaunchAgents
sudo chown root:wheel my.SystemUIServer_cleaner.plist


This file will only be noticed by launchd and kick in automatically when you logout then login again. If you don't want to do that, but do want it to start working right away, you can manually tell launchd about it using:

sudo launchctl load /Library/LaunchAgents/my.SystemUIServer_cleaner.plist

[crarko adds: I haven't tested this one. This would be applicable to managing runaway SystemUIServer memory in general if you observe it, and not just for iStat. It's also a good example of a simple launchd script.]
    •    
  • Currently 3.60 / 5
  You rated: 5 / 5 (10 votes cast)
 
[23,454 views]  

Handle growing SystemUIServer memory usage | 18 comments | Create New Account
Click here to return to the 'Handle growing SystemUIServer memory usage' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Handle growing SystemUIServer memory usage
Authored by: sfgecko on Sep 20, '10 09:55:13AM

are you sure it's not another menubar app (e.g. google notifier) that is causing your systemuiserver process to leak memory?

i use istat menus 3.05 and my mac has been up for nearly 3 weeks (never sleeps) and systemuiserver is only 150MB. i have 6 other apps that run in the menubar as well, so 150MB doesn't seem unreasonable. it's second only to kernel_task in terms of real memory usage by the system.



[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: dilvish1984 on Sep 20, '10 11:09:22AM

I'm also not seeing this memory leak with iStat v3.05 -- I'm wondering if the original poster actually submitted this as a bug report to them? They have a nice web form for contacting them at:

http://bjango.com/contact/

I mentioned this thread to them using that web form so maybe someone from Bjango will show up here to comment...

Edited on Sep 20, '10 11:10:37AM by dilvish1984



[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: ctwise on Sep 20, '10 12:10:11PM

I'm seeing the same behavior. My SystemUIServer was at 1.5 GB (that's not a typo, GB) this morning. It probably depends on which menubar widgets you're using. I have network, CPU, date, disk and battery running. I haven't tried mix and matching to see which might be causing the problem.



[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: PhotonPanda on Sep 20, '10 10:23:41PM

I have seen this memory leak when I was using 2.x. I fiddled around with the various monitors to try and figure things out. It's not enough to just use or not use some of the monitors. For example, the rate of leak (if it happens for a particular monitor) can be different depending on the display style you choose for that particular monitor. i.e. Using a percentage display for CPU vs using the history histogram.

Since going to 3.x I have not seen the leak no matter which style or monitors I use. The computers used for observation are on for as long as possible - years if possible, but with some scheduled down time.



[ Reply to This | # ]
Thanks!
Authored by: CarlRJ on Sep 20, '10 10:22:11AM

I haven't tested the LaunchDaemon, but I have little doubt it would work -- I found this page googling about SystemUIServer and memory usage, and can happily report that "killall SystemUIServer" does indeed (temporarily at least) solve my problem.

I had been a little suspicious of iStat Menus (which I'd rather not forgo -- too useful), as it was the only non-Apple thing I saw referenced in SystemUIServer's open files list in Activity Monitor.

Thanks, name99, very much, for doing/presenting the research that SystemUIServer can safely be killed (and will auto-restart), as I was not looking forward to having to restart my MBP occasionally just to get SystemUIServer to release its excess memory.

And I was a little astonished to find precisely the answer I needed, written up on the very morning I went looking for it. BTW, I also came across Tuning Mac OS X Performance, which suggests that 3rd-party menu extras are top suspects in excess CPU usage by SystemUIServer as well:

Third-party menu extras that use an active Internet connection can result in very high CPU usage if the network connection becomes busy or blocked. The chances of this increase if you are simultaneously using streaming media and a menu extra that requires an Internet connection.


[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: rwmitchell on Sep 20, '10 11:06:47AM

When iStat Menus 3 first came out, I tried it and then subsequently noticed my machine became very boggy within a few days. A reboot (I know, barbaric) would fix the problem temporarily, but it would return. I reverted back to iStat Menus 2 and the problem went away.

I've been watching the updates to see if they have fixed any performance issues that would be related but haven't seen anything.

Your problem and fix sounds like the same thing, but my trial version of 3 has long since expired.



[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: usunoro on Sep 20, '10 03:17:09PM

With the latest version, I've had no problems with memory usage. I'm using the clock and calendar widget, load widget, temperature and network usage widgets. Currently using 48.5MB real memory, and 78MB virtual memory. I've not noticed it slowing anything else down either.

---
-- Usu



[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: boredzo on Sep 20, '10 05:10:08PM

Obviously the ideal would be for Bjango to get on the case and fix this bug. Since they appear unwilling to do so,

Did you report it to them, name99? Not everyone leaves their computer running for weeks without rebooting.

Don't forget to send them evidence that the leak is from iStat Menus, not one of the built-in menu extras or another third-party SystemUIServer plug-in or application's status item. Just because you're seeing a leak doesn't mean they would be.



[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: postglock on Sep 20, '10 06:46:29PM
Just to let people know, an open-source alternative to iStat is MenuMeters. Not sure if it's better or worse (I find it excellent), but it is free.

[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: tokai on Sep 21, '10 02:20:48AM

I currently have a 28 days uptime; and the SystemUIServer requires 8.14 MB. (960MB virtual memory are assigned to it, but that value strongly depends on the free space you have on your system drive; and I have a lot free there).

I don't use iStat, obviously.

Perhaps you should try an alternative, like MenuMeters.

---
http://tokai.binaryriot.org/



[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: TheFLP on Sep 21, '10 10:07:30AM

I, too harbored deep suspicions about iStat 2's resource usage, but version 3 seems to be much better behaved, so I have no regrets paying for the upgrade.

(OTOH, I have 8GB of RAM now, so I'm less likely to notice these problems, even with a few dozen tabs open in Chrome, plus Safari, Mailplane and Firefox, not to mention my VMware XP machine running all the time. The thought of a 16GB iMac makes me drool.)

My current uptime is 36 days and SystemUIServer is using only 53MB of real memory, which seems reasonable with all the other menu thingies I have (it's a constant struggle weighing their relative merits against available screen space). But I'll keep this hint in mind if I see it creeping into the stratosphere. I like easy fixes. :)

Now, if only kernel_task could be reset without disrupting the whole boat...



[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: foomanchu99 on Sep 21, '10 11:55:53AM

I ran into the same problem a few months ago. I noticed that my laptop wasn't waking, and I would resort to power cycling my unit. I let my unit sit for a couple of hours with the lid open, and the OS finally came back. I found SystemUIServer taking huge amounts of resources in Activity Viewer.

What worked for me was to: put my unit in target mode, mount it on another computer, and remove all of the cache contents. I removed:

rm -rf /Volumes/My\ Laptop/System/Library/Caches/*
rm -rf /Volumes/My\ Laptop/Library/Caches/*
rm -rf /Volumes/My\ Laptop/Users/username/Library/Caches/*

I'm assuming there was some corrupt data in cache SystemUIServer was gnawing on.

YMMV



[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: name99 on Sep 21, '10 03:49:02PM

Some people have complained about my blaming iStat menus for this. Let me say:

(a) I love iStat menus. If I didn't I would just disable it.

(b) Although I aggressively report bugs (I expect Apple are sick of me) I personally have not reported this one to Bjango. When I was doing research on what SystemUIServer did, and why it was growing so large on my machines, I saw many reports of iStat menus, dating from a long time ago; and I figured that Bjango simply knew about this. Fair enough, it's a big internet, so I will submit a bug report to them.

(c) Is it fair to blame them? Like most people, I'm not really in a position to track this down scientifically --- that's the problem with bugs that take many many days to manifest themselves. I don't use any 3rd party menulings apart from iStat. so it's either them or Apple.

Of course it COULD be Apple, but that seems the sort of thing Apple would catch internally, not necessarily from formal testing but just from engineers noticing huge SystemUIServer memory usage on various machines (home machines, work machines, spouses machines). Back when I worked at Apple, for example, I'd certainly write up a bug for anything unexpected I saw on a machine, my own or someone else's.

As for reproducibility, I have a very customized version of iStat, in that the display of pretty much everything has been changed from the default way Bjango has it set up. It is certainly possible that it is only if you use CPU display with custom colors AND aggregating CPUs (or whatever) that the bug is triggered, which is why some people don't see it.

(d) I used MenuMeters before iStat Menus, and found it did the job, but iStat Menus is substantially richer in what it displays, and I have come to really like having easy access to the info it presents.



[ Reply to This | # ]
Handle growing SystemUIServer memory usage
Authored by: koen on Sep 22, '10 05:24:20AM

Does anyone know if this memory leak is also present in the iStat dashboard widget?



[ Reply to This | # ]
Bjango are working on it
Authored by: theosib on Sep 22, '10 10:06:32AM

Regarding the comment implying that Bjango are unwilling to fix this, I understand your frustration, and there are a lot of companies that have really poor customer service, don't fix bugs, and don't respond to emails.

This is not the case for Bjango. I contacted them about this bug. They very quickly responded and explained that they are aware of it and working on it.

There are LOTS of companies out there with good customer service. Bjango have always responded to my inquiries. Another good company is the Omni Group. Also, Crucial and Kingston. How about Apple (when you have AppleCare anyhow). Newegg, and even Amazon. On the other hand, I'll never again do business with OCZ or MSI, and I avoid Chase (the bank that handles the Amazon VISA card) like the plague.



[ Reply to This | # ]
Bjango are working on it
Authored by: Marc Edwards on Sep 22, '10 07:33:59PM

Thank you.

We're definitely watching this one closely and we've been in contact with name99 to see if we can get some more info. There were some memory issues in older versions of iStat Menus. Version 3 fixed quite a few bugs and memory handling. We don't have any known memory leaks in version 3, but we're doing what we can to investigate to be sure everything's ok (and if it's not, we'll make every effort to fix any bugs).

Also, thanks for mentioning us alongside other great companies like Omni, Kingston, Apple etc. There is definitely one way we're a little different: We're smaller than all of those companies. That means we're very agile and if you receive a reply to a question, it's either from our full time support person or from one of the people building the app (please be nice, we do everything we can to make great apps!).

On a side note, iStat Menus 3.1 will be released in the next few days. As always, any bug reports are welcome: http://bjango.com/contact/



[ Reply to This | # ]
Bjango are working on it
Authored by: mike666 on Sep 27, '10 01:21:21PM

I've twice reported a similar iStat 3 issue whereby the WindowServer process would gradually start eating up CPU cycles within a day after booting and I've had not a single response. The little bug report form doesn't look like it would be able to handle pasting in my entire system.log so I was hoping someone at Bjango might actually request that or any other pertinent files via email. Considering that I gladly paid for the functionality of this app and that it has been pretty much useless since, I would appreciate at least being given the opportunity to help the developers nail down the issue that's affecting my system.



[ Reply to This | # ]
switching from i$tat to free MenuMeters might fix the problem
Authored by: justjim on Sep 22, '10 02:02:23PM

I used to use iStat, but switched to freebie MenuMeters and have been VERY pleased. Seems to show everything that iStat showed; doesn't seem to have any hidden gotchas that need such work-arounds. And it's free. :-)



[ Reply to This | # ]