Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
From: Robert Newson <rnewson@apache.org>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_3AE8B36B-2F20-4A3D-99AC-8B50EF1BDE5F";
 protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <D65A9208-91E0-4846-BAE7-008D45E0AC94@apache.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Bug? Database compaction keeps re-running continuously on CouchDB
 1.4
Date: Sat, 5 Oct 2013 09:26:42 +0100
References: <1380874669.18587.29887753.2B255FEF@webmail.messagingengine.com>
 <1380955431.25834.30260849.03926390@webmail.messagingengine.com>
To: user@couchdb.apache.org
In-Reply-To: <1380955431.25834.30260849.03926390@webmail.messagingengine.com>

--Apple-Mail=_3AE8B36B-2F20-4A3D-99AC-8B50EF1BDE5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


It makes intuitive sense that setting that % too low will cause endless =
(and pointless) compactions (the ratio of disk_size to data_size =
exceeding your % immediately after compaction). I'm fairly sure, for =
example, that the data_size value does not include the space consumed by =
the many database footers in the file.

B.

On 5 Oct 2013, at 07:43, Calle Arnesten <calle.arnesten@codekick.com> =
wrote:

> I tested to change the db_fragmentation to different levels. If I =
raise it to 70% the compaction stops, but for 60% and lower it keeps =
running all the time.=20
>=20
> So there seems to be something weird with how CouchDB calculates the =
fragmentation level. As I said, I have a large percentage of deleted =
documents in the database, so perhaps it is not including them correctly =
in the calculation? It could definitely be near 70% of the database size =
that is deleted documents.
>=20
> On Fri, Oct 4, 2013, at 10:17, Calle Arnesten wrote:
>> Hi,
>>=20
>> I recently upgraded from CouchDB 1.2 to 1.4. I have noticed that the =
database compaction is running more or less all the time during the =
allowed compaction time. Is there a known issue for this with 1.4?
>>=20
>> The compaction is completed on each run and the reported database =
size is smaller on the first run during the compaction time. But then it =
starts again for the same database, and when completed, starts again, =
etc. It's like it thinks that the database is still fragmented even if =
it's not.
>>=20
>> The databases are quite large (~5GB), so it's not the case that many =
documents have had time to change during the compaction time.
>>=20
>> These are my settings:
>> [{db_fragmentation, "20%"}, {view_fragmentation, "20%"}, {from, =
"03:00"}, {to, "11:00"}]
>>=20
>> The harddrive is not full, it has about 70GB of free space.=20
>>=20
>> I have a large percentage of deleted documents, if that might be a =
reason for the issue/bug.=20
>>=20
>> I don't have the same problem for view compaction.
>>=20
>> Best regards
>> Calle Arnesten


--Apple-Mail=_3AE8B36B-2F20-4A3D-99AC-8B50EF1BDE5F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJST81FAAoJEBAV9o+doki86CUP/RdijfaoddJhQKGdDYKJ0gXo
9KViMGS+BmuuErIzuknvHvGjE75NhQEVWGAuMotoGoCimVLAUyrAO0uwoMHb2J6Z
IqjsUDV+j89L3E7Q5lIO1M1NMG3poOdDZ1RdG03BiE088iU3bKfBCOqrHzLvhzmd
nOaws7fePoawv+izJKFCorP1QBFdCkpFE7HC+srsfu+VkVnAmruM20tSHqieQHDR
K0jTsa1Msf12FCT7CsGszRDiGZ/LTHdB65nt7eeuS+kfj3wbAGgmp0wvB83TYLrC
0fKzgD0iRGEoy6pvw2CAvASfD3QzigpsKxjtDUsVy/AQZvVGiBhvsXZeQ6YlbQ+X
j0K5G6taOKWlv8QFFQgH+VU4A97Uv2wUaJ7NKkH98Q3uX6eMeisbVBvy91mRGsTR
ipLiqLLpxBcFKKteI8wzCqJ88P8pAxZDMl2eo7vzrOO6MwfHzpIWP8Fo7GylfE+U
IMJemzOtXSzT4Z6FAv4w6pH/in2A55V4ybjrVa3TUZRVuPs+N9M082Reeir87AYp
DxIlzjUZrG6nIfEwc8g/aQr+Yru4529YDTARcrPNQGdTuRJGsWw2NnWPSQMQHYgU
u6KrNWcJ169lQivUHtGUdT+S7JVY8dm+qYessIKNEd9uB+aBThrxQMihgfYcdxvp
MKPJS1kuJDoRg909+xBV
=0wHB
-----END PGP SIGNATURE-----

--Apple-Mail=_3AE8B36B-2F20-4A3D-99AC-8B50EF1BDE5F--