Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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 camadas de produto
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 que você especifique um múltiplo do fator de replicação como o número de nós. Por exemplo, use 3, 6, 9, etc.
O Azure usa um RAID 0 sobre o número de discos provisionados. Para obter as IOPS (operações de entrada/saída por segundo) ideais, verifique as IOPS máximas na camada de produto que você escolheu juntamente com as IOPS de um disco P30. Por exemplo, a camada de Standard_DS14_v2 produto suporta 51.200 IOPS não armazenadas em cache. Um único disco P30 tem um desempenho básico de 5.000 IOPS. Quatro discos levam 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 à camada de produto e ao número de discos. O benchmarking é especialmente importante para níveis de produtos com apenas oito núcleos. Nossa pesquisa mostra que CPUs de oito núcleos funcionam apenas para as cargas de trabalho menos exigentes. A maioria das cargas de trabalho precisa de um mínimo de 16 núcleos para funcionar corretamente.
Cargas de trabalho analíticas vs. transacionais
As cargas de trabalho transacionais normalmente precisam de um datacenter otimizado para baixa latência. As cargas de trabalho analíticas geralmente usam consultas mais complexas, que levam mais tempo para serem executadas. Na maioria dos casos, você deseja datacenters separados com:
- Um otimizado para baixa latência.
- Uma solução otimizada para cargas de trabalho analíticas.
Otimizar para cargas de trabalho analíticas
Recomendamos que você aplique 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 |
|---|---|---|
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
| Valor | Cassandra MI padrão | Recomendação para carga de trabalho analítica |
|---|---|---|
file_cache_size_in_mb |
2,048 | 6,144 |
Mais recomendações
| Valor | 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 que você aumente os tempos limite do driver do cliente Cassandra de acordo com os tempos limite aplicados no servidor.
Otimizar 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 que você use um driver de cliente que suporte a execução especulativa e que configure seu cliente de acordo. Para um driver Java V4, uma demonstração ilustra como esse processo funciona e como habilitar a política neste exemplo.
Monitore 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%. Para exibir métricas da CPU, no portal do Azure, na seção Monitoramento , abra a guia Métricas .
Para uma visualização realista da CPU, adicione um filtro e use Usage kind=usage_idle para dividir a propriedade. Se este valor for inferior a 20%, aplique o método de divisão para distribuir entre 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:
- Escale verticalmente para uma camada de produto com mais núcleos de CPU, especialmente se os núcleos forem apenas 8 ou menos.
- Escale horizontalmente ao adicionar mais nós. Como mencionado anteriormente, o número de nós deve ser um múltiplo do fator de replicação.
Se a CPU estiver alta para apenas alguns nós, mas baixa para os outros, isso indica uma partição quente. Este cenário carece de uma investigação mais aprofundada.
A alteração da camada de produto é suportada usando o portal do Azure, a CLI do Azure e a implantação do modelo do Azure Resource Manager (modelo ARM). Você pode implantar ou editar um modelo ARM e substituir a camada de produto por um dos seguintes valores:
Standard_E8s_v4Standard_E16s_v4Standard_E20s_v4Standard_E32s_v4Standard_DS13_v2Standard_DS14_v2Standard_D8s_v4Standard_D16s_v4Standard_D32s_v4Standard_L8s_v3Standard_L16s_v3Standard_L32s_v3Standard_L8as_v3Standard_L16as_v3Standard_L32as_v3
Atualmente, não suportamos a transição entre famílias de produtos. Por exemplo, se atualmente possui um Standard_DS13_v2 e deseja fazer upgrade para um produto maior, como Standard_DS14_v2, essa opção não está disponível. Abra um pedido de suporte para solicitar uma atualização para o produto de nível superior.
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. Nesse caso, é importante revisar as métricas de IOPS.
Se as métricas mostrarem uma ou todas as seguintes características, talvez seja necessário aumentar a escala:
- Suas métricas são consistentemente maiores ou iguais ao IOPS base. Lembre-se de multiplicar 5.000 IOPS pelo número de discos por nó para obter o número.
- As suas métricas são consistentemente superiores ou iguais ao limite máximo de IOPS permitido para a classe de produto em operações de escrita.
- Sua camada de produto oferece suporte ao armazenamento em cache (cache write-through), e esse número é menor do que as IOPS dos discos gerenciados. Este valor é o limite superior para o IOPS de leitura.
Se vir o IOPS elevado apenas em alguns nós, poderá ter uma partição sobrecarregada e precisar rever os seus dados para um possível desequilíbrio.
Se as IOPSs forem inferiores às suportadas pela camada de produto, mas superiores ou iguais às IOPS do disco, execute as seguintes ações:
- Adicione mais nós para aumentar a escala dos datacenters.
Se as IOPS atingirem o limite superior suportado pela camada de produto, você poderá:
- Escale para uma camada de produto diferente que ofereça suporte a mais IOPS.
- Adicione mais nós para aumentar a escala dos datacenters.
Para obter mais informações, consulte Desempenho de máquina virtual e disco.
Desempenho da rede
Normalmente, o desempenho da rede é suficiente. Se você fizer streaming de dados frequentemente, como aumento/redução horizontal de escala frequente, ou se houver grandes movimentos de entrada/saída de dados, esse desempenho pode se tornar um problema. Talvez seja necessário avaliar o desempenho da rede da camada de produto. Por exemplo, a camada do produto Standard_DS14_v2 suporta 12.000 Mb/s. Compare esse valor com o byte-in/out nas métricas.
Se vir a rede elevada para apenas alguns nós, poderá ter uma partição quente. Analise seus padrões de distribuição e acesso de dados para uma possível distorção.
- Escale verticalmente para uma camada de produto diferente, oferecendo suporte a mais E/S de rede.
- Aumente horizontalmente a escala do cluster adicionando mais nós.
Demasiados clientes ligados
Planeje e provisione 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 implantação específica, 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 que você ocasionalmente revise as métricas de espaço em disco. Cassandra acumula vários discos e depois os reduz quando a compactação é acionada. É importante revisar o uso do disco por períodos mais longos para estabelecer tendências, como quando a compactação não consegue recuperar espaço.
Nota
Para garantir espaço disponível para compactação, mantenha a utilização do disco em cerca de 50%.
Se você vir esse comportamento para apenas alguns nós, você pode ter uma partição quente. Analise seus padrões de distribuição e acesso de dados para uma possível distorção.
- Adicione mais discos, mas esteja atento aos limites de IOPS impostos pela sua camada de produto.
- Aumente horizontalmente a capacidade do cluster.
Memória JVM
Nossa fórmula padrão atribui metade da memória da máquina virtual à Java Virtual Machine (JVM) 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 verificações de intervalo, podem ter restrições de memória.
Na maioria dos casos, a memória é recuperada efetivamente pelo coletor de lixo Java. Se a CPU estiver frequentemente acima de 80%, não sobram ciclos de CPU suficientes para o coletor de lixo. Resolva os problemas de desempenho da CPU antes de verificar quaisquer problemas de memória.
Se a CPU pairar abaixo de 70% e a coleta de lixo não puder recuperar memória, talvez você precise de mais memória JVM. Mais memória JVM pode ser necessária se você estiver em uma camada de produto com memória limitada. Na maioria dos casos, é necessário revisar as suas consultas e configurações do cliente e reduzir fetch_size, juntamente com o que for selecionado em limit, na sua consulta de Cassandra Query Language (CQL).
Se precisar de mais memória, pode:
- Dimensione verticalmente para uma camada de produto que tenha mais memória disponível.
Lápides
Realizamos reparações a cada sete dias com o Reaper, que remove linhas cujo tempo de vida (TTL) expirou. Estas fileiras são chamadas 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. Alguns erros indicam que uma consulta não pôde ser atendida devido ao excesso de lápides.
Uma atenuação de curto prazo se as consultas não forem atendidas é aumentar o tombstone_failure_threshold valor na configuração Cassandra do padrão 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 o seguinte aviso em CassandraLogs e falhas potencialmente relacionadas:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Revise suas consultas para ficar abaixo do tamanho de lote recomendado. Em casos raros e como mitigação de curto prazo, aumente batch_size_fail_threshold_in_kb na configuração Cassandra do valor padrão de 50 para um valor mais alto.
Aviso de partição grande
Você pode encontrar o seguinte aviso em 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 Stack Overflow. Esse problema pode causar sérios problemas de desempenho e deve 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. Usar Zstandard (Cassandra 4.0 e posterior) permite uma poupança de espaço de cerca de 12% com uma sobrecarga mínima de CPU.
Otimize o espaço de memória do memtable
O padrão é utilizar um quarto do heap da JVM para memtable_heap_space no arquivo cassandra.yaml. Para aplicativos orientados a gravação ou em camadas de produto com pequenas quantidades de memória, esse problema pode levar a descargas frequentes e fragmentadas sstables, que exigem mais compactação. Aumentar para pelo menos 4.048 pode ser bom. Essa abordagem requer uma avaliação comparativa cuidadosa para garantir que outras operações (por exemplo, leituras) não sejam afetadas.