os X server memory leaks?

Hey!

*feeling stupid*

I just broadened the activety window and it says intel to the far right. Nothing else! I'll keep watching!

🙂

Tobias

In addition to Activity Monitor there are a couple of other ways of checking that don't involve launching the app (and using up all that memory).

For GUI-based applications you can choose 'Get Info' in the Finder and it'll tell you whether it's a PowerPC or Intel app.

For command-line apps, use file:

<pre class=command>$ file /usr/sbin/httpd
/usr/sbin/httpd: Mach-O universal binary with 4 architectures
/usr/sbin/httpd (for architecture ppc): Mach-O executable ppc
/usr/sbin/httpd (for architecture ppc64): Mach-O 64-bit executable ppc64
/usr/sbin/httpd (for architecture i386): Mach-O executable i386
/usr/sbin/httpd (for architecture x86_64): Mach-O 64-bit executable x86_64</pre>

Here you can see that apache (/usr/sbin/httpd) contains 4 separate executable code bases - a 32 and 64-bit version for PPC and a 32 and 64-bit version for Intel. The OS will automatically select the optimal version for your system.

Camelot, thank-you very much for your excellent info on memory usage in OS X, it is something that's a constant source of confusion for many and I can only hope that Apple will post a support article outlining the very same (and as coherently as you do).

As for anyone using Retrospect, I can't recommend enough against it. As has been noted, that means using Rosetta and all the potential trouble that will be sure to cause. I see Rosetta as a distinctly client-oriented feature and not something I want happening on my server.

While not without it's own quirks, have a look at BRU from Tolis Group.

I've had it with Retrospect and how horribly it performs with Tape Libraries (Exabyte, via FW 800, on first a G4 then a G5 Xserve).

They keep promising a feature-match to the Windows version and I no longer believe it will ever arrive. I'll not be surprised if the Universal Binary version is a bug-ridden, ugly port of the existing core app.

Well I was about to post that not using Retrospect PPC was not the problem but I noticed a bit down the Process chain "RetroRunSL" still hanging on after my restart last night. SO I'm gonna do another set of tests and screens.
What I can say is that the RAM does not come back from "Wierd" as it should. I never launch Retrospect today and the main startup item never ran "RetroRun", SL is different. It is all in kernel_task at almost 2GB of RAM and has been like that for 9 hour next to no load on the server. Just this one little PPC Process causing all this havoc, dam. (Is rosetta a process I don't see it?) I have <80MB of RAM out of 3GB as Free, not good. My Page/Outs are still very low which is good.

Hmm. Since I've been posting and quit the RetroRunSL the kernel_task's gone down from 1.97GB (been at thaty for hours) to 1.94GB. I'd be qurious to see if it drops further but I want my RAM back, lol.

Well instead of a reboot I just played around and started launching all different Universal Apps. I only had like 100 MBs free so I wanted to see what it would do.
Well I started to free up memory. Most of It came out of Wierd was 2.27 now only 2.03GB. The most noticable change to the kernel_task Real memory was when I ran DU and repair perms. KTreal dropped from 1.9 to 1.7 slowly as the repair went on.
So anyway now I have ONLY intel process running I did not reboot and I managed to get to 500MB Free 2GB still Wierd and KT has 1.72GB real.

I can live with that so I'll leave it and look tommorow.

Retrospect will show as:

translated

And if you want to make sure no part of Retro is running, issue:

sudo systemstarter stop RetroRun

If you want to remove it permanently, remove the "RetroRun" folder from within /Library/StartupItems

I've had the memory leak problem from the moment I set up the server. For the first eight weeks, I was not running Retrospect. Recently I have been. Doesn't seem to make any difference. Also, running repair perms. does not decrease the wired ram.

Wow I was tired when I last posted !

Excuse me please ! 🙂

ROSETTA will show as: translated

And of course, Rosetta is needed only on Intel-based Macs.

Still, it's one more strike against Retrospect at this point.

Hi there

(1st post to any discussion forum ever, didn't realise I couldn't change my alias when I chose it!)

I don't know if this contributes to things or not but we recently installed OS X Server 10.4.8 Tiger (Universal installer). We are exhibiting the same behaviour where the Wired memory increases until it uses all the available RAM and then the machine crashes the next time it is asked to do something. However, this is on a PowerPC box NOT an Intel one (it's a Dual 2.5GHz G5 PowerMac with 2.5GB RAM) i.e. no Rosetta involved.

We have been using Retrospect without any problems (no increase to the Wired memory in Activity Monitor when backing up/restoring etc.). In fact we have been using file sharing and other apps on the machine without problem. What DOES affect things is file searches using the built in Find in OS X 10.4; when doing finds using it you can actually watch the red in the pie chart that denotes Wired memory in Activity Monitor increase. You just keep using Find and within two or three Finds the Wired memory maxes out and the machine dies - you can't even take a screenshot of the Activity Monitor window. Finds using EasyFind or from a PC don't cause this problem - I guess because they don't use the search indexes of the server's hard disk (is that right?).

