memory fragmentation issues in 1.2?

[Paul T]

Well, I re-read the thread and it is now clear that
you are making several contradicting claims, hence I
had to make some (wrong) assumptions. Now there is
more or less enough information provided and some
conclusions can be made.

You are saying that your copy of memcached is leaking
memory to the point of going from 800Mb to 2Gb+ per
memcached process. That is certainly wrong and should
not be happening. It could be that you are the only
person on a planet observing this behaviour. ( OOM has
nothing to do with it - it was bad idea to mention it
in the first place, it distracted us)

You then made an assumption that it has something to
do with "memory fragmentation".

Perhaps you dont know (really? you don't know?), but
memcached is *not* using system malloc, but instead it
is using a custom memory allocation -- memory pooling
subsystem that is being sold as a subsystem to
*prevent* the "memory fragmentation". 

If you read the memcached presentations (or look into
memcached source code) you would realise that
memcached is the least likely software in the world to
cause "memory fragmentation" because by design
memcached does *not* allocate any memory with malloc.

It tries *so* hard that it is a all over the place. 

Are you saying that in result of all this dance they
actually *do* cause the actual memory fragmentation?

That would be *hillarious*. 

Is it what you're saying? If the process consumes 2Gb
instead of 800Mb - there are clearly memory leaks.

Now we can keep speculating if there is bug in
memcached, or perhaps you've built it poorly e t.c.
but the thing is simple :

If Memcached is leaking memory "memory fragmentaion"
is the *least* probable cause.

So what is the problem? Memcached is leaking RAM and
you can not capture the leak, because valgrind is no
help? (In the absense of bugs in slabs subsystem of
course valgrind would no help because memcached's
malloc is custom - see the article that I posted
earlier).

In any case - I am sorry I did not solved your
problem. 

Certainly,  you have all the experience to detect the
leak by yourself.

Rgds.Paul.

--- George Schlossnagle <george at omniti.com> wrote:

> Paul T wrote:
> > --- George Schlossnagle <george at omniti.com> wrote:
> > 
> >> Paul T wrote:
> >>> Turn off the OOM killer and see what happens?
> >> I could.  I would expect it to actually OOM and
> die
> >> when it exceeds
> >> addressable memory space.
> > 
> > All I'm saying is that it could be that OOM gets
> > nervous too early. If I would post you the cacti
> > pictures from my servers you would see than the
> amount
> > of 'free RAM' goes down for a while. And then at
> some
> > point Linux re-claims it. It's OK behaviour.
> 
> If malloc fails (fails to allocate), then it doesn't
> really matter if
> you have the OOM killer running or not.
> 
> > Are you complaining about the amount of 'free RAM'
> > going down on Linux? If that is what you call
> > 'addressabe RAM' - I see no reason to be troubled.
> 
> I'm talking about the addressable memory space in my
> process shrinking.
> 
> 
> > When was that? 
> > A lot have changed in Linux codebase in last 10
> years.
> 
> This year, against all the major Linux distro
> vendors.  Porting Solaris'
> libumem to the platforms we needed to support and
> integrating against
> that solved all the issues.
> 
> Having a discussion with you about whether the
> behavior I'm experiencing
> is possible/real/a figment of my imagination doesn't
> really move me any
> closer to solving my problem.
> 
> George
> 



 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited