Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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. Este recurso permite 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
O Azure dá suporte a três zonas de disponibilidade na maioria das regiões. A Instância Gerenciada do Azure para Apache Cassandra mapeia zonas de disponibilidade para racks. Recomendamos que você escolha uma chave de partição com alta cardinalidade para evitar partições quentes. 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.
O Azure usa um RAID 0 sobre o número de discos provisionados. Para obter as IOPS ideais, verifique as IOPS máximas na SKU escolhida 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. 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 para SKUs com apenas oito núcleos. Nossa pesquisa mostra que oito CPUs principais só funcionam para as cargas de trabalho menos exigentes. 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. Para obter mais informações sobre como aplicar essas configurações, consulte Atualizar a configuração do Cassandra.
Tempos limite
| Valor | Cassandra MI Padrão | Recomendação para carga de trabalho analítica |
|---|---|---|
| tempo_de_expiração_do_pedido_de_leitura_em_ms | 5.000 | 10.000 |
| range_request_timeout_em_ms (tempo limite de pedido de intervalo em ms) | 10.000 | 20.000 |
| tempo_limite_para_escrita_de_requisição_em_ms | 5.000 | 10.000 |
| cas_contention_timeout_in_ms (tempo limite de contenção cas em ms) | 1,000 | 2.000 |
| tempo_limite_de_pedido_em_ms | 60 000 | 120 000 |
| tempo_limite_de_registo_de_consulta_lenta_em_ms | 500 | 1,000 |
| validade_das_funções_em_ms | 2.000 | 120 000 |
| validade_das_permissões_em_ms | 2.000 | 120 000 |
Caches
| Valor | Cassandra MI Padrão | Recomendação para carga de trabalho analítica |
|---|---|---|
| tamanho_da_cache_de_ficheiro_em_mb | 2,048 | 6,144 |
Mais recomendações
| Valor | Cassandra MI Padrão | Recomendação para carga de trabalho analítica |
|---|---|---|
| commitlog_espaço_total_em_MB | 8,192 | 16,384 |
| tamanho_da_matriz_de_colunas_em_kb | 64 | 16 |
| taxa_de_compactação_mb_por_segundo | 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 habilitar a política neste exemplo.
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, o que se manifesta em múltiplos timeouts dos clientes. Nesse cenário, recomendamos que você execute as seguintes ações:
- Escalone verticalmente para um SKU com mais núcleos de CPU, especialmente se o número de núcleos for 8 ou menos.
- Escale horizontalmente ao adicionar 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, que precisa de mais investigação.
Nota
A alteração da SKU é suportada usando o portal do Azure, a CLI do Azure e a implantação de modelo ARM. Você pode implantar ou editar um modelo ARM e substituir SKU por um dos seguintes valores:
- 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
Atualmente, não suportamos a transição entre famílias SKU. Por exemplo, se atualmente possui um Standard_DS13_v2 e deseja atualizar para um SKU maior, como um Standard_DS14_v2, essa 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 geridos do Azure P30, que permitem IOPS de rajada. É 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, talvez seja necessário aumentar a escala.
- Consistentemente maior ou igual à 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 o IOPS dos discos gerenciados. Este valor é o limite superior para o 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 IOPSs forem inferiores às suportadas pela SKU, 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 dos data centers adicionando mais nós.
Se o seu IOPS exceder o máximo que o seu SKU suporta, você pode:
- Aumente para uma SKU diferente que suporta mais IOPS.
- Aumente a escala dos data centers adicionando mais nós.
Para obter mais informações, consulte Desempenho de máquina virtual e disco.
Desempenho da rede
Na maioria dos casos, o desempenho da rede é suficiente. No entanto, se estiver frequentemente a transmitir dados, como aumento/redução frequente de escala horizontal, ou se houver grandes movimentos de dados de entrada e saída, esse desempenho pode tornar-se um problema. Talvez seja necessário avaliar o desempenho de rede da sua SKU. Por exemplo, o Standard_DS14_v2 SKU suporta 12.000 Mb/s. Compare esse valor 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 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
Você deve planejar e provisionar implantações 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 essa situação não exceda os limites toleráveis.
Espaço em disco
Na maioria dos casos, há espaço em disco suficiente. As implantações padrão são otimizadas para IOPS, o que leva a uma baixa utilização do disco. No entanto, recomendamos rever ocasionalmente as métricas de espaço em disco. Cassandra acumula vários discos e depois reduz-os quando a compactação é acionada. É 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 apenas observar esse comportamento em alguns nós, pode ter uma partição quente e precisar revisar seus padrões de distribuição e acesso de dados para identificar uma possível discrepância.
- Adicione mais discos, mas esteja atento aos limites de IOPS impostos pelo seu SKU
- Expandir horizontalmente o cluster
Memória JVM
Nossa fórmula padrão atribui metade da memória da máquina virtual à JVM (Jave Virtual Machine) com um limite superior de 31 GB. Na maioria dos casos, essa abordagem é 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. Mais memória JVM pode ser necessária se você estiver em uma 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 o Reaper, que remove linhas cujo TTL expirou, chamadas de lápides. Algumas cargas de trabalho excluem com mais frequência e mostram avisos, como Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) nos logs da 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 são satisfeitas, é aumentar a tombstone_failure_threshold na configuração Cassandra a partir do padrão de 100.000 para um valor mais alto.
Também recomendamos que você revise o TTL no keyspace e, potencialmente, execute 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 que você revise a estratégia de compactação e favoreça Leveled Compaction Strategyo . Em alguns casos, essas ações podem indicar 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.
Nesse caso, você deve revisar 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>
Esta mensagem indica um problema no modelo de dados. Para obter mais informações, consulte este artigo sobre o Stack Overflow. Esse problema 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. 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
O padrão é utilizar 1/4 da memória heap da JVM para memtable_heap_space no cassandra.yaml. Para aplicações orientadas para escrita e/ou em SKUs com memória pequena, este problema pode levar a descargas frequentes e fragmentadas sstables, que requerem mais compactação. Nesses casos, aumentá-lo para pelo menos 4048 pode ser bom. Essa abordagem requer uma avaliação comparativa cuidadosa para garantir que outras operações, por exemplo, leituras, não sejam afetadas.