[
https://issues.apache.org/jira/browse/CASSANDRA-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13629757#comment-13629757
]
Vijay edited comment on CASSANDRA-4860 at 4/12/13 4:00 AM:
-----------------------------------------------------------
This is my theory:
2M KV with Measure.measure() will take 96,000,000 or 96M (2 *24 * 2000000
bytes) will fit in key cache.
2M KV with measureDeep() will take 96M + 48M (48 * 2000000 + 24 * 2000000)
where 48 is the index min size and 24 is the key size.
Hence there is a eviction overhead on the keycache which you dont have in
Measure.measure().
Give the above if you have the key cache of 300M and re test both v3 should
show a better performance.
{code}
Completed warmup!, Number of Iteratoions: 1000000
Using reflection took: 8037
Using 4860-v3 took: 90
Using MemoryMeter meter.measure(key) took: 190
Using MemoryMeter meter.measureDeep(key) took: 1002
Using 4860-v3 RowIndexEntry took: 14
Using MemoryMeter meter.measure(RowIndexEntry(i)) took: 104
Using MemoryMeter meter.measureDeep(RowIndexEntry(i)) took: 459
Size of Meter.measure key: 24
Size of Meter.measure index: 24
Size of Meter.measureDeep key: 48
Size of Meter.measureDeep index: 24
Size of key: 48
Size of index: 24
{code}
was (Author: vijay2...@yahoo.com):
This is my theory:
2M KV with Measure.measure() will take 96,000,000 or 96M (2 *24 * 2000000
bytes) will fit in key cache.
2M KV with measureDeep() will take 96M + 48M (48 * 2000000 + 24 * 2000000)
where 48 is the index min size and 24 is the key size.
Give the above if you have the key cache of 300M and re test both v3 should
show a better performance.
{code}
Completed warmup!, Number of Iteratoions: 1000000
Using reflection took: 8037
Using 4860-v3 took: 90
Using MemoryMeter meter.measure(key) took: 190
Using MemoryMeter meter.measureDeep(key) took: 1002
Using 4860-v3 RowIndexEntry took: 14
Using MemoryMeter meter.measure(RowIndexEntry(i)) took: 104
Using MemoryMeter meter.measureDeep(RowIndexEntry(i)) took: 459
Size of Meter.measure key: 24
Size of Meter.measure index: 24
Size of Meter.measureDeep key: 48
Size of Meter.measureDeep index: 24
Size of key: 48
Size of index: 24
{code}
> Estimated Row Cache Entry size incorrect (always 24?)
> -----------------------------------------------------
>
> Key: CASSANDRA-4860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4860
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0, 1.2.3, 2.0
> Reporter: Chris Burroughs
> Assignee: Vijay
> Fix For: 1.2.0 beta 3
>
> Attachments: 0001-4860-v2.patch, 0001-4860-v3.patch,
> 0001-CASSANDRA-4860-for-11.patch, 0001-CASSANDRA-4860.patch,
> 4860-perf-test.zip, trunk-4860-revert.patch
>
>
> After running for several hours the RowCacheSize was suspicious low (ie 70
> something MB) I used CASSANDRA-4859 to measure the size and number of
> entries on a node:
> In [3]: 1560504./65021
> Out[3]: 24.0
> In [4]: 2149464./89561
> Out[4]: 24.0
> In [6]: 7216096./300785
> Out[6]: 23.990877204647838
> That's RowCacheSize/RowCacheNumEntires . Just to prove I don't have crazy
> small rows the mean size of the row *keys* in the saved cache is 67 and
> Compacted row mean size: 355. No jamm errors in the log
> Config notes:
> row_cache_provider: ConcurrentLinkedHashCacheProvider
> row_cache_size_in_mb: 2048
> Version info:
> * C*: 1.1.6
> * centos 2.6.32-220.13.1.el6.x86_64
> * java 6u31 Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
