Strange memory problems

[Charles Swiger]

On Mar 8, 2006, at 12:52 PM, Eugene wrote:
>>> With Apache stopped, it goes down to RSS=0.5GB and VSZ=0.6G --  
>>> but Inactive
>>> Memory remains above 2.5GB.
>>> Is it a memory leak somewhere or what?
>>
>> That looks quite normal to me, apart from the zombie process.  
>> FreeBSD always
>> attempts to occupy most of the RAM, because it's a very fast way  
>> of saving
>> information, and after all a lot of RAM is of no use if there's  
>> nothing in
>> it. So long as no other program needs it for more "important"  
>> information,
>> there's nothing wrong with keeping a lot of "unimportant" stuff  
>> around in
>> case it is needed again quickly.
>
> Ok, that's nice. However, I was concerned not so much with low Free  
> memory as with Act+Inact being 1.5-4 times greater than size of  
> running processes. What data is there, exactly? I don't think it  
> has more than 1GB of unsynced disk writes?

No.  It's caching all of the pages used by processes which have not  
needed to be paged out yet.  The syncer process will regularly flush  
dirty pages to disk, so the amount of unsynced disk writes is going  
to be much smaller.

> Also, a more general question: how do I estimate 'real' memory  
> load? Sum(RSS) + 0.5*DiskCache  ?
> For example, I would like to know (in advance) e.g. how many Apache  
> processes we can handle before memory becomes a problem.

The instantaneous 'real' memory load is the Active column, plus the  
KVA (wired down memory) and the disk cache.  You can divide the  
amount of (inactive + free) by the size of each apache httpd, and get  
an upper bound on the number of extra httpd's you can probably run.

Paying attention to your page fault rate is a better way of tuning,  
however.

> Do you think it would be nice if top(1) could give some  
> consolidated measure -- probably taking into account usage  
> statistics and/or response time?

Top already attempts to give useful measurements.

> Or at least two measures -- e.g. "How much memory can be allocated  
> off-hand without any disk I/O"

You can allocate an almost unlimited amount of memory, so long as you  
don't actually write to it; FreeBSD uses VM overcommit extensively.

> and "How much memory can be allocated so that swapped data would  
> not have to be re-read again in reasonable time"?

That's the "inactive" entry in top, more or less.

-- 
-Chuck