Question
2
Replies
262
Views
Posted: October 3, 2018
Last activity: March 21, 2019
Closed
ADM CommitLog in Cassandra/DNode sizing
we've recently implemented more modems in our DSM implementation. We're seeing an increase in growth in cassandra (/cassandra_data was 35 GB). Are there tuning parameters to flush this data to the DB? We're going to be applying the hotfix for 42009 for the OperationTimedOut exception on node start/sync. The commitlog table itself is 12 GB and that query is timing out.
***Edited by Moderator Marissa to update SR Details***
Posted: 2 years ago
it's the adm_response_commitlog within cassandra (so a Pega table/keyspace) that was timing out. There was a hotfix to apply. I also posted another question around gc_grace_seconds to see about reclaiming disk space more frequently than 10 days.
I'm not sure what you mean by the query to the commit log table are timing out.
We don't do queries against Cassandra commit logs. Cassandra should use these logs if your node crash hence we lose data in memory. Commit logs contains data about all tables in Cassandra.
12 GB sounds high.
In the short term, you could try to use nodetool flush and check if the commit logs get reduced afterward.
In the long term, you could try adding the setting commitlog_total_space_in_mb in your yaml file:
https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html#configCassandra_yaml__commitlog_total_space_in_mb
I'm not aware this setting has been exposed into any Pega DSS setting so this is direct Cassandra configuration.
I believe you will need to restart the node for the setting to take effect.
Test all this first in a test system.