Re: (ITS#5860) slapd memeory leak under openldap 2.4

[hyc@symas.com]

Rodrigo Costa wrote:
> Howard,
>
> I tested the HEAD load last night. The results I believe are partial.

Thanks for the feedback, please try the new patch in HEAD.
>
> The memory stay stable and the use was much lower. I had in my slapd.conf the following cache boundaries :
>
> line 122 (cachesize       1000)
> line 123 (idlcachesize    1000)
> line 124 (dncachesize     2000)
>
> Which make with the new load to consume much less memory and stay stable.
>
> PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 20715 ldap      18   0  184m  73m  68m S    0  0.6 174:05.81 slapd
>
> But by the other hand I use the monitor information to check the cache usage. I would notice that now dncache is keeping around the boundary I put of 20000 but the cache is now fixed as 1, not 1000. See information below :
>
> readOnly: FALSE
> olmBDBEntryCache: 1
> olmBDBDNCache: 2185
> olmBDBIDLCache: 1
> olmDbDirectory: /var/openldap-data/bdb2/
> entryDN: cn=Database 2,cn=Databases,cn=Monitor
>
> This kept around this all the time I was making a search in DB.
>
> Before this load with this possible DN cache boundary solution I made the ldapsearch in around 7 minutes, for the first time not cached yet. And around 4 minutes after the entrances were cached.
>
> Now with this new load I made the search and it took :
>
> 1000000
>
> real    174m6.486s
> user    0m43.746s
> sys     0m16.923s
>
>
> Almost 3 hours. It's ok that I didn't tune the cache sizes but I was at least expecting the olmBDBEntryCache would now follow the 1000 boundary and not single 1.
>
> I believe this is what is not making this huge performance difference and not the olmBDBDNCache.
>
> Please confirm this is some tuning missing or if something else like the olmBDBEntryCache would be improved.
>
> In terms of memory usage now it is respecting but the performance, probably based in the olmBDBEntryCache only using 1 position, is much worst.
>
> Please also let me know if you think this performance degradation and the olmBDBEntryCache marking 1 is a tuning issue or something still need to be modified in the code.
>
> Thanks for the fast solution for this issue since this would be affecting all systems and types of DB.
>
> Rodrigo.


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/