[
https://issues.apache.org/jira/browse/CASSANDRA-8231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-8231:
------------------------------------
Attachment: 8231-notes.txt
Yes - too many objects are measured.
It's not just instances of {{Class}}.
Also instances of {{AbstractType}}, reverse comparators of {{AbstractType}},
{{ColumnDefinition}}, {{Function}} - maybe more.
Additionally a single object is measured as often as it is referenced.
I've attached {{8231-notes.txt}} that shows the classes that are measured (used
a patched version of jamm).
> Wrong size of cached prepared statements
> ----------------------------------------
>
> Key: CASSANDRA-8231
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8231
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jaroslav Kamenik
> Assignee: Benjamin Lerer
> Attachments: 8231-notes.txt
>
>
> Cassandra counts memory footprint of prepared statements for caching
> purposes. It seems, that there is problem with some statements, ie
> SelectStatement. Even simple selects is counted as 100KB object, updates,
> deletes etc have few hundreds or thousands bytes. Result is that cache -
> QueryProcessor.preparedStatements - holds just fraction of statements..
> I dig a little into the code, and it seems that problem is in jamm in class
> MemoryMeter. It seems that if instance contains reference to class, it counts
> size of whole class too. SelectStatement references EnumSet through
> ResultSet.Metadata and EnumSet holds reference to Enum class...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
