Paul B. Henson wrote:
From: Howard Chu [mailto:hyc@symas.com] Sent: Sunday, January 12, 2014 1:41 PM
From the sound of your quite vague test description, sure. As it states
in
the LMDB doc, long-lived reader transactions prevent reuse of freed pages. http://symas.com/mdb/doc/
You have a long search operation running, and are issuing writes while the search is in progress.
Hmm, I don't think that is the case. The way the script works is that it first generates a list of all of our groups (which doesn't even come from LDAP, it gets pulled out of a database that is another component of our idm infrastructure). Then, for each group, it does a search to get all the members, and then removes/adds them 500 at a time until it has processed all of them. So there is one search, then repeated modify remove/modify add, then another completely separate search, etc, through all of them. The connection to the LDAP server is persistent throughout the script, but there is no single operation whose duration persists.
Does it have anything to do with being a syncrepl provider? The documentation sometimes describes syncrepl as being a "persistent search", and the size increase only occurred on the primary master, not the secondary master or read-only slaves.
The syncprov persistent search implementation doesn't result in a long-lived read transaction. You can use mdb_stat -r to see what's going on as far as read transactions in the DB.