Hi,
I see a strange thing in cn=Monitor. Suggestions needed.
I have a huge database, and performance is great as long as olcReadOnly is TRUE. But a soon as I enable writes, the number of Read Waiters are growing, even though there's no or very few Write waiters.
# Read, Waiters, Monitor dn: cn=Read,cn=Waiters,cn=Monitor monitorCounter: 311
# Write, Waiters, Monitor dn: cn=Write,cn=Waiters,cn=Monitor monitorCounter: 0
# Current, Connections, Monitor dn: cn=Current,cn=Connections,cn=Monitor monitorCounter: 210
I have idletime=120 and connections do around 30 reads each before they are retired, but not many writes. Like this:
# Connection 5389, Connections, Monitor dn: cn=Connection 5389,cn=Connections,cn=Monitor monitorConnectionNumber: 5389 monitorConnectionOpsReceived: 32 monitorConnectionOpsExecuting: 0 monitorConnectionOpsPending: 0 monitorConnectionOpsCompleted: 32 monitorConnectionGet: 32 monitorConnectionRead: 32 monitorConnectionWrite: 0
It's slapd 2.4.21, BDB 4.8.26 and back_bdb.
Any hint to what could cause that many read-waiters, but only while writing is enabled and even though there's not that many writes?
/Peter
--On Friday, February 26, 2010 9:46 AM +0100 Peter Mogensen apm@mutex.dk wrote:
Hi,
I see a strange thing in cn=Monitor. Suggestions needed.
I have a huge database, and performance is great as long as olcReadOnly is TRUE. But a soon as I enable writes, the number of Read Waiters are growing, even though there's no or very few Write waiters.
# Read, Waiters, Monitor dn: cn=Read,cn=Waiters,cn=Monitor monitorCounter: 311
# Write, Waiters, Monitor dn: cn=Write,cn=Waiters,cn=Monitor monitorCounter: 0
# Current, Connections, Monitor dn: cn=Current,cn=Connections,cn=Monitor monitorCounter: 210
I have idletime=120 and connections do around 30 reads each before they are retired, but not many writes. Like this:
# Connection 5389, Connections, Monitor dn: cn=Connection 5389,cn=Connections,cn=Monitor monitorConnectionNumber: 5389 monitorConnectionOpsReceived: 32 monitorConnectionOpsExecuting: 0 monitorConnectionOpsPending: 0 monitorConnectionOpsCompleted: 32 monitorConnectionGet: 32 monitorConnectionRead: 32 monitorConnectionWrite: 0
It's slapd 2.4.21, BDB 4.8.26 and back_bdb.
Any hint to what could cause that many read-waiters, but only while writing is enabled and even though there's not that many writes?
It could be a bug in back-monitor...
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Friday, February 26, 2010 9:46 AM +0100 Peter Mogensen apm@mutex.dk wrote:
I have idletime=120 and connections do around 30 reads each before they are retired, but not many writes. Like this:
# Connection 5389, Connections, Monitor dn: cn=Connection 5389,cn=Connections,cn=Monitor monitorConnectionNumber: 5389 monitorConnectionOpsReceived: 32 monitorConnectionOpsExecuting: 0 monitorConnectionOpsPending: 0 monitorConnectionOpsCompleted: 32 monitorConnectionGet: 32 monitorConnectionRead: 32 monitorConnectionWrite: 0
It's slapd 2.4.21, BDB 4.8.26 and back_bdb.
Any hint to what could cause that many read-waiters, but only while writing is enabled and even though there's not that many writes?
It could be a bug in back-monitor...
I should say that once in a while I _do_ see one or two connections with a few (mostly 1) monitorConnectionWrite.
So it's not that they never get counted.
/Peter
Quanah Gibson-Mount wrote:
It could be a bug in back-monitor...
I assume that delete operations are "writes".
If so, you may be right.
I've just tried doing an ldapdelete -r on a subtree with several thousands entries and just before it finished the connection monitor entry was this:
# Connection 34616, Connections, Monitor dn: cn=Connection 34616,cn=Connections,cn=Monitor monitorConnectionNumber: 34616 monitorConnectionOpsReceived: 7983 monitorConnectionOpsExecuting: 1 monitorConnectionOpsPending: 0 monitorConnectionOpsCompleted: 7982 monitorConnectionGet: 7983 monitorConnectionRead: 7983 monitorConnectionWrite: 0
I'm sure this is the correct connection.
Every entry delete seems counted as a "read".
Also - it took very long time to delete these entries. Over an hour.
(there's around 10 million entries in the database)
/Peter
openldap-technical@openldap.org