卡桑德拉OOM问题的故障诊断与修复

Question

虽然关于OOM问题有多个线程，但是想要澄清某些事情。我们正在运行一个K8版本的36节点Cassandra集群，3.11.6版本，为容器分配了32G。

容器正在被OOM杀死(注意：-不是java堆OOM错误，而是linux cgroup OOM杀手)，因为它的cgroup达到了32 gigs的内存极限。

统计与信任

map[limits:map[ephemeral-storage:2Gi memory:32Gi] requests:map[cpu:7 ephemeral-storage:2Gi memory:32Gi]]

Cgroup内存限制34359738368 -> 32 Gigs

由Cassandra -Xms19660M -Xmx19660M -Xmn4096M自动计算的JVM空间

Grafana截图

卡桑德拉·Yaml -> https://pastebin.com/ZZLTc1cM

JVM选项-> https://pastebin.com/tjzZRZvU

节点上的Nodetool输出，该节点已经消耗了98%的内存。

nodetool info
ID                     : 59c53bdb-4f61-42f5-a42c-936ea232e12d
Gossip active          : true
Thrift active          : true
Native Transport active: true
Load                   : 179.71 GiB
Generation No          : 1643635507
Uptime (seconds)       : 9134829
Heap Memory (MB)       : 5984.30 / 19250.44
Off Heap Memory (MB)   : 1653.33
Data Center            : datacenter1
Rack                   : rack1
Exceptions             : 5
Key Cache              : entries 138180, size 99.99 MiB, capacity 100 MiB, 9666222 hits, 10281941 requests, 0.940 recent hit rate, 14400 save period in seconds
Row Cache              : entries 10561, size 101.76 MiB, capacity 1000 MiB, 12752 hits, 88528 requests, 0.144 recent hit rate, 900 save period in seconds
Counter Cache          : entries 714, size 80.95 KiB, capacity 50 MiB, 21662 hits, 21688 requests, 0.999 recent hit rate, 7200 save period in seconds
Chunk Cache            : entries 15498, size 968.62 MiB, capacity 1.97 GiB, 283904392 misses, 34456091078 requests, 0.992 recent hit rate, 467.960 microseconds miss latency
Percent Repaired       : 8.28107989669628E-8%
Token                  : (invoke with -T/--tokens to see all 256 tokens)

做了什么，

1. 我们已经确保在cassandra进程上没有内存泄漏，因为我们有一个自定义的触发代码。Gc日志分析显示，我们占用了大约14千兆的jvm空间。

问题

虽然我们知道cassandra确实占用了堆空间(Bloom过滤器、Memtables等)

1. grafana截图显示，节点在32 gigs中占98%。JVM堆=19.5gigs+ nodetool输出中的off堆空间= 1653.33 MB (1Ggs ) (JVM堆+off堆= 22吉)。剩下的内存(10 G)在哪里？如何准确地说明占用剩余内存的内容。(和nodetool输出由于抱怨原因不共享)？

我们的生产集群需要大量的批准，因此使用j控制台远程部署它们是很困难的。说明此内存使用情况的任何其他方法。

1. 一旦我们记录了内存的使用情况，接下来有哪些步骤可以解决这个问题，并避免OOM杀死呢？

Answer 1

SSTables很有可能被映射到内存(用mmap()缓存)。如果是这样的话，它就不是即时的，内存的使用将随着时间的推移而增加，这取决于何时读取SSTables，然后缓存它们。我在https://community.datastax.com/questions/6947/上写过这个问题。

存在一个名为“磁盘访问模式”的不知名配置属性的问题。如果没有将其设置为cassandra.yaml，则默认为mmap，这意味着所有SSTables都将mmap编辑到内存中。如果是这样的话，您将在启动时在system.log中看到一个条目，如下所示：

INFO  [main] 2019-05-02 12:33:21,572  DatabaseDescriptor.java:350 - \
  DiskAccessMode 'auto' determined to be mmap, indexAccessMode is mmap

解决方案是将磁盘访问模式配置为只缓存SSTable索引文件(而不是*-Data.db组件)，方法是设置：

disk_access_mode: mmap_index_only

有关更多信息，请参阅我上面发布的链接。干杯!