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.