Hi,
During performance testing with SLAMD we noticed the dncache exceeds the limit. As a result the system starts to swap a lot and the responses of slapd are very slow.
Has anyone seen that behavior before?
Here are the facts:
slapd.conf monitoring on tool-threads 4 cachesize 450000 dncachesize 450000 idlcachesize 450000 cachefree 90000
# ldapsearch -x -D "cn=xxxx" -w xx -b 'cn=database 2,cn=databases,cn=monitor' -s sub '(objectclass=*)' '*' '+' | grep -i Cache
olmBDBEntryCache: 398306 olmBDBDNCache: 482001 <<========== olmBDBIDLCache: 449999
# slapd -V @(#) $OpenLDAP: slapd 2.4.11 (Sep 11 2008 10:58:58) $ root@node3:/usr/src/redhat/BUILD/openldap-2.4.11/servers/slapd
#db_stat -V Berkeley DB 4.6.21: (September 27, 2007)
# uname -r 2.6.9-67.ELsmp
# cat /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 6)
Cheers, Pavlos
--On Thursday, October 02, 2008 11:07 AM +0300 Pavlos Parissis p_pavlos@freemail.gr wrote:
Hi,
During performance testing with SLAMD we noticed the dncache exceeds the limit. As a result the system starts to swap a lot and the responses of slapd are very slow.
Has anyone seen that behavior before?
Here are the facts:
slapd.conf monitoring on tool-threads 4 cachesize 450000 dncachesize 450000 idlcachesize 450000 cachefree 90000
# ldapsearch -x -D "cn=xxxx" -w xx -b 'cn=database # 2,cn=databases,cn=monitor' -s sub '(objectclass=*)' '*' '+' | grep -i # Cache
olmBDBEntryCache: 398306 olmBDBDNCache: 482001 <<========== olmBDBIDLCache: 449999
Sounds like a bug to me, have you filed an ITS?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Thursday, October 02, 2008 9:33 AM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Thursday, October 02, 2008 11:07 AM +0300 Pavlos Parissis p_pavlos@freemail.gr wrote:
Hi,
During performance testing with SLAMD we noticed the dncache exceeds the limit. As a result the system starts to swap a lot and the responses of slapd are very slow.
Has anyone seen that behavior before?
Here are the facts:
slapd.conf monitoring on tool-threads 4 cachesize 450000 dncachesize 450000 idlcachesize 450000 cachefree 90000
# ldapsearch -x -D "cn=xxxx" -w xx -b 'cn=database # 2,cn=databases,cn=monitor' -s sub '(objectclass=*)' '*' '+' | grep -i # Cache
olmBDBEntryCache: 398306 olmBDBDNCache: 482001 <<========== olmBDBIDLCache: 449999
Sounds like a bug to me, have you filed an ITS?
Actually, please read ITS#5721:
http://www.openldap.org/its/index.cgi/?findid=5721
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Thu, 02 Oct 2008 09:33:50 -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Thursday, October 02, 2008 11:07 AM +0300 Pavlos Parissis p_pavlos@freemail.gr wrote:
[...snip...]
olmBDBEntryCache: 398306 olmBDBDNCache: 482001 <<========== olmBDBIDLCache: 449999
Sounds like a bug to me, have you filed an ITS?
No, but after I read your mail I filed one,ITS#5722
Is there anything that I can do to help debugging the issue?
Cheers, Pavlos
On Thu, 02 Oct 2008 13:32:56 -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Thursday, October 02, 2008 9:33 AM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Thursday, October 02, 2008 11:07 AM +0300 Pavlos Parissis p_pavlos@freemail.gr wrote:
Hi,
During performance testing with SLAMD we noticed the dncache exceeds the limit. As a result the system starts to swap a lot and the responses of slapd are very slow.
[...snip...]
olmBDBEntryCache: 398306 olmBDBDNCache: 482001 <<========== olmBDBIDLCache: 449999
Sounds like a bug to me, have you filed an ITS?
Actually, please read ITS#5721:
Well, when I sent the mail this ITS wasn't there.
But, how long is that "temporarily" ? In my case it was 32000 entries more than the limit. Isn't it too dangerous to have that "termporarily" period?
Cheers, Pavlos
--On Thursday, October 02, 2008 10:50 PM +0200 Pavlos Parissis p_pavlos@freemail.gr wrote:
Well, when I sent the mail this ITS wasn't there.
But, how long is that "temporarily" ? In my case it was 32000 entries more than the limit.
As long as the conditions noted in ITS#5721 apply, I'd think.
Isn't it too dangerous to have that "termporarily" period?
Dangerous how? Previous releases had no upper limit, and although that caused more memory usage, it wasn't dangerous...
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Thu, 02 Oct 2008 13:54:10 -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Thursday, October 02, 2008 10:50 PM +0200 Pavlos Parissis p_pavlos@freemail.gr wrote:
Well, when I sent the mail this ITS wasn't there.
But, how long is that "temporarily" ? In my case it was 32000 entries more than the limit.
As long as the conditions noted in ITS#5721 apply, I'd think.
Isn't it too dangerous to have that "termporarily" period?
Dangerous how? Previous releases had no upper limit, and although that caused more memory usage, it wasn't dangerous...
In our test we saw that when the dnchache was way too above the limit the system starting to swap a lot. We have quite long DNs , but I don't know the actual size.
BTW, what is the actual size that is being allocated in the memory for each entry in dncache? I know that the entries in entry cache are about twice as large as they are on disk, but I don't know about the dncache entries.
Cheers, Pavlos
openldap-software@openldap.org
-
p_pavlos＠freemail.gr -
Pavlos Parissis
-
Quanah Gibson-Mount