cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelvin Kakugawa (JIRA)" <j...@apache.org>
Subject [jira] Created: (CASSANDRA-1930) db.Table flusherLock write lock fairness policy is sub-optimal
Date Tue, 04 Jan 2011 01:20:45 GMT
db.Table flusherLock write lock fairness policy is sub-optimal
--------------------------------------------------------------

                 Key: CASSANDRA-1930
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1930
             Project: Cassandra
          Issue Type: Improvement
          Components: Core
    Affects Versions: 0.7.0 rc 3, 0.7.0 rc 2, 0.7.0 rc 1, 0.7 beta 3, 0.7 beta 2, 0.7 beta
1, 0.6.8, 0.6.7, 0.6.6, 0.6.5, 0.6.4, 0.6.3, 0.6.2, 0.6.1, 0.6, 0.5, 0.4, 0.3, 0.6.9, 0.7.0,
0.7.1, 0.8
            Reporter: Kelvin Kakugawa
            Assignee: Kelvin Kakugawa
             Fix For: 0.8


h4. scenario:
1) high write throughput cluster
2) external services adding material cpu contention

h4. symptoms:
The row mutation stage falls *very* behind.

h4. cause:
ReentrantReadWriteLock's fair policy causes write lock acquisition / release to require a
material amount of CPU time.

h4. summary:
When there are other services contending for the CPU, the RRW lock's fair policy causes write
lock acquisition / release to take enough time to eventually put threads waiting for read
lock acquisition very behind.  We repro'd this scenario by reducing the scope of the write
lock to: 1 boolean check, 1 boolean assignment, and 1 db.Memtable instantiation (itself, just:
2 variable assignments) w/ the same performance.  Modifying the fairness policy to be the
default policy allowed the row mutation stage to keep up.

-- 
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