Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds

[sscdvp@gmail.com]

2009/4/17, sscdvp@gmail.com <sscdvp@gmail.com>:
>
>
> >
> > >
> > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from
> > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10.
> > > According to ITS#5860 slapd should not allocate more memory than it was
> > > specified. In fact I have the same behaviour as it was with previous
> > >
> > > version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for
> > > set_cachesize 300 MB). But slapd process continuosly grows in memory until
> > > 32-bit limit then crashes due to unavalable memory resources. I need to
> > >
> > > mention bdb database size is less then 1 GB.
> > > After restart it rapidly consumes 1.5 GB RSS in few minutes and then it
> > > grows beyond the limit during 24 hours. The more queries are processing
> > > the more memory it eats.
> > >
> > > I am using this database for logging which size grows.
> > > The question is: is it possible to use 32-bit openldap with relatively
> > > large database sizes that override 32-bit per-process memory space?
> > >
> > > My slapd.conf contains:
> > >
> > >
> > > threads 64
> > >
> >
> > Why do you have so many threads configured?  How many cpu's do you have??
>
>
> > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from
> > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10.
>
>
I have an application which generates heavy load in slapd (many
ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete).
BDB databases are situated on separate disk and BDB logs are on the
other disk. But slapd performance (I mean time to answer) still cuts
down during large disk IO periods 'cause these disks are used by other
applications at the same time. And so I have increased number of
threads from the defaults threads=32 up to 64, just to save some time
for my application which requires not more then 30 ms for one search
to complete.
> Just to be sure I have tried the default settings for threads and it's behaviour didn't changed - slapd heap memory just continuously grows (I have seen through pmap)...
> Also I have tried libtcmalloc which is usually recommended and solaris built in' libmtmalloc, but it didn't helped.