SnappyData provides statistics for system memory, JVM heap, garbage collection, and table sizes.
You can use these statistics to analyze your application's memory usage. An example follows the table.
Type
CachePerfStats
Name
RegionStats-<table> and RegsionStats-partition-<table>
Statistic
entries
Description
Number of rows in the replicated or partitioned table.
Type
PartitionedRegionStats
Name
PartitionedRegion/<schema>/<table>Statistics
Statistic
dataStoreEntryCount and dataStoreBytesInUse
Description
Number of rows/bytes in a partitioned table, including redundant copies.
Type
VMMemoryUsageStats
Name
vmHeapMemoryStats
Statistic
usedMemory and maxMemory
Description
Used heap and maximum heap, in bytes.
Type
VMMemoryUsageStats
Name
OffHeapMemoryStats
Statistic
usedMemory, maxMemory, freeMemory
Description
Used off-heap memory, maximum (amount allocated) off-heap memory, and free off-heap memory in bytes.
Type
VMMemoryPoolStats
Name
ParSurvivorSpace, ParEdenSpace, CMSOldGen
Statistic
currentUsedMemory
Description
Estimated used memory, in bytes, for each heap memory pool.
Type
VMGCStats
Name
ParNew, ConcurrentMarkSweep
Statistic
collectionTime
Description
Approximate elapsed time that this garbage collector spent doing collections.
Type
LinuxSystemStats
Name
<hostname>
Statistic
pagesSwappedIn, pagesSwappedOut
Description
Number of pages that have been brought into memory from disk or flushed out of memory to disk by the operating system. These paging operations seriously degrade performance.
This VSD chart shows the heap usage in a fabric server plotted against the entry counts in each of the replicated and partitioned tables used in an application. This suggests that heap is growing over time due to an increase in the number of rows in the ORDER_LINE table. Several associated tables are growing in size as well.
This growth can be verified by looking at the bytes used by each of the partitioned tables. The ORDER_LINE table is responsible for most of the heap growth.