Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of msddsm@gmail.com designates
 209.85.220.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=date:from:subject:to:x-priority:message-id:mime-version
         :content-type:content-transfer-encoding:x-mailer;
        b=sow8pNNDEP7z7hTCuAblxQOdLDGKDWTDww2M47kbPD1z7FOjUvfF2e1R6gEd3eYH7l
         sKilmOr8gYCZ2Uu3TPWn86MUTJGT4kXx4vHmff/Y8pOsBeWWhwmdp4rae1YRpbltJGzb
         l+2FyCnXqBpQK1taKmUWNas9ulysccPM80KDM=
Date: Mon, 15 Mar 2010 15:09:07 -0400
From: Matthew Sinclair-Day <msddsm@gmail.com>
Subject: Replicated database size
To: user@couchdb.apache.org
Message-ID: <4b9e85d5.111f5e0a.6587.ffffd45d@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi folks,

I've been putting couch 10.1 on Solaris 10/x86 through its paces=20
lately trying to understand its replication performance and=20
behavior, and have noticed the size of pre-compacted replicas=20
can vary from one host to another.

In one test, the origin has roughly 1.2 million documents taking=20
up 263MB of storage, but replicated size varies from one server=20
to another:

origin   : 263MB
replica 1: 0.6GB
replica 2: 0.7GB
replica 3: 1.0GB

As expected the replicas are larger than the compacted origin=20
database, but I didn't expect such size differences from replica=20
to replica.

After compacting the origin (again) and the replicas, their=20
sizes settle down to:

origin:  : 262.4MB
replica 1: 262.4MB
replica 2: 262.5MB
replica 3: 262.4MB

I'm trying to understand what the reason could be for the=20
variance in pre-compacted database sizes.  All replicas are=20
running the same build of CouchDB on the same version of=20
Solaris, though replica3 is running on newer hardware in a=20
VMWare container.

Matt