Thanks all for the help. But I am bit lost though because in my case top command is showing that Cassandra process is consuming 18G (heap+nonheap + pagecache) Free command is showing 12G as available out of 24G total. Now my heap is 8G and off heap metrics show 1.6G ( using jmxterm) usage. So my usage should be around 9.6G and rest page cache is around 8G. Bug free command shows only 12G is available for use. I want to understand this discrepancy in memory consumption.
Regards Himanshu On Sun, Apr 12, 2020 at 10:28 AM Erick Ramirez <erick.rami...@datastax.com> wrote: > I observe long running nodes have high non heap memory footprint then a >> recently started node. That is the reason I am interested in find non heap >> memory usage by Cassandra node. What could be the reason of high non heap >> memory footprint in long running cluster? >> > > Memory utilisation grows over time as SSTables get read. From Cassandra > 2.2 onwards SSTables get mapped to memory -- i.e. the data files get copied > to memory to speed up reads. A newly restarted C* doesn't use as much > memory because the data hasn't been read yet so are not mapped to memory. > > I would like to know why memory usage is high and is there way to control >> it. > > > Laxmikant already mentioned disk_access_mode previously. This was a > hidden property in C* but CASSANDRA-8464 > <https://issues.apache.org/jira/browse/CASSANDRA-8464> [1] changed the > behaviour in C* 2.2 so I wrote this KB article > <https://support.datastax.com/hc/en-us/articles/360027838911> to explain > the memory issue in detail [2]. TL;DR -- set this in cassandra.yaml to > only mmap() the index files so there's less memory used: > > disk_access_mode: mmap_index_only > > > I want to monitor memory pressure, I want to check that if heap+non heap >> usage goes above certain level then I can take certain action. > > > In any case as Michael Shuler explained, your approach is problematic so > try to follow his recommendations. Cheers! > > [1] https://issues.apache.org/jira/browse/CASSANDRA-8464 > [2] https://support.datastax.com/hc/en-us/articles/360027838911 >
