[
https://issues.apache.org/jira/browse/CASSANDRA-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877618#action_12877618
]
Ben Manes commented on CASSANDRA-975:
-------------------------------------
That's understandable, but I was hoping it would be better. The new version has
the advantage of avoiding degradation scenarios which could affect Cassandra
due to its large caches. In the future an improved eviction policy (LIRS) is
now possible, which could make up for this slightly lower performance by
increasing the hit rate. That work is still experimental though and I've been
too busy to put much effort into it.
The older version is in SECOND_CHANCE mode which does no work on a read (sets a
volatile flag per entry), but on a write it iterates over the FIFO queue to
evict the first entry without that flag set. Any entry visited that had the
flag set has it unset and is resubmitted to the tail of the queue. This allows
reads to avoid locking, but it can result in flushing the queue if all the
entries were marked. That's an O(n) operation and writes are blocking, but for
small application caches (100 - 1000 avg) it isn't bad. For large caches (1M+),
that could be noticeable and unacceptable. I would also suspect that the
hit-rate of the policy would degrade with the cache's size, given that it may
not follow the rule of thumb that only 10-20% is hot, as in normal in
applications. This may have been reported in Cassandra
(http://comments.gmane.org/gmane.comp.db.cassandra.user/3039).
The new design trades off slightly higher memory usage and an amortized penalty
for performing LRU reordering for (mostly) non-blocking writes without a
degradation scenario. The memory usage and penalty could probably be improved
by tweaking the heuristics (currently just magic numbers). In a dedicated
server like Cassandra, we could also experiment with using ThreadLocal reorder
buffers vs. per-segment, which would avoid contention on the buffer if that was
found to be an issue. With help, I can probably bring it on par if there is
concern with the slightly slower results.
For now, its probably a choice between potentially suffering a degradation
scenario vs. slightly slower cache operations.
> explore upgrading CLHM
> ----------------------
>
> Key: CASSANDRA-975
> URL: https://issues.apache.org/jira/browse/CASSANDRA-975
> Project: Cassandra
> Issue Type: Task
> Reporter: Jonathan Ellis
> Assignee: Matthew F. Dennis
> Priority: Minor
> Fix For: 0.8
>
> Attachments: 0001-trunk-975.patch, clhm_test_results.txt,
> insertarator.py, readarator.py
>
>
> The new version should be substantially better "on large caches where many
> entries were readon large caches where many entries were read," which is
> exactly what you see in our row and key caches.
> http://code.google.com/p/concurrentlinkedhashmap/issues/detail?id=9
> Hopefully we can get Digg to help test, since they could reliably break CLHM
> when it was buggy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
