[Date Prev][Date Next]
RE: mdb expected growth
- To: "'Howard Chu'" <firstname.lastname@example.org>, <email@example.com>
- Subject: RE: mdb expected growth
- From: "Paul B. Henson" <firstname.lastname@example.org>
- Date: Mon, 13 Jan 2014 12:53:46 -0800
- Content-language: en-us
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=+xxm2cxAsJQBIqlX4D3w3NPCjtBWp72HR0J+fQsfQJU=; b=Cc8rLxzgQPnEzAVQsOpcwNgfvBUfTCyhusl3x4T6X96f7v76Z0WtGgASS1e9j6AuTu M9xVHxEwJK4YSseb6ilyYBxFcIc2tlcIa+6pMPH6vLn3V8BS9MUaLstP7pdmXW6NvpUn qBgaYo36k0goocM/an51cyiJa7yrlXqlV9oBDapblKnZ+cx/rPlBG4QfV4C1Lz3ItCvQ k1cdjkSb5JUJb+HSm01mcILsiTz3L3QCu6yGmskXqANgUSV7dHsL2UUpK0AiimLqpDDN bphkBMwmSbYytztcJOx0nwiLdduK4k6ffi5YM72BVcSP+hPM3sZtUPA8n56MiOmnO8M+ 3tzA==
- In-reply-to: <52D30BE7.email@example.com>
- References: <firstname.lastname@example.org> <52D30BE7.email@example.com>
- Thread-index: AQHwbpYQZ7N6yyEEjSUcOKUdJcLw3QKZl/J3miuXG/A=
> From: Howard Chu [mailto:firstname.lastname@example.org]
> Sent: Sunday, January 12, 2014 1:41 PM
> From the sound of your quite vague test description, sure. As it states
> the LMDB doc, long-lived reader transactions prevent reuse of freed pages.
> 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.