What does SZ on the ps output mean?
ap...@student.open.ac.uk
The total size of the process in virtual memory,
including all mapped files and devices, in pages
where on my system (solaris 8) a page is 8K.
But this does not tell me all that I need to know. I used to think
that SZ was the amount of heap storage used, as allocated typically
(but not exclusively) through malloc. But I am not sure now. I
originally assumed that no matter how many malloc and frees were done,
if they all matched and the app did not leak then SZ would not show an
ongoing upward trend. I think I need to understand more about SZ so I
have come here for help please.
Here's why I am not sure: I have a java program, a server, that uses
SWIG/JNI to talk to a C wrapper which in turn talks to a third-party C
API. I have been using ps to monitor the value of SZ over time in the
hope of spotting any memory leak. I am also using JMX via jconsole to
examine the java heap as mgd by the JVM. Jconsole tells me that the
heap is periodically GCd with a series of relatively frequent minor GC
efforts and a more major GC effort every two hours or so. It basically
says there are no leaks. But the value of SZ keeps going up. There are
fluctuations and one has to see the ps results over a 24 hour period
to see the overall trend. The trend is a slow climb of around 500
pages followed by a sharp spike every few hours of between 500 to 1500
pages. The overall effect is a definate upward trend with an average
growth of 1 MB per hour.
When I only had figures for the first hour or so and I saw a spike I
figured that because the values after the spike had gone down maybe
there weren't any leaks and any outstanding memory would be reclaimed
eventually. But the climb of SZ is relentless. It is one of the
biggest processes on the machine now and this has me worried.
Regards,
Andrew Marlow
Rich Teer
> According to man, SZ is:
> The total size of the process in virtual memory,
> including all mapped files and devices, in pages
> where on my system (solaris 8) a page is 8K.
>
> But this does not tell me all that I need to know. I used to think
> that SZ was the amount of heap storage used, as allocated typically
> (but not exclusively) through malloc. But I am not sure now. I
The man page is correct.
> originally assumed that no matter how many malloc and frees were done,
> if they all matched and the app did not leak then SZ would not show an
> ongoing upward trend. I think I need to understand more about SZ so I
Not so. Freed memory is not returned to the OS until the process
terminates, so it is quite possible that a process' memory usage
will continue to grow even though it has no memory leaks.
HTH,
--
Rich Teer, SCSA, SCNA, SCSECA, OGB member
CEO,
My Online Home Inventory
URLs: http://www.rite-group.com/rich
http://www.linkedin.com/in/richteer
http://www.myonlinehomeinventory.com
Darren Dunham
> But this does not tell me all that I need to know. I used to think
> that SZ was the amount of heap storage used, as allocated typically
> (but not exclusively) through malloc. But I am not sure now. I
> originally assumed that no matter how many malloc and frees were done,
> if they all matched and the app did not leak then SZ would not show an
> ongoing upward trend. I think I need to understand more about SZ so I
> have come here for help please.
'SZ' is an OS concept about mapped spaces.
'malloc' and 'free' are library routines that do not always directly
affect mappings. In particular, 'free' will not normally return the
now-unused memory back to the OS (there are many reasons this can be
difficult to do). Some alternate allocation libraries will try to do
this as well as possible.
You are correct that over the long term if the malloc and frees match
up, there shouldn't be an upward trend. But it is possible for
fragmentation to occur in the allocation area. If that happens, then
you lose useful space to fragmentation.
> Here's why I am not sure: I have a java program, a server, that uses
> SWIG/JNI to talk to a C wrapper which in turn talks to a third-party C
> API. I have been using ps to monitor the value of SZ over time in the
> hope of spotting any memory leak. I am also using JMX via jconsole to
> examine the java heap as mgd by the JVM. Jconsole tells me that the
> heap is periodically GCd with a series of relatively frequent minor GC
> efforts and a more major GC effort every two hours or so. It basically
> says there are no leaks. But the value of SZ keeps going up. There are
> fluctuations and one has to see the ps results over a 24 hour period
> to see the overall trend. The trend is a slow climb of around 500
> pages followed by a sharp spike every few hours of between 500 to 1500
> pages. The overall effect is a definate upward trend with an average
> growth of 1 MB per hour.
>
> When I only had figures for the first hour or so and I saw a spike I
> figured that because the values after the spike had gone down maybe
> there weren't any leaks and any outstanding memory would be reclaimed
> eventually. But the climb of SZ is relentless. It is one of the
> biggest processes on the machine now and this has me worried.
Rather than a single value, you might examine the process with 'pmap -x
<PID>' and see which particular mapping (or mappings) is growing. Of
course if it is the heap, then you'll have to do the debugging at the
Java or library level to see why the memory is continuing to leak.
--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
ap...@student.open.ac.uk
> ap...@student.open.ac.uk wrote:
> > But this does not tell me all that I need to know. I used to think
> > that SZ was the amount of heap storage used, as allocated typically
> > (but not exclusively) through malloc. But I am not sure now. I
> > originally assumed that no matter how many malloc and frees were done,
> > if they all matched and the app did not leak then SZ would not show an
> > ongoing upward trend.
> 'malloc' and 'free' are library routines that do not always directly
> affect mappings. In particular, 'free' will not normally return the
> now-unused memory back to the OS (there are many reasons this can be
> difficult to do).
> You are correct that over the long term if the malloc and frees match
> up, there shouldn't be an upward trend. But it is possible for
> fragmentation to occur in the allocation area. If that happens, then
> you lose useful space to fragmentation.
I am aware of this theorectical possibility but don't think I have
ever seen it happen in practise.
> Rather than a single value, you might examine the process with 'pmap -x
> <PID>' and see which particular mapping (or mappings) is growing. Of
> course if it is the heap, then you'll have to do the debugging at the
> Java or library level to see why the memory is continuing to leak.
Thanks for that tip. I didn't know about pmap. I see from pmap that
the heap is more or less constant at around 32 MB. I don't know what
the other entries mean. There are loads of items with read/write
[ anon]. I think these are getting bigger. What does that mean please?
Regards,
Andrew Marlow
Darren Dunham
> Thanks for that tip. I didn't know about pmap. I see from pmap that
> the heap is more or less constant at around 32 MB. I don't know what
> the other entries mean. There are loads of items with read/write
> [ anon]. I think these are getting bigger. What does that mean please?
[anon] just means that the memory isn't backed by any particular file
(it wasn't paged in from disk), and it's not part of the heap or stack.
So it's memory that that has been allocated to the process, not directly
in the heap. I see that most multi-threaded proceses tend to have quite
a number of anon mappings. I presume this is some sort of thread-local
storage for each.
I'm not a Java person, so I can't begin to suggest the best way to start
tracking down memory issues like this.