cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-724) Insert/Get Contention
Date Wed, 20 Jan 2010 21:49:54 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803007#action_12803007
] 

Jonathan Ellis commented on CASSANDRA-724:
------------------------------------------

I can reproduce this on a single-node setup, so I think it is possible you are seeing two
effects: one from the messagingservice stack (Brandon points out that this happens much more
frequently w/o CASSANDRA-705, than with it), and one from the commitlog sync (which I can
reproduce on a single node system).

> Insert/Get Contention
> ---------------------
>
>                 Key: CASSANDRA-724
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-724
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 0.6
>            Reporter: Chris Goffinet
>         Attachments: test_case.py
>
>
> We tried out the socket io patch in CASSANDRA-705, tested the latest JVM of b18 for 1.6.
Still seeing very strange insert times. We see this with get_slices as well but it's easy
to reproduce with batch_insert. I wonder if its related to Memtable contention, it's pretty
easy to see the slow times when you restart the test script attached. We are running this
on a 7 node cluster, <1% cpu. Consistency Level of 1.
> Results
> ---------------------
> Slow insert test.10882 0.203548192978
> Slow insert test.18005 0.203876972198
> Slow insert test.21154 0.204496860504
> Slow insert test.22054 0.0444049835205
> Slow insert test.26445 0.201545000076

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message