[
https://issues.apache.org/jira/browse/CASSANDRA-19801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Lacerda updated CASSANDRA-19801:
--------------------------------------
Description:
We often encounter cases where humongous object allocations cause long GC
pauses. However, identifying the cause is very difficult because you must use a
profiler to catch the allocations before GC.
It would be nice to add a TRACE-level logger to the ReadCommand or ReadExecutor
classes. This would allow us to turn on code that calculates the cell size and,
if it exceeds the heap region size (which varies by heap size), triggers a
message in the logs that identifies the query that triggered the large read
with the partition key and query parameters so it's easy to ID the cell.
It might be easier to log on the write rather than the read path.
was:
We often encounter cases where massive object allocations cause long GC pauses.
However, identifying the cause is very difficult because you have to use a
profile and catch the allocations before they GC.
It would be nice to add a TRACE level logger to the ReadCommand or ReadExecutor
classes that would allow us to turn on code that would calculate the cell size
and if over the heap region size (varies by heap size), trigger a message in
the logs that identifies the query that triggered the large read with the
partition key and query params so it's easy to ID the cell.
> Ability to log large objects with query that's reading it
> ---------------------------------------------------------
>
> Key: CASSANDRA-19801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19801
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Steve Lacerda
> Priority: Urgent
>
> We often encounter cases where humongous object allocations cause long GC
> pauses. However, identifying the cause is very difficult because you must use
> a profiler to catch the allocations before GC.
> It would be nice to add a TRACE-level logger to the ReadCommand or
> ReadExecutor classes. This would allow us to turn on code that calculates the
> cell size and, if it exceeds the heap region size (which varies by heap
> size), triggers a message in the logs that identifies the query that
> triggered the large read with the partition key and query parameters so it's
> easy to ID the cell.
> It might be easier to log on the write rather than the read path.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
