Práticas recomendadas para um desempenho ideal
A Instância Gerenciada do Azure para Apache Cassandra é um serviço totalmente gerenciado para clusters Apache Cassandra de código aberto puro. O serviço também permite que as configurações sejam substituídas, dependendo das necessidades específicas de cada carga de trabalho, permitindo a máxima flexibilidade e controle onde necessário. Este artigo fornece dicas sobre como otimizar o desempenho.
Instalação e configuração ideais
Fator de replicação, número de discos, número de nós e SKUs
Como o Azure dá suporte a três zonas de disponibilidade na maioria das regiões e a Instância Gerenciada Cassandra mapeia zonas de disponibilidade para racks, recomendamos escolher uma chave de partição com alta cardinalidade para evitar partições ativas. Para obter o melhor nível de confiabilidade e tolerância a falhas, é altamente recomendável configurar um fator de replicação de 3. Também recomendamos especificar um múltiplo do fator de replicação como o número de nós, por exemplo, 3, 6, 9, etc.
Usamos um RAID 0 sobre o número de discos provisionados. Portanto, para obter as IOPS ideais, você precisa verificar as IOPS máximas na SKU que você escolheu juntamente com as IOPS de um disco P30. Por exemplo, o Standard_DS14_v2 SKU suporta 51.200 IOPS não armazenadas em cache, enquanto um único disco P30 tem um desempenho básico de 5.000 IOPS. Assim, quatro discos levariam a 20.000 IOPS, o que está bem abaixo dos limites da máquina.
Recomendamos vivamente uma análise comparativa extensiva da sua carga de trabalho em relação à SKU e ao número de discos. O benchmarking é especialmente importante no caso de SKUs com apenas oito núcleos. Nossa pesquisa mostra que oito CPUs principais só funcionam para as cargas de trabalho menos exigentes, e a maioria das cargas de trabalho precisa de um mínimo de 16 núcleos para ter desempenho.
Cargas de trabalho analíticas vs. transacionais
As cargas de trabalho transacionais normalmente precisam de um data center otimizado para baixa latência, enquanto as cargas de trabalho analíticas geralmente usam consultas mais complexas, que levam mais tempo para serem executadas. Na maioria dos casos, você desejaria centros de dados separados:
- Um otimizado para baixa latência
- Um otimizado para cargas de trabalho analíticas
Otimização para cargas de trabalho analíticas
Recomendamos que os clientes apliquem as seguintes cassandra.yaml configurações para cargas de trabalho analíticas (veja aqui como se candidatar).
Tempos limite
| Value | Cassandra MI Padrão | Recomendação para carga de trabalho analítica |
|---|---|---|
| read_request_timeout_in_ms | 5,000 | 10,000 |
| range_request_timeout_in_ms | 10,000 | 20.000 |
| counter_write_request_timeout_in_ms | 5,000 | 10.000 |
| cas_contention_timeout_in_ms | 1,000 | 2.000 |
| truncate_request_timeout_in_ms | 60,000 | 120 000 |
| slow_query_log_timeout_in_ms | 500 | 1,000 |
| roles_validity_in_ms | 2,000 | 120 000 |
| permissions_validity_in_ms | 2,000 | 120 000 |
Caches
| Value | Cassandra MI Padrão | Recomendação para carga de trabalho analítica |
|---|---|---|
| file_cache_size_in_mb | 2,048 | 6,144 |
Mais recomendações
| Value | Cassandra MI Padrão | Recomendação para carga de trabalho analítica |
|---|---|---|
| commitlog_total_space_in_mb | 8,192 | 16,384 |
| column_index_size_in_kb | 64 | 16 |
| compaction_throughput_mb_per_sec | 128 | 256 |
Definições do cliente
Recomendamos aumentar os tempos limite do driver do cliente Cassandra de acordo com os tempos limite aplicados no servidor.
Otimização para baixa latência
Nossas configurações padrão já são adequadas para cargas de trabalho de baixa latência. Para garantir o melhor desempenho para latências finais, é altamente recomendável usar um driver de cliente que suporte a execução especulativa e configurar seu cliente de acordo. Para o driver Java V4, você pode encontrar uma demonstração ilustrando como isso funciona e como ativar a política aqui.
Monitoramento de gargalos de desempenho
Desempenho da CPU
Como todo sistema de banco de dados, Cassandra funciona melhor se a utilização da CPU é de cerca de 50% e nunca fica acima de 80%. Você pode visualizar as métricas da CPU na guia Métricas em Monitoramento do portal:
Gorjeta
Para uma visualização realista da CPU, adicione um filtro e divida a propriedade por Usage kind=usage_idle. Se esse valor for inferior a 20%, você poderá aplicar a divisão para obter o uso por todos os tipos de uso.
Se a CPU estiver permanentemente acima de 80% para a maioria dos nós, o banco de dados ficará sobrecarregado, manifestando-se em vários tempos limite do cliente. Nesse cenário, recomendamos executar as seguintes ações:
- dimensionar verticalmente para uma SKU com mais núcleos de CPU (especialmente se os núcleos forem apenas 8 ou menos).
- dimensionar horizontalmente adicionando mais nós (como mencionado anteriormente, o número de nós deve ser múltiplo do fator de replicação).
Se a CPU é alta apenas para alguns nós, mas baixa para os outros, isso indica uma partição quente e precisa de mais investigação.
Nota
A alteração de SKU é suportada por meio do Portal do Azure, da CLI do Azure e da implantação de modelo ARM. Você pode implantar/editar o modelo ARM e substituir o SKU por um dos seguintes.
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
- Standard_L8s_v3
- Standard_L16s_v3
- Standard_L32s_v3
- Standard_L8as_v3
- Standard_L16as_v3
- Standard_L32as_v3
Observe que, atualmente, não suportamos a transição entre famílias de SKU. Por exemplo, se você possui atualmente um Standard_DS13_v2 e está interessado em atualizar para um SKU maior, como Standard_DS14_v2, esta opção não está disponível. No entanto, você pode abrir um tíquete de suporte para solicitar uma atualização para a SKU mais alta.
Desempenho do disco
O serviço é executado em discos gerenciados do Azure P30, que permitem "IOPS de intermitência". É necessário um monitoramento cuidadoso quando se trata de gargalos de desempenho relacionados ao disco. Neste caso, é importante rever as métricas IOPS:
Se as métricas mostrarem uma ou todas as características a seguir, isso pode indicar que você precisa aumentar a escala.
- Consistentemente maior ou igual ao IOPS base (lembre-se de multiplicar 5.000 IOPS pelo número de discos por nó para obter o número).
- Consistentemente maior ou igual ao IOPS máximo permitido para o SKU para gravações.
- Sua SKU suporta armazenamento em cache (write-through-cache) e esse número é menor do que as IOPS dos discos gerenciados (esse será o limite superior para suas IOPS de leitura).
Se você vir o IOPS elevado apenas para alguns nós, poderá ter uma partição ativa e precisar revisar seus dados para uma possível inclinação.
Se as IOPS forem inferiores às suportadas pela SKU escolhida, mas superiores ou iguais às IOPS do disco, pode executar as seguintes ações:
- Adicione mais discos para aumentar o desempenho. O aumento de discos requer um caso de suporte a ser gerado.
- Aumente a escala do(s) datacenter(s) adicionando mais nós.
Se o seu IOPS exceder o máximo que o seu SKU suporta, você pode:
- escale para uma SKU diferente suportando mais IOPS.
- Aumente a escala do(s) datacenter(s) adicionando mais nós.
Para obter mais informações, consulte Máquina virtual e desempenho do disco.
Desempenho da rede
Na maioria dos casos, o desempenho da rede é suficiente. No entanto, se você estiver transmitindo dados com frequência (como escala/redução horizontal frequente) ou se houver grandes movimentos de dados de entrada/saída, isso pode se tornar um problema. Pode ser necessário avaliar o desempenho de rede do seu SKU. Por exemplo, o Standard_DS14_v2 SKU suporta 12.000 Mb/s, compare isso com o byte-in/out nas métricas:
Se você vir a rede elevada apenas para alguns nós, talvez tenha uma partição ativa e precise revisar seus padrões de distribuição e/ou acesso de dados para uma possível inclinação.
- Dimensione verticalmente para uma SKU diferente, suportando mais E/S de rede.
- Aumente horizontalmente a escala do cluster adicionando mais nós.
Demasiados clientes ligados
As implantações devem ser planejadas e provisionadas para dar suporte ao número máximo de solicitações paralelas necessárias para a latência desejada de um aplicativo. Para uma determinada implantação, a introdução de mais carga no sistema acima de um limite mínimo aumenta a latência geral. Monitore o número de clientes conectados para garantir que isso não exceda os limites toleráveis.
Espaço em disco
Na maioria dos casos, há espaço em disco suficiente, pois as implantações padrão são otimizadas para IOPS, o que leva à baixa utilização do disco. No entanto, aconselhamos ocasionalmente a revisão das métricas de espaço em disco. Cassandra acumula muitos discos e depois reduz-os quando a compactação é acionada. Por isso, é importante revisar o uso do disco por períodos mais longos para estabelecer tendências - como compactação incapaz de recuperar espaço.
Nota
Para garantir espaço disponível para compactação, a utilização do disco deve ser mantida em cerca de 50%.
Se você vir esse comportamento apenas para alguns nós, talvez tenha uma partição ativa e precise revisar seus padrões de distribuição e/ou acesso de dados para uma possível inclinação.
- adicione mais discos, mas esteja atento aos limites de IOPS impostos pela sua SKU
- Dimensionar horizontalmente o cluster
Memória JVM
Nossa fórmula padrão atribui metade da memória da VM à JVM com um limite superior de 31 GB - o que, na maioria dos casos, é um bom equilíbrio entre desempenho e memória. Algumas cargas de trabalho, especialmente aquelas que têm leituras frequentes entre partições ou varreduras de intervalo podem ser desafiadas pela memória.
Na maioria dos casos, a memória é recuperada efetivamente pelo coletor de lixo Java, mas especialmente se a CPU estiver frequentemente acima de 80%, não há ciclos de CPU suficientes para o coletor de lixo restante. Portanto, quaisquer problemas de desempenho da CPU devem ser resolvidos antes dos problemas de memória.
Se a CPU pairar abaixo de 70% e a coleta de lixo não conseguir recuperar memória, talvez você precise de mais memória JVM. Este é especialmente o caso se você estiver em um SKU com memória limitada. Na maioria dos casos, você precisa revisar suas consultas e configurações do cliente e reduzir fetch_size junto com o que é escolhido em limit sua consulta CQL.
Se você realmente precisa de mais memória, você pode:
- Registre um ticket para que possamos aumentar as configurações de memória da JVM para você
- Dimensionar verticalmente para uma SKU que tenha mais memória disponível
Lápides
Realizamos reparos a cada sete dias com ceifador, que remove linhas cujo TTL expirou (chamado de "lápide"). Algumas cargas de trabalho têm exclusões mais frequentes e veem avisos como Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) nos logs de Cassandra, ou até mesmo erros indicando que uma consulta não pôde ser atendida devido ao excesso de lápides.
Uma mitigação de curto prazo se as consultas não forem atendidas é aumentar a tombstone_failure_threshold configuração Cassandra do padrão 100.000 para um valor mais alto.
Além disso, recomendamos rever o TTL no espaço de chaves e, potencialmente, executar reparos diariamente para limpar mais lápides. Se os TTLs forem curtos, por exemplo, menos de dois dias, e os dados entrarem e forem excluídos rapidamente, recomendamos rever a estratégia de compactação e favorecer o Leveled Compaction Strategy. Em alguns casos, tais ações podem ser uma indicação de que é necessária uma revisão do modelo de dados.
Avisos de lote
Você pode encontrar esse aviso no CassandraLogs e falhas potencialmente relacionadas:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Neste caso, deve rever as suas consultas para ficar abaixo do tamanho de lote recomendado. Em casos raros e como uma mitigação de curto prazo, você pode aumentar batch_size_fail_threshold_in_kb na configuração Cassandra do padrão de 50 para um valor mais alto.
Aviso de partição grande
Você pode encontrar este aviso no CassandraLogs:
Writing large partition <table> (105.426MiB) to sstable <file>
Isso indica um problema no modelo de dados. Aqui está um artigo de estouro de pilha que entra em mais detalhes. Isso pode causar sérios problemas de desempenho e precisa ser resolvido.
Otimizações especializadas
Compressão
Cassandra permite a seleção de um algoritmo de compressão apropriado quando uma tabela é criada (consulte Compressão) O padrão é LZ4, que é excelente para taxa de transferência e CPU, mas consome mais espaço no disco. Usando Zstd (Cassandra 4.0 e superior) economiza cerca de ~ 12% de espaço com sobrecarga mínima de CPU.
Otimizando o espaço de pilha do memtable
Nosso padrão é usar 1/4 da pilha da JVM para memtable_heap_space no cassandra.yaml. Para aplicações orientadas para escrita e/ou em SKUs com memória pequena, isso pode levar a descargas frequentes e fragmentados, exigindo assim mais compactação. Nesses casos, o aumento para pelo menos 4048 pode ser benéfico, mas requer uma avaliação comparativa cuidadosa para garantir que outras operações (por exemplo, leituras) não sejam afetadas.
Próximos passos
Neste artigo, apresentamos algumas práticas recomendadas para um desempenho ideal. Agora você pode começar a trabalhar com o cluster: