linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zan Lynx <zlynx@acm.org>
To: Attila Kinali <attila@kinali.ch>
Cc: Robert Hancock <hancockrwd@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: Long lasting MM bug when swap is smaller than RAM
Date: Wed, 01 Jul 2009 17:15:38 -0600	[thread overview]
Message-ID: <4A4BEE1A.8090204@acm.org> (raw)
In-Reply-To: <20090701100834.1f740ad5.attila@kinali.ch>

Attila Kinali wrote:
> On Wed, 1 Jul 2009 10:04:32 +0200
> Attila Kinali <attila@kinali.ch> wrote:
> 
>>> But 
>>> swapping does not only occur if memory is running low. If disk usage is 
>>> high then non-recently used data may be swapped out to make more room 
>>> for disk caching.
>> Hmm..I didn't know this.. thanks!
> 
> This was the cause of the problem!
> 
> I just restarted svnserv, clamav and bind (the three applications
> using most memory) and suddenly swap cleared up.
> 
> Now the question is, why did they accumulate so much used swap
> space, while before the RAM upgrade, we hardly used the swap space at all?

I do not know about the others, but ClamAV suffers from pretty serious 
memory fragmentation.  What it does is load the updated signatures into 
a new memory allocation, verify them, then free the old signature 
allocation.  This results in a large hole in glibc's malloc structures 
and because of ClamAV's allocation pattern, this hole is difficult to 
reclaim.  This ClamAV memory fragmentation will continue to grow worse 
until the daemon is completely restarted.

Under memory pressure the kernel pushes least used pages out to swap, 
and these unused but still allocated pages of ClamAV are never again 
used, so out to swap they go.

I know this because the company I work for tried to fix the memory 
allocation fragmentation of ClamAV, but they did not like our patch and 
preferred to continue allowing the memory allocator to fragment in 
exchange for simpler code.

-- 
Zan Lynx
zlynx@acm.org

"Knowledge is Power.  Power Corrupts.  Study Hard.  Be Evil."

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-07-01 23:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-30  9:58 Attila Kinali
2009-06-30 17:58 ` Hugh Dickins
2009-07-01  7:55   ` Attila Kinali
2009-07-01  1:36 ` Robert Hancock
2009-07-01  8:04   ` Attila Kinali
2009-07-01  8:08     ` Attila Kinali
2009-07-01 23:15       ` Zan Lynx [this message]
2009-07-01  4:21 ` Wu Fengguang

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=4A4BEE1A.8090204@acm.org \
    --to=zlynx@acm.org \
    --cc=attila@kinali.ch \
    --cc=hancockrwd@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox