[Samba] Samba + LDAP + IIS = massive memory usage

[Martin Edwards]

(Sorry, I meant to send this to the list first time around)

Thanks very much for that.

On a thread using 1.2GB pool-usage reports:

full talloc report on 'null_context' (total 5898052 bytes in 39825 blocks)

There are thousands of lib/charcnv.c:601 entries but all using only 1 block
each.

On Fri, May 1, 2009 at 9:29 AM, Volker Lendecke
<Volker.Lendecke at sernet.de>wrote:

> On Thu, Apr 30, 2009 at 02:55:46PM +0100, Martin Edwards wrote:
> > I'm not sure if this is a bug or a problem we are causing which is why
> I'm
> > posting to the list first in the hope that someone else might have come
> > across it.
> >
> > We have been using Samba quite successfully for a number of years.
>  However,
> > with this new setup we have a problem.
> >
> > We're using Samba as a backend for a web farm - 6 or 7 Windows servers
> > running IIS with all the website data under UNC paths and all the
> anonymous
> > web users and app pools running as domain users.
> >
> > Samba itself uses an LDAP backend.
> >
> > This setup works very nicely for our needs however we have an issue in
> that
> > each Samba process belonging to one of the web servers seems to consume
> RAM
> > indefinitely until it is killed.  When the servers are busy each thread
> can
> > use 1GB in 20 minutes.
> >
> > Obviously this is extremely abnormal memory usage.
> >
> > My only guess is that, when a page is requested on a website and not
> found,
> > Samba allocates the memory and does not free it?
> >
> > We have tried Samba 3.0, 3.2 and 3.3 (various iterations) and have
> > experienced exactly the same problem.
> >
> > Can anyone offer any insight.  I would be most grateful.
>
> Two steps: Can you run "smbcontrol <pid> pool-usage" on a
> moderately large smbd and send the result? If that does not
> show anything suspicious, we will ask you to run it under
> valgrind --tool=memcheck. Be aware that this *significantly*
> slows down operation, so you might need some kind of plan
> how to do this. But it is the safest way to find out
> what's going on.
>
> Volker
>