cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-6369) Fix prepared statement size computation
Date Mon, 18 Nov 2013 12:53:21 GMT

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

Jonathan Ellis updated CASSANDRA-6369:
--------------------------------------

    Reviewer: Lyuben Todorov

> 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)

Mime
View raw message