On Tue, 28 Nov 2000, Peter Gervai wrote:
> Do I have anything to do about this? I don't know about using mallocs, I
> suppose oops automagically use ptmalloc then (is there any way to check
> which malloc do oops use?)
AFAIK, ptmalloc come as part of glibc, so it is used authomatically with
glibc.
>
> RSS is the actual resident size (29M), so I suppose it contains 16M data
> cache and 13M structures? Isn't this a bit big? Oops now uses 3 storages,
> 20+100+600MB, this is not that much I think.
Here is one of differences between squid and oops - its size in memory
not related to size of storages. VSZ can depend on load (requests per
second) and number of simultaneous connections in service.
Here is on low-loaded system
29382 root 35M 28M sleep 58 0 0:00.14 7.3% oops/194
10req/sec, near 100 connections, 7.5G storages
Here is heavy-loaded system:
202 root 490M 345M sleep 58 0 0:00.02 34% oops/619
50req/sec, 400 connections(up to 3500), 32G storages, 3weeks uptime. On this
system without heavy load VSZ is near 30M.
So, what I want to say - VSZ can depend on load. In the best case RSS is
almost equal to VSZ. With some mallocs (e.g. native solaris) VSZ never go
down, so you will always get VSZ more (much more) then RSS. Does your VSZ
become lower in quiet time (when load go down)?
>
> > VSZ sometimes can not move down even if you free almost all allocated
> > memory. ptmalloc handle this situation better then some other mallocs, it
> > can return unused memory to system. The most important thing is that vsz
> > must stop at some moment.
>
> I'll watch it closely. What I worry about is always when the VSZ gets
> swapped... and gets used from there. It seems good, as the swapped out
> data doesn't seem to get used much. So far.
Does vmstat or any other tool can show swapping activity on your system?
> The only way on my lazy mind is a malloc debugger, there are probably
> several ones floating around the net. Those wrap malloc() calls and
> record allocations is some tables.
>
> (Some out of my debian/linux catalog: electric-fence [it's rather a
> helper for bad alloc's], ccmalloc, dmalloc [some stats, too], debauch)
>
> It shall not be used for normal use (it slows down memory allocations,
> though I don't know the amount of the impact. Probably most of these
> tools are pretty portable - some maybe don't. I am not an active C
> developer, cannot say preferences....
>
> But it can be a debug aid, IF required. I don't think it's such a big
> problem now, so it doesn't really worth the work unless there is a
> problem requiring this solution. :-)
They can debug real bugs (leaks, read from unitialized, write to unallocated
and so on), but not the case of error-free, but memory ineffective case.
I'm periodically run OOPS under memory debugger to find what can be found.
But this is really difficult time :)
Igor Khasilev |
PACO Links, igor at paco dot net |
=====================================================================
If you would like to unsubscribe from this list send message to
[EMAIL PROTECTED] with "unsubscribe oops-eng" in message body.
Archive is accessible on http://www.paco.net/oops/
