Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of schumi.han@gmail.com
 designates 209.85.214.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=KS8S6VL8kWYW5zorUzX1QiYuxAmkxxvZz4lf0DQy7byqZkph3sSo1v3Ux8PLxYtWPv
         z9vpjYvSEie+jG5YQw0sWcOQqzz+iIf0mR9JBJAEoBNOtogF7QkTjNAS7Od8NJHZQy8f
         nGzbtfszmOicJTL4l1hJJlU8uWCUz3Vmd3ulc=
MIME-Version: 1.0
In-Reply-To: <AANLkTimz3ROjS=EJOw2DfGZcZZgZ4FAEsY1dP-K4-t8O@mail.gmail.com>
References: <4C977450.5030908@corp.aol.com>
	<AANLkTimrPfYEUsnUP-MO_JMmYuxGu6U3qKM9v1Pbfja+@mail.gmail.com>
	<4C979A84.20904@corp.aol.com>
	<AANLkTimz3ROjS=EJOw2DfGZcZZgZ4FAEsY1dP-K4-t8O@mail.gmail.com>
Date: Wed, 22 Sep 2010 11:46:33 +0800
Message-ID: <AANLkTimwWu9Uqdd5nv9G4EmcUXewE2GypkSF3j1z2vvZ@mail.gmail.com>
Subject: Re: improving read performance
From: Zhu Han <schumi.han@gmail.com>
To: dev@cassandra.apache.org
Content-Type: multipart/alternative; boundary=001517477fb0df73e60490d0fdab

--001517477fb0df73e60490d0fdab
Content-Type: text/plain; charset=ISO-8859-1

> Reasons to not use the row cache with large rows include:
>
> * In general it's a waste of memory better given to the OS page cache,
> unless possibly you're continually reading entire rows rather than
> subsets of rows.
>
> * For truly large rows you may have immediate issues with the size of
> the data being cached; e.g. attempting to cache a 2 GB row is not the
> best idea in terms of heap space consumption; you'll likely OOM or
> trigger fallbacks to full GC, etc.
>
> * Having a larger key cache may often be more productive.
>
> > That aside, splitting the memtable in 2, could make checking the bloom
> > filters unnecessary in most cases for me, but I'm not sure it's worth the
> > effort.
>
> Write-through row caching seems like a more direct approach to me
> personally, off hand. Also to the extent that you're worried about
> false positive rates, larger bloom filters may still be an option (not
> currently configurable; would require source changes).
>
> IMHO, it's very difficult to tune JVM when JVM caches a lot of data for a
long time because
the modern GC does not design for such purpose.

There is a patch about make the row cache pluggable to be replaced by
memcached[1]. This is likely
the right way to go.

[1]https://issues.apache.org/jira/browse/CASSANDRA-1283


> --
> / Peter Schuller
>

--001517477fb0df73e60490d0fdab--