All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yoss <bartek@milc.com.pl>
To: Willy TARREAU <willy@w.ods.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Memory leak in 2.4.33-pre1?
Date: Wed, 15 Feb 2006 10:01:30 +0100	[thread overview]
Message-ID: <20060215090130.GA3343@milc.com.pl> (raw)
In-Reply-To: <20060214214349.GA298@w.ods.org>

On Tue, Feb 14, 2006 at 10:43:49PM +0100, Willy TARREAU wrote:
> On Tue, Feb 14, 2006 at 09:21:36AM +0100, Yoss wrote:
> > I downgraded hernel to 2.4.33 last night.
> I presume you mean 2.4.32 here.

Right. :)

> 
> > So there is no slabinfo from that problem now. But thank you for reply.
> > Why is this memory not showed somewhere in top or free?
> 
> I don't know, it's some gray area for me too, it's just that I'm used to
> this behaviour. I even have a program that I run to free it when I want
> to prioritize disk cache usage over dentry cache (appended to this mail).

I think it is grey for me too ;\
After about 36h of run the summary size of processes is 714MB. Free
says:

webcache:~# free -m
             total       used       free     shared    buffers  cached
Mem:          1009        996         13          0		    50      93
-/+ buffers/cache:        852        157
Swap:         1953          0       1953

So thereis 139MB of difference. But:

#slabtop -s c -o | head -20

Active / Total Objects (% used)    : 793971 / 805664 (98.5%)
 Active / Total Slabs (% used)      : 66499 / 66513 (100.0%)
 Active / Total Caches (% used)     : 36 / 59 (61.0%)
 Active / Total Size (% used)       : 235510.62K / 236644.88K (99.5%)
 Minimum / Average / Maximum Object : 0.02K / 0.29K / 128.00K

OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
362495 362490  99%    0.50K  51785        8     207140K inode_cache
380910 380900  99%    0.12K  12697       32      50788K dentry_cache
44800  35342  78%    0.09K   1120       42        4480K	buffer_head
636    607  95%    2.00K    318        2          1272K size-2048
139    139 100%    4.00K    139        1           556K size-4096
2064   1891  91%    0.16K     86       25          344K ip_dst_cache
232    224  96%    0.91K     58        4           232K	sock
2080   2048  98%    0.09K     52       42	       208K blkdev_requests
5198   4495  86%    0.03K     46      128		   184K size-32
1032    658  63%    0.16K     43       25		   172K skbuff_head_cache
870    864  99%    0.12K     29       32		   116K filp
1416   1381  97%    0.06K     24       64		    96K size-64
570    545  95%    0.12K     19			 32         76K size-128
								 
> Have you noticed the difference ? So the memory is not wasted at all. It's
> just reported as 'used'.

I see. I also noticed that I simply cannot tell what for is this memory
used. Is this better for me to enlarge cache_mem in squid for about
100MB and have less *_cache or is better to have more *_cache? :)

> > > If you don't believe me, simply allocate 1 GB in a process, then free it.
> > If that what you said is rigth, day after tomorow I'll have the same
> > situation - only thing I have changed is kernel. So we'll see. :)
> 
> If you encounter it, simply run the tool below with a size in kB. Warning!
> a wrong parameter associated with improper ulimit will hang your system !
> Ask it to allocate what you *know* you can free (eg: the swapfree space).

I don't matter is this memory used for cache or free. I just want to be
sure that it is not leaking :)

-- 
Bartłomiej Butyn aka Yoss
Nie ma tego złego co by na gorsze nie wyszło.

  reply	other threads:[~2006-02-15  9:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-13 21:46 Memory leak in 2.4.33-pre1? Yoss
2006-02-14  0:05 ` Willy Tarreau
2006-02-14  0:34   ` Roberto Nibali
2006-02-14  4:50     ` Willy Tarreau
2006-02-14  8:22     ` Yoss
2006-02-14  8:21   ` Yoss
2006-02-14 21:43     ` Willy TARREAU
2006-02-15  9:01       ` Yoss [this message]
2006-02-15 20:11         ` Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060215090130.GA3343@milc.com.pl \
    --to=bartek@milc.com.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@w.ods.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.