On Mon, Dec 31, 2012 at 11:24 AM, James Masson wrote:
>
> Well, it turns out the Read-Request Latency graph in Ops-Center is highly
> misleading.
>
> Using jconsole, the read-latency for the column family in question is
> actually normally around 800 microseconds, punctuated by occasional big
> sp
Following up on this, I was hoping to get everyone's take on my use case
for Cassandra and see if everyone agrees it can meet the requirements:
I have a very tight SLA around get times. These are almost always single
row fetches for 20-50 columns on a row that is likely under 200 columns.
The req
Well, it turns out the Read-Request Latency graph in Ops-Center is
highly misleading.
Using jconsole, the read-latency for the column family in question is
actually normally around 800 microseconds, punctuated by occasional big
spikes that drive up the averages.
Towards the end of the batc
On Dec 29, 2012, at 8:53 PM, Mohit Anchlia wrote:
> Can you post gc settings? Also check logs and see what it says
These are the relevant jam settings:
-home /usr/lib/jvm/j2re1.6-oracle/bin/../
-ea -javaagent:/usr/share/cassandra/lib/jamm-0.2.5.jar
-XX:+UseThreadPriorities
-XX:ThreadPriorityP
Hi Yiming,
I've had the chance to observe what happens to cassandra read response
time over time.
It starts out with fast 1ms reads, until the first compaction starts,
then the CPUs are maxed out for a period, and read latency rises to 4ms.
After compaction finishes, the system returns to 1
