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 matthieu.rakotojaona@gmail.com
 designates 74.125.82.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ_m3YAgQ=ibpiHUK=HCZ+56xmEuEdNx9Mr0ib08FZ1uOL3J4Q@mail.gmail.com>
References: 
 <CAMiZLn2J+D6zqQr4Ej5u7n_fQacym0wMzcugMGgoQqCR=X1RTQ@mail.gmail.com>
 <CAJ_m3YAgQ=ibpiHUK=HCZ+56xmEuEdNx9Mr0ib08FZ1uOL3J4Q@mail.gmail.com>
From: Matthieu Rakotojaona <matthieu.rakotojaona@gmail.com>
Date: Sat, 10 Mar 2012 20:01:40 +0100
Message-ID: 
 <CAMiZLn26vW1Layf1eAxdx5NjJP7N_QTfiiwrVOVem7HqW7RL4g@mail.gmail.com>
Subject: Re: Compaction
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

Wow, thank you for the very comprehensive answer.

On Thu, Mar 8, 2012 at 10:39 PM, Paul Davis <paul.joseph.davis@gmail.com> w=
rote:
>> And the initial purpose to my mail comes here. I just added a few
>> documents in my db (1.7+M) and found that the disk_size gives me ~2.5GB.
>> while the data_size is around 660 Mo. From what I read, a compaction is
>> supposed to leave you with data_size ~=3D disk_size; yet, after numerous
>> compaction, it doesn't shrink a bit.
>>
>
> I bet you have random document ids which will indeed cause the
> database file to end up with a significant amount of garbage left
> after compaction. I'll describe why below.

Yup. I already had my ids, but they were not ordered as I read through
the file. Now that couchDB stores my rows with its own-generated IDs
(with the 'sequential' algorithm), the new size of my whole DB shrank
down to 500 MB. Very neat.

>> * If yes, can you move the temporary db.compact.couch file somewhere
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0else and link to it so that couchdb thinks no=
thing has changed ?
>>
>
> I'm not sure what you mean here.

In case I see that I will lack storage space, like what happened to
me, I would like the .compact file to be created and used in another
disk, but I didn't see this in the config file. So I thought something
like that would do the trick :

1. Launch compaction
2. Pause it (actually, stop the server for now)
3. Move the .compact created file somewhere else, and symlink to it
4. Continue compaction

This flow could also be useful if we want to use an SSD to do a
(faster) compaction, later writing the DB back to a classic HDD.

I resorted to mounting some directory on my data disk to
/var/lib/couchdb, which I'm not really proud of.

--=20
Matthieu RAKOTOJAONA