[jira] [Updated] (CASSANDRA-6369) Fix prepared statement size computation

["Jeremiah Jordan (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremiah Jordan updated CASSANDRA-6369:
---------------------------------------

    Since Version: 1.2.11

> Fix prepared statement size computation
> ---------------------------------------
>
>                 Key: CASSANDRA-6369
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6369
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 1.2.12, 2.0.3
>
>         Attachments: 6369.txt
>
>
> When computed the size of CQLStatement to limit the prepared statement cache (CASSANDRA-6107), we overestimate the actual memory used because the statement include a reference to the table CFMetaData which measureDeep counts. And as it happens, that reference is big: on a simple test preparing a very trivial select statement, I was able to only prepare 87 statements before some started to be evicted because each statement was more than 93K big and more than 92K of that was the CFMetaData object. As it happens there is no reason to account the CFMetaData object at all since it's in memory anyway whether or not there is prepared statements or not.
> Attaching a simple (if not extremely elegant) patch to remove what we don't care about of the computation. Another solution would be to use the MemoryMeter.withTrackerProvider option as we do in Memtable, but in the QueryProcessor case we currently use only one MemoryMeter, not one per CF, so it didn't felt necessarilly cleaner. We could create one-shot MemoryMeter object each time we need to measure a CQLStatement but that doesn't feel a lot simpler/cleaner either. But if someone feels religious about some other solution, I don't care.



--
This message was sent by Atlassian JIRA
(v6.1#6144)