Por que os nós aumentaram o uso de memória após a atualização do Cassandra?

Sintomas

Usuários relataram problemas de desempenho não observados quando os clusters estavam sendo executados com o Cassandra 2.1. Logo após a atualização para o Cassandra 2.2 ou 3.x, os nós apresentam problemas apesar de fatores como carga do aplicativo, tráfego do cluster, padrões de acesso, hora do dia/semana/mês e recursos de hardware/rede serem iguais.

Os sintomas incluem:

• Aumento significativo no uso de memória off-heap (por exemplo, quando monitorado usando utilitários Linux como topou sar).
• Aumento de P99 e/ou latências máximas de leitura (como da nodetool tablehistogramssaída).
• Tempos limite de solicitação de leitura intermitentes em situações extremas.

Em um caso raro, o Cassandra iniciado em um nó não consegue concluir a sequência de inicialização porque a maior parte da memória é consumida muito rapidamente e eventualmente se esgota, então o Linux oom-killerencerra o processo do Cassandra.

Causa

O Apache Cassandra usa E/S de arquivo mapeado na memória por meio da chamada de sistema Unix mmap()(ou mmappara abreviar). A chamada de sistema mmap permite que o Cassandra use a memória virtual do sistema operacional para armazenar cópias de arquivos de dados, de modo que a leitura de SSTables seja rápida. Uma propriedade oculta cassandra.yamlchamada disk_access_modedetermina como os arquivos de dados são acessados. As opções válidas são:

• auto(padrão) - tanto os dados SSTable quanto os arquivos de índice são mapeados em sistemas de 64 bits; somente os arquivos de índice são mapeados para sistemas de 32 bits
• mmap- ambos os arquivos de dados e índice são mapeados para a memória
• mmap_index_only- somente arquivos de índice são mapeados para a memória
• standard- Cassandra usa IO padrão e nenhum arquivo é mapeado para a memória

Nas versões do Cassandra 2.1 ou anteriores, a leitura de SSTables compactadas envolvia os dados sendo copiados no heap e então enviados para um buffer no heap para serem descompactados e se comportando como se o modo de acesso ao disco estivesse definido, mmap_index_onlyapesar do modo padrão ser auto.

Com o suporte adicional para descompressão direta de buffer no Cassandra 2.2 ( CASSANDRA-8464 ), o comportamento do modo de acesso ao disco mudou para a forma como foi projetado, ou seja, o automodo padrão em sistemas de 64 bits agora mmap()inclui dados SSTable e arquivos de índice.

Em casos em que há muitas leituras aleatórias, e o conjunto de SSTables sendo lido intensamente é maior do que a memória disponível, os nós afetados terão um alto número de falhas de página. Em alguns casos, os servidores afetados ficam sem memória e o Linux oom-killerencerra o Cassandra.

Solução

Como o CASSANDRA-8464 permite mapear dados compactados diretamente, é mais eficiente mapear apenas arquivos de índice.

Com o padrão disk_access_mode: autodurante a inicialização, o Cassandra registra uma entrada semelhante a esta:

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

Definido disk_access_modepara :mmap_index_only​cassandra.yaml

disk_access_mode: mmap_index_only

Após reiniciar o Cassandra, uma entrada nos logs será semelhante a:

INFO [main] 2019-05-02 17:53:50,437 DatabaseDescriptor.java:356 - \
  DiskAccessMode is standard, indexAccessMode is mmap

Esta entrada de log indica que os arquivos de dados SSTable são usados ​​com E/S de disco padrão, mas os arquivos de índice serão mapeados para a memória.

Créditos

• Branimir Lambov
• Jake Luciani
• Marca Curtis
• Michael Keeney
• Stefania Alborghetti
• Thanh Tranh
• Wei Deng

Esta postagem foi republicada do artigo da Base de conhecimento de suporte do DataStax Aumento do uso de memória em nós após a atualização para o DSE 5.0 ou DSE 5.1 ​​e a Comunidade DataStax (retirado em preferência para a Rede Stack Exchange).