Our 'solution' at the moment to prevent crashes is to not do Finds and to keep an eye on Wired RAM usage in Activity Monitor, restarting when it looks like maxing out (which it hasn't come near to since banning Finds) and getting the first person on day shift to restart the server when they arrive in the morning.

Hope this helps!
Neil

PowerMac Mac OS X (10.4.8) Dual 2.5GHz G5 2.5G RAM

I have also that wired memory problem, on a 3 GB Macpro. Usually, the wired memory grows up quickly to 1.15 GB then stay at this value for weeks in my usual operating conditions. I thougt it was a Rosetta related problem because I use some PPC applications, and also because applying the last Microsoft Office update almost crashes the system: 2.8G wired memory, lot of swapping, and no other solution than a reboot.
Now, as the Microsoft office upgrade installer did a lot of file search, it may well be a file search problem.
Its also clearly a server problem: the same operations (running, upgrading MS Ofiice) run smoothly on a MacosX 2 GB Macbook pro.


Macpro Mac OS X (10.4.8)

If you want to remove it permanently, remove the
"RetroRun" folder from within /Library/StartupItems

Just removing this was what I did do first and the RetroRunSH still launched. I have not done a restart since I killed the RetroRunSH since I wanted to see if the memory would return to normal. The directions are at the link below and I believe after a reboot no RetroRun* will launch preventing any PPC code from even entering the system.

http://kb.dantz.com/al/12/1/5734.html

The other Posts concerning the "Search issue" I think might be a separate issue. Since it seem to effect both PPC & Intel units. I on the other hand do not see this problem but I will do some tests.

As to my current Server state, all seems a bit better. As I posted previously I decided not to reboot last week after killing all PPC processes. Since then the kernel_task Real Mem. has dropped to below 1GB. My Free is still only about 300MB but it appears the kernel_task has let some of it go. The main chunk of memory now resides in "inactive". So something still seems to not be quite right. I'm going to reboot in a day and see if after NO PPC processes from start-up keep everything going nicely. I am pretty confident that this issues of memory on an Intel unit is related to rosetta & PPC processes. I will post a series of screen shots as soon as my testing is done.
current memory distribution:
Wired : 1.10GB
Active: 442.28MB
Inactive: 1.19GB
Used: 2.72GB
Free: 291.30MB

Well still no reboot because Inactive has seemed to free up and all looks pretty good. No PPC code running. The problem I am seeing now I can say after a week of testing is related to PPC processes running on an Intel Mac. Memory grows over time and is not reclaimed. Once I stop ALL PPC code from running. (RetroRun & RetroRunSH) the memory has seemed to be reclaimed if it ever so slowly. As of today with one week and no Retrospect/PPC code running and no reboot since having PPC code here's the before/after.

One week ago after one day of PPC code running memory distribution:
kernel_task real=1.97GB
Wired : 2.27GB
Active: 408.35MB
Inactive: 258.57GB
Used: 2.92GB
Free: 79.52MB
VM = 10.71GB
In/Out = 99668/64282

current memory distribution no reboot 8 days running:
kernel_task real=839.13MB
Wired : 1.13GB
Active: 578.82MB
Inactive: 205.63MB
Used: 1.90GB
Free: 1.10GB
VM = 12.57GB
In/Out = 392182/76832

This all reads pretty clear to me. Almost no Page Outs for a week yet 64k in one day. The 10.4.x Server search/memory problem may be something else.

Hope Retrospect 7.5 gets here soon till then off to write a cron job or something to launch Retro when needed. Anyone want to help?

Well the Search memory issue is a big one. OMG the kernel_task real memory grow by leaps and bounds. I did 3 searches with the same result. Sherlock 2-Classic, Find 10.3.9, and Spotlight. By far spotlight search caused the kernel_task to grow fastest and by the greatest amount but if i made a wider search in Sherlock 2 I could get about the same growth. It does seem to cap out but I think that has more to do with the size of the results. If you want it to max out do a really wide open search and you should top out the real memory for kernel_task.

I have taken away a lot of things. I had a problem with my domain and how different servers connected to the OD Master. When these problems escalated, it also consumed - it seams - memmory and in the end this lead to crashes.

Searching has thou also showed just this behaviour. And I have basiccaly 2 questions:

- Does it differ if the search is done on the server or from a client to a AFP share?

- It is not to bad if the usage of memmory grows during search, but does the system handle memmory back (or leak)?

/Tobias

This is a known problem at the moment and only affects the Universal version of Mac OSX Server. It is only triggered when you do a find either on the server itself or via a client. The wired memory will increase until finally loacking up the server. Apple is working on the problem which will hopefully be solved in the next update to the operating system or via a seperate patch.

Hope this helps everyone, we only discovered it when we installed the universal version on a PPC machine, we rebuilt the machine and everything was fine after opening a ticket with Apple and discussing the problems.