openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by quanah＠zimbra.com 27 Jan '09

27 Jan '09

--On Monday, January 26, 2009 3:18 PM -0800 Rodrigo Costa <rlvcosta(a)yahoo.com> wrote: > Quanah and Howard, > > Sorry to come back. > > I tried to make 2 ldapsearch to the same DB simultaneously, doing some > stress test like dump the LDIF and queries coming. > > The slapd after sometime start to get more memory. By what I could > observe looks like new thread was started consuming again the same memory > as before so the slad now is consuming around the double of memory as > before. Are you also using an alternate malloc() instead of glibc? I know you were investigating this, just want to confirm you are using tcmalloc or hoard and not glibc. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 27 Jan '09

27 Jan '09

Quanah and Howard, Sorry to come back. I tried to make 2 ldapsearch to the same DB simultaneously, doing some stress test like dump the LDIF and queries coming. The slapd after sometime start to get more memory. By what I could observe looks like new thread was started consuming again the same memory as before so the slad now is consuming around the double of memory as before. I believe the cache would not grow beyond the boundary as like per thread since once cache is allocated it is never released. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10195 ldap 18 0 1913m 1.7g 68m S 100 15.0 31:25.71 slapd Then performance start to degrade again. Like before looks like the dump get stuck and comes in chunks. See example below : Mon Jan 26 21:05:16 BRST 2009 378752 Mon Jan 26 21:09:21 BRST 2009 378800 See that after around 4 minutes I have only 48 adds to the output LDIF from my first ldapsearch. Looks like if multiples queries are happening something still getting lost. Both queries are to the same DB and the monitor has : readOnly: FALSE olmBDBEntryCache: 1000 olmBDBDNCache: 1000953 olmBDBIDLCache: 1 Sorry to come back with this issue but I could detect this now. Thanks, Rodrigo. --- On Mon, 1/26/09, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > From: Quanah Gibson-Mount <quanah(a)zimbra.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com, openldap-its(a)openldap.org > Date: Monday, January 26, 2009, 8:53 PM > --On Monday, January 26, 2009 10:44 PM +0000 > rlvcosta(a)yahoo.com wrote: > > > Just some last questions. Is there any expectation for > a new release, for > > example 2.4.15, with this ITS included? Just to use a > formal release. > > 2.4.14 will have the fix for this ITS. There's no set > release date at this time, but hopefully soon. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by quanah＠zimbra.com 26 Jan '09

26 Jan '09

--On Monday, January 26, 2009 10:44 PM +0000 rlvcosta(a)yahoo.com wrote: > Just some last questions. Is there any expectation for a new release, for > example 2.4.15, with this ITS included? Just to use a formal release. 2.4.14 will have the fix for this ITS. There's no set release date at this time, but hopefully soon. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 26 Jan '09

26 Jan '09

