How do I improve Level DB performance?

Tim Haines tmhaines at gmail.com
Fri May 11 11:00:15 EDT 2012


David,

I ran the benchmark again for 9 hours overnight, just doing puts.
 Performance fell steadily from 400 puts/s to 250 puts/s.

Graph: http://twitpic.com/9jtjmu/full

Cheers,

Tim.

On Thu, May 10, 2012 at 3:01 PM, David Smith <dizzyd at basho.com> wrote:

> On Thu, May 10, 2012 at 2:33 PM, Tim Haines <tmhaines at gmail.com> wrote:
>
> > I've set up a new cluster, and have been doing pre-deployment benchmarks
> on
> > it. The benchmark I was running slowly sunk from 1000 TPS to 250 TPS over
> > the course of the single 8 hour benchmark doing 1 read+1 update using 1k
> > values.  I'm wondering if anyone might have suggestions on how I can
> improve
> > this.
>
> Generally, this suggests that you are becoming seek-time bound. The
> test config, as specified, will generate a pretty huge number of
> not_founds which are (currently) crazy expensive w/ LevelDB,
> particularly as the dataset grows.
>
> Assuming you start with an empty database, a sample of this test will
> generate operations like so:
>
> Key 1000 - get -> not_found
> Key 1001 - update -> not_found + write
> Key 1002 - get -> not_found
> etc..
>
> I.e. the leveldb cache never gets a chance to be useful, because
> you're always writing new values and the cost of writing each new
> value goes up, since you have to thrash the cache to determine if
> you're ever seen the key that doesn't exist. :)
>
> The root problem here is going to be the key_generator --
> partitioned_sequential_int will just run through all the ints in order
> and never revisit a key.
>
>
> >         {write_buffer_size, 16777216},
> >         {max_open_files, 100},
> >         {block_size, 262144},
> >         {cache_size, 168430088}
>
> I strongly recommend not changing write_buffer_size; it can have
> unexpected latency side-effects when LevelDB compaction occurs.
> Smaller == more predictable.
>
> Does that help?
>
> D.
>
> --
> Dave Smith
> VP, Engineering
> Basho Technologies, Inc.
> dizzyd at basho.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20120511/ac21032f/attachment.html>


More information about the riak-users mailing list