Thanks, I've read the conversation.
Turning on timed sync for bitcask kinda solved the problem for now.
On Tue, Aug 17, 2010 at 11:52 PM, Alexander Sicular wrote:
> I'm having a discussion with dizzyd in the irc about this. The compaction is
> not triggered by time or by and particular number o
I'm having a discussion with dizzyd in the irc about this. The compaction is
not triggered by time or by and particular number of records overwritten, but
rather the total number of dead bytes and fragmentation percentage as listed in
the default config here,
http://github.com/basho/bitcask/blo
how is the compact phase defined/activated? I looked through the docs
and didn't see it.
On Tue, Aug 17, 2010 at 11:54 AM, Alexander Sicular wrote:
> Bitcask is a write only log (wol) that eats disk (by keeping all updates)
> until a compaction phase that reclaims disk at some defined interval.
We've been running Riak at production for 3 weeks and database just
kept growing. Even more time for our test server. Well, it was an
older Riak, 0.12.0.
I've been running 0.12.1 for several hours and still no compaction though...
On Tue, Aug 17, 2010 at 7:54 PM, Alexander Sicular wrote:
> Bitca
Bitcask is a write only log (wol) that eats disk (by keeping all
updates) until a compaction phase that reclaims disk at some defined
interval.
-Alexander
@siculars on twitter
http://siculars.posterous.com
Sent from my iPhone
On Aug 17, 2010, at 11:27, Dmitry Demeshchuk
wrote:
Greet
Greetings.
This problem has already been discussed in IRC a bit.
I use Riak 0.12.1 (have been using 0.12.0 but then updated to the
latest version and got the same problem) with bitcask storage.
All Riak settings are default, i.e., all buckets are
default-configured (allow_mult=false), replicatio
