On 24/03/2015 6:56 AM, Quanah Gibson-Mount wrote:
--On Monday, March 23, 2015 8:38 PM +0000 Howard Chu hyc@symas.com wrote:
Geoff Swan wrote:
I had to duplicate an LMDB database for replication recently, and used mdb_copy to do so. One server is using the original data.mdb database (which is sparse)
and the other is using the mdb_copy non-sparse data.mdb file.
If you specified no special options, the file produced by mdb_copy is identical to the original - it will also be sparse if the original is.
Well, to be clear: While the DB is sparse, mdb_copy does drop the unused map space when using mdb_copy by default.
That is what I have seen. The filesystem reports 2TB file size for the first server, and 590GB file size for the mdb copy, with default options.
I.e., if I specified an 80GB maxsize on a 20MB db, then the database copy done via mdb_copy will be 20MB not 80GB. I.e., it's still sparse, but the unused portion has been dropped.
OK
I think this is the behavior they're referring to. However, in my experience, after starting up slapd with an mdb_copy'd db, where sparse files are in use, the size will be set to whatever slapd's configured to use after slapd is started.
This is not what is being seen. The file size remains at 590GB on the server using the copy, and 2TB on the original server.
If that is not being seen, then your configurations are not as identical as thought.
The configurations are identical. The servers are direct copies of each other. Hence the question concerning performance as one is ramping up to a much slower search time than the other.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration