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/
