Устранение неполадок и устранение проблемы Cassandra OOM

Хотя есть несколько тем, касающихся проблемы OOM, хотелось бы прояснить некоторые вещи. Мы запускаем кластер Cassandra из 36 узлов версии 3.11.6 в K8 с 32 гигабайтами, выделенными для контейнера.

Контейнер уничтожается OOM (Примечание: не ошибка OOM кучи java, а убийца OOM cgroup linux), поскольку он достигает предела памяти в 32 гигабайта для своей cgroup.

Статистика и конфиги

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

Ограничение памяти группы 34359738368 -> 32 Gigs

Пространства JVM, автоматически рассчитанные Cassandra -Xms19660M -Xmx19660M -Xmn4096M

Графана Скриншот

Кассандра Ямл --> 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 log аналитика показывает, что мы занимаем примерно 14 гигабайт всего пространства jvm.

Вопросы

Хотя мы знаем, что cassandra занимает места вне кучи (фильтр Блума, Memtables и т. д.)

1. Скриншот grafana показывает, что узел занимает 98% из 32 гигабайт. Куча JVM = 19,5 гигабайта + пространство вне кучи в выходной информации nodetool = 1653,33 МБ (1 гигабайт) (куча JVM + вне кучи = 22 гигабайта). Где остальная память (10 гигов)?. Как точно учитывать, что занимает оставшуюся память. (Выходные данные Nodetool tablestats и nodetool cfstats не используются совместно по причинам жалобы)?

Наш производственный кластер требует большого количества разрешений, поэтому развертывание их с помощью jconsole remote затруднено. Любые другие способы учета этого использования памяти.

2. Как только мы учтем использование памяти, каковы следующие шаги, чтобы исправить это и избежать уничтожения OOM?