Howard, Now it fits under my expectation. Under the initial load without the fix I had slapd not respecting any boundary and then all DN information being cached. In this way the first query would take longer since the information wasn't yet cached. At that time I had, without cache, a search for around 1million entrances in around 7 minutes and after cached this time reduce to around half. So now with the new load I was expecting something a little longer as the initial not cached since now slapd will not be able to cache all information and so the cache will be often overwritten. Now in my tests I obtained : First time: real 6m50.017s user 0m17.346s sys 0m9.159s Second time: real 6m47.790s user 0m17.032s sys 0m9.137s Third time: real 7m17.459s user 0m17.412s sys 0m9.320s This is more than perfect. Amazing how you guys could solve this problem so quickly. I saw sometimes the DN cache allocating a little more memory since it sometimes pass a little the boundary, like seen below : olmBDBEntryCache: 1000 olmBDBDNCache: 1000247 olmBDBIDLCache: 1 The maximum I saw was 1000268 but nothing considerable. In this way now slapd is keeping memory allocation stable as it is supposed to behave. The only comment is if dn cache is passed this memory allocated appears to never be released. The maximum size slapd obtained was : PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10195 ldap 18 0 385m 266m 68m S 0 2.2 20:54.16 slapd This is more than perfect ! Thanks for all your quick solution of this problem. I believe many users of openLDAP will see their system more stable with this fix. Just some last questions. Is there any expectation for a new release, for example 2.4.15, with this ITS included? Just to use a formal release. By the tests I was expecting the cachefree as the cache size bringing some improvements, at least in a full query, since system would "cycle" pointer memory and overwritten all cache at once. What is the purpose of cachefree? Just to understand better and then tune later with some better idea about cache purposes. Best Regards, Rodrigo. --- On Mon, 1/26/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)OpenLDAP.org > Date: Monday, January 26, 2009, 6:00 PM > Rodrigo Costa wrote: > > Howard, > > > > I do not think the ITS is completely solved. Let me > try to explain better. > > > > I have the system respecting now the DN cachesize > boundary. At the same time I wasn't sure about the > cachefree idea and now I changed to 1, or equal the default > value. > > > > In any case what happens is : > > > > 1) I have the system doing sequential search in a > reasonable speed until the dncachesize is reached; > > 2) After dncchesize is reached the sequential search > hangs, or the output from the search get stuck for a long > time(I'm forwarding to a file so I do not have screen > actualization delays); > > Ex: > > [root@brtldp11 backup]# date; cat temp.ldif |grep -e > '^pnnum*' |wc -l > > Mon Jan 26 17:22:21 BRST 2009 > > 250016 > > [root@brtldp11 backup]# date; cat temp.ldif |grep -e > '^pnnum*' |wc -l > > Mon Jan 26 17:23:00 BRST 2009 > > 250016 > > See above that even almost after 1 minute passed not > new LDIF entrance was included. > > 3) Then query get stuck and looks like deterministic > it time by time only dumps 16 entrances and get stuck. This > behavior repeats and with these stuck that sometime gets > minutes the query never ends. > > > > olmBDBEntryCache: 884 > > olmBDBDNCache: 1000261 > > olmBDBIDLCache: 1 > > > > olmBDBEntryCache: 611 > > olmBDBDNCache: 1000261 > > olmBDBIDLCache: 1 > > > >Even with cachesize as 1000 and cachefree as 1, the > olmBDBEntryCache continues > to decrease, just slow now. > > > > I was expecting that a cachefree as 1000 would purge > all entrances and then > > cache again all 1000 new with in sequence always > answering the search. So > > the search would never hangs like it is happening now. > > I see. OK, this is now fixed in HEAD. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP > http://www.openldap.org/project/

1 0

Re: (ITS#5336)
by hyc＠symas.com 26 Jan '09

26 Jan '09

quanah(a)zimbra.com wrote: > A similar bug has been reported in the debian bug tracking system, with > some debugging information and reproducibility steps. > > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465915> Noting that this was closed in Debian as of 2.4.9. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 26 Jan '09

26 Jan '09

Rodrigo Costa wrote: > Howard, > > I do not think the ITS is completely solved. Let me try to explain better. > > I have the system respecting now the DN cachesize boundary. At the same time I wasn't sure about the cachefree idea and now I changed to 1, or equal the default value. > > In any case what happens is : > > 1) I have the system doing sequential search in a reasonable speed until the dncachesize is reached; > 2) After dncchesize is reached the sequential search hangs, or the output from the search get stuck for a long time(I'm forwarding to a file so I do not have screen actualization delays); > Ex: > [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l > Mon Jan 26 17:22:21 BRST 2009 > 250016 > [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l > Mon Jan 26 17:23:00 BRST 2009 > 250016 > See above that even almost after 1 minute passed not new LDIF entrance was included. > 3) Then query get stuck and looks like deterministic it time by time only dumps 16 entrances and get stuck. This behavior repeats and with these stuck that sometime gets minutes the query never ends. > > olmBDBEntryCache: 884 > olmBDBDNCache: 1000261 > olmBDBIDLCache: 1 > > olmBDBEntryCache: 611 > olmBDBDNCache: 1000261 > olmBDBIDLCache: 1 > >Even with cachesize as 1000 and cachefree as 1, the olmBDBEntryCache continues to decrease, just slow now. > > I was expecting that a cachefree as 1000 would purge all entrances and then > cache again all 1000 new with in sequence always answering the search. So > the search would never hangs like it is happening now. I see. OK, this is now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 26 Jan '09

26 Jan '09

Howard, I do not think the ITS is completely solved. Let me try to explain better. I have the system respecting now the DN cachesize boundary. At the same time I wasn't sure about the cachefree idea and now I changed to 1, or equal the default value. In any case what happens is : 1) I have the system doing sequential search in a reasonable speed until the dncachesize is reached; 2) After dncchesize is reached the sequential search hangs, or the output from the search get stuck for a long time(I'm forwarding to a file so I do not have screen actualization delays); Ex: [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l Mon Jan 26 17:22:21 BRST 2009 250016 [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l Mon Jan 26 17:23:00 BRST 2009 250016 See above that even almost after 1 minute passed not new LDIF entrance was included. 3) Then query get stuck and looks like deterministic it time by time only dumps 16 entrances and get stuck. This behavior repeats and with these stuck that sometime gets minutes the query never ends. olmBDBEntryCache: 884 olmBDBDNCache: 1000261 olmBDBIDLCache: 1 olmBDBEntryCache: 611 olmBDBDNCache: 1000261 olmBDBIDLCache: 1 Even with cachesize as 1000 and cachefree as 1, the olmBDBEntryCache continues to decrease, just slow now. I was expecting that a cachefree as 1000 would purge all entrances and then cache again all 1000 new with in sequence always answering the search. So the search would never hangs like it is happening now. It get stuck and will never ends since it responds only 16 entrances in order of minutes and in bursts. The previous load was more reasonable than now since even taking much longer it would end the search. [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l Mon Jan 26 17:31:36 BRST 2009 250128 Please let me know if you need more information, Rodrigo. --- On Mon, 1/26/09, Howard Chu <hyc(a)symas.com> wrote: > From: Howard Chu <hyc(a)symas.com> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: rlvcosta(a)yahoo.com > Cc: openldap-its(a)OpenLDAP.org > Date: Monday, January 26, 2009, 5:18 PM > Rodrigo Costa wrote: > > Howard, > > > > I download the new HEAD version and made some testing. > Now the > olmBDBEntryCache is following the cache configuration. > > Good, then this ITS is resolved. Usage questions should be > directed to the > -software mailing list. > > > I also made some small change in slapd.conf including > cachefree > configuration. Please see below in the end how slapd is > configured related to > bdb cache : > > > line 123 (cachesize 1000) > > line 124 (cachefree 1000) > > line 125 (idlcachesize 1000) > > line 126 (dncachesize 1000000) > > Setting cachefree equal to cachesize will effectively cause > the entire entry > cache to be dumped each time it reaches its maximum size. > That's clearly not a > good idea. > > > I increase the dncachesize since with a small value > the search takes > considerable more time. > > > > First I tested with a value greater than the value > that was consuming > > before > without the memory boundary. In this way I was expecting > some order of > magnitude as before, what it achieved (line 126 > (dncachesize 5000000)): > > > BEFORE CACHED: > > 1000000 > > > > real 5m23.084s > > user 0m28.026s > > sys 0m6.686s > > > > Then Cache has : > > > > olmBDBEntryCache: 1001 > > olmBDBDNCache: 4000264 > > olmBDBIDLCache: 1 > > > > AFTER CACHED: > > > > 1000000 > > > > real 2m31.623s > > user 0m28.145s > > sys 0m8.637s > > > > Just to let clear these tests above where with the new > logic and where the > DN Cache Size is bigger than the final number I had with > the old logic where > all information is cached into memory. > > > > For each entrance I have 4 dn's that compose the > entrance. Since my filter > is for only one of the dn I was expecting this cache to be > only related with > the filter and then in 1,000,000. > > > Then I change the dncachesize to 1000000 (line 126 > (dncachesize 1000000) : > > > > The total time for a search using a filter for one > index dn became : > > > > ldap_result: Can't contact LDAP server (-1) > > 255801 > > > > real 469m26.619s > > user 0m7.027s > > sys 0m1.756s > > > > I needed to kill the server so I would have an idea > about how many > > entrances > it searched. The time is too long and I'm not sure if > it would even end. I let > all night but the process did not end. This was the same > ldapsearch as when > all entrances would be allocated in a DN cache into memory. > > > > But the cache process was something I wasn't > expecting. Before the > dncachesize was reached I had at monitor : > > > > olmBDBEntryCache: 1001 > > olmBDBDNCache: 921296 > > olmBDBIDLCache: 1 > > > > Then after the boundary was reached it became : > > > > olmBDBEntryCache: 1 > > olmBDBDNCache: 1000262 > > olmBDBIDLCache: 1 > > > > Where these numbers didn't change anymore. Not > sure why after the > dncachesize is reached the cachesize(or olmBDBEntryCache) > became 1. > > Because you set cachefree to 1000. 1001 - 1000 = 1. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP > http://www.openldap.org/project/

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by hyc＠symas.com 26 Jan '09

26 Jan '09

Rodrigo Costa wrote: > Howard, > > I download the new HEAD version and made some testing. Now the olmBDBEntryCache is following the cache configuration. Good, then this ITS is resolved. Usage questions should be directed to the -software mailing list. > I also made some small change in slapd.conf including cachefree configuration. Please see below in the end how slapd is configured related to bdb cache : > line 123 (cachesize 1000) > line 124 (cachefree 1000) > line 125 (idlcachesize 1000) > line 126 (dncachesize 1000000) Setting cachefree equal to cachesize will effectively cause the entire entry cache to be dumped each time it reaches its maximum size. That's clearly not a good idea. > I increase the dncachesize since with a small value the search takes considerable more time. > > First I tested with a value greater than the value that was consuming > before without the memory boundary. In this way I was expecting some order of magnitude as before, what it achieved (line 126 (dncachesize 5000000)): > BEFORE CACHED: > 1000000 > > real 5m23.084s > user 0m28.026s > sys 0m6.686s > > Then Cache has : > > olmBDBEntryCache: 1001 > olmBDBDNCache: 4000264 > olmBDBIDLCache: 1 > > AFTER CACHED: > > 1000000 > > real 2m31.623s > user 0m28.145s > sys 0m8.637s > > Just to let clear these tests above where with the new logic and where the DN Cache Size is bigger than the final number I had with the old logic where all information is cached into memory. > > For each entrance I have 4 dn's that compose the entrance. Since my filter is for only one of the dn I was expecting this cache to be only related with the filter and then in 1,000,000. > Then I change the dncachesize to 1000000 (line 126 (dncachesize 1000000) : > > The total time for a search using a filter for one index dn became : > > ldap_result: Can't contact LDAP server (-1) > 255801 > > real 469m26.619s > user 0m7.027s > sys 0m1.756s > > I needed to kill the server so I would have an idea about how many > entrances it searched. The time is too long and I'm not sure if it would even end. I let all night but the process did not end. This was the same ldapsearch as when all entrances would be allocated in a DN cache into memory. > > But the cache process was something I wasn't expecting. Before the dncachesize was reached I had at monitor : > > olmBDBEntryCache: 1001 > olmBDBDNCache: 921296 > olmBDBIDLCache: 1 > > Then after the boundary was reached it became : > > olmBDBEntryCache: 1 > olmBDBDNCache: 1000262 > olmBDBIDLCache: 1 > > Where these numbers didn't change anymore. Not sure why after the dncachesize is reached the cachesize(or olmBDBEntryCache) became 1. Because you set cachefree to 1000. 1001 - 1000 = 1. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5906) slapo-rwm and cn=config
by ando＠sys-net.it 26 Jan '09

26 Jan '09

ldap(a)htam.net wrote: > Full_Name: Mathieu MILLET > Version: 2.4.13 > OS: Linux Fedora 10 > URL: > Submission from: (NULL) (81.80.3.6) > > > When configuring the slapo-rwm overlay inside a relay database, using cn=config > style, it is impossible to load (online or offline) the attribute > olcRwmRewrite. Should be fixed in HEAD. Please test and report. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5906) slapo-rwm and cn=config
by ldap＠htam.net 26 Jan '09

26 Jan '09

Full_Name: Mathieu MILLET Version: 2.4.13 OS: Linux Fedora 10 URL: Submission from: (NULL) (81.80.3.6) When configuring the slapo-rwm overlay inside a relay database, using cn=config style, it is impossible to load (online or offline) the attribute olcRwmRewrite. The error message is : htam@p10891008 ldif]$ ldapadd -h localhost -x -D "cn=config" -w secret -f config_relay_database.ldif adding new entry "olcOverlay={0}rwm,olcDatabase={3}relay,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcRwmRewrite> handler exited with 1 config_relay_database.ldif : dn: olcOverlay={0}rwm,olcDatabase={3}relay,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmNormalizeMapped: FALSE olcRwmRewrite: {0} rwm-rewriteEngine "on" olcRwmRewrite: {1} rwm-rewriteContext "default" olcRwmRewrite: {2} rwm-rewriteRule "cn=(.+),ou=ilo,dc=domain-ilo,dc=net$" "uid=$1,ou=people,dc=domain,dc=net" ":" olcRwmRewrite: {3} rwm-rewriteContext "searchEntryDN" olcRwmRewrite: {4} rwm-rewriteRule "uid=(.+),ou=people,dc=domain,dc=net$" "cn=$1,ou=ilo,dc=domain-ilo,dc=net" ":" olcRwmRewrite: {5} rwm-rewriteRule ".+,ou=groups,dc=domain,dc=net$" "$0" ":@" olcRwmRewrite: {6} rwm-rewriteContext "searchAttrDN" "alias" "searchEntryDN" olcRwmRewrite: {7} rwm-rewriteContext "matchedDN" "alias" "searchEntryDN" olcRwmTFSupport: no ------------------------------ dn: olcDatabase={3}relay objectClass: olcDatabaseConfig objectClass: olcRelayConfig olcDatabase: {3}relay olcSuffix: ou=ilo,dc=domain-ilo,dc=net olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcMonitoring: FALSE olcRelay: dc=domain,dc=net structuralObjectClass: olcRelayConfig I get the same result and error, if I manually put this file in the slapd.d sub-directory. I also get the same result and error, if I ldapadd the objet without the olcRwmRewrite attribute and then ldapmodify to add this attribute (even a single line like <<rwm-rewriteEngine "on">> or <<rwm-rewriteContext "default">>).

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs