Close popover

Table of Contents

Configuring key cache settings


Maintain fast read access to Cassandra SSTables by tuning the use of the key cache separately for each table.

Cassandra’s key cache stores a map of partition keys to row index entries, which enables fast read access into SSTables.

  1. Check the current cache size by using Cassandra's nodetool info utility.

    The following nodetool info snippet shows sample key cache metrics:root@ip-10-123-5-62:/usr/local/tomcat/cassandra/bin# ./nodetool info ID : 8ae22738-98eb-4ed1-8b15-0af50afc5943 Gossip active : true Thrift active : true Native Transport active: true Load : 230.73 GB Generation No : 1550753940 Uptime (seconds) : 634324 Heap Memory (MB) : 3151.44 / 10240.00 Off Heap Memory (MB) : 444.33 Data Center : us-east Rack : 1c Exceptions : 0 Key Cache : entries 1286950, size 98.19 MB, capacity 300 MB, 83295 hits, 83591 requests, 0.996 recent hit rate, 14400 save period in seconds Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests, NaN recent hit rate, 0 save period in seconds Counter Cache : entries 0, size 0 bytes, capacity 50 MB, 0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds Token : (invoke with -T/--tokens to see all 256 tokens)
  2. If the size parameter roughly equals the capacity parameter, increase the cache size in the prconfig/dnode/yaml/key_cache_size_in_mb/default dynamic system setting, depending on your needs.

    The key_cache_size_in_mb setting indicates the maximum amount of memory for the key cache across all tables. The default value is either 5% of the total JVM heap, or 100 MB, whichever is lower.

  • Configuring Cassandra compression

    You can customize the compression settings for Cassandra SSTables to best suit your application's requirements. By using compression, you reduce the size of the data written to disk, and increase read and write throughput.

  • Configuring the retry policy

    You can increase Cassandra's fault tolerance by configuring how many times you want to retry queries that have failed. By retrying a failed Cassandra query you can circumvent temporary issues, for example, network-related errors.

  • Configuring dynamic system settings

    As a best practice, set system configuration settings by using dynamic system settings data instances. For example, you can use a dynamic system settings to configure which fields are available in full-text search. Dynamic system settings are stored in the Pega Platform database and are used by all nodes that share that database.

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.