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.
