--089e0115ff765de02a04e84f36b1 Content-Type: text/plain; charset=ISO-8859-1

I think I faced this same problem last week during a massive load of users (300K +) using a single ldapadd execution. My db "exploded" (MDB_MAP_FULL) after about 120K users populated. The main issue was related to the size of the db than to the actual memory allocated. It grew up to over 12GB before reaching the limit of my file system. But with memory-mapped files topics are close, I suppose.

Curious enough, populating the same db from a full syncrepl led the db to grew to only (more or less) 500MB.

As additional information, this server was part of a 5-node multi-master. And after the ldapadd the db -size was very different on each of the servers being part of the cluster.

I cannot share any conf, I'm sorry. Marco

--089e0115ff765de02a04e84f36b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>I think I faced this same problem last week= during a massive load of users (300K +) using a single ldapadd execution.<= br>My db &quot;exploded&quot; (MDB_MAP_FULL) after about 120K users populat= ed.<br>

The main issue was related to the size of the db than to the actual memory = allocated. It grew up to over 12GB before reaching the limit of my file sys= tem. But with memory-mapped files topics are close, I suppose.<br><br> </div> Curious enough, populating the same db from a full syncrepl led the db to g= rew to only (more or less) 500MB.<br><br>As additional information, this se= rver was part of a 5-node multi-master. And after the ldapadd the db -size = was very different on each of the servers being part of the cluster.<br>

<br></div>I cannot share any conf, I&#39;m sorry.<br></div>Marco<br></div>

--089e0115ff765de02a04e84f36b1--