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: > [r...@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l > Mon Jan 26 17:22:21 BRST 2009 > 250016 > [r...@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/
