Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A Instância Gerenciada do Azure para Apache Cassandra é um serviço totalmente gerenciado para clusters puros de código aberto do Apache Cassandra. O serviço também permite que as configurações sejam substituídas, dependendo das necessidades específicas de cada carga de trabalho. Esse recurso permite a máxima flexibilidade e controle quando 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 que você provisiona. Para obter as operações de entrada/saída ideais por segundo (IOPS), verifique o IOPS máximo no nível do produto que você escolheu, juntamente com o IOPS de um disco P30. Por exemplo, a camada de Standard_DS14_v2 produto dá suporte a 51.200 IOPS não armazenados em cache. Um único disco P30 tem um desempenho base de 5.000 IOPS. Quatro discos levam a 20.000 IOPS, que está bem abaixo dos limites do computador.
É altamente recomendável realizar testes abrangentes de sua carga de trabalho em relação à camada de produto e ao número de discos. O benchmarking é especialmente importante para camadas de produto com apenas oito núcleos. Nossa pesquisa mostra que as CPUs de oito núcleos funcionam apenas para as cargas de trabalho menos exigentes. A maioria das cargas de trabalho precisa de, no mínimo, 16 núcleos para serem executadas corretamente.
Cargas de trabalho transacionais versus analíticas
Normalmente, as cargas de trabalho transacionais 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 versã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 | Padrão de MI do Cassandra | 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 | Padrão de MI do Cassandra | Recomendação para carga de trabalho analítica |
|---|---|---|
file_cache_size_in_mb |
2,048 | 6.144 |
Mais recomendações
| Valor | Padrão de MI do Cassandra | 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 |
Configurações de cliente
Recomendamos que você aumente os tempos limite de driver de cliente do 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 traseiras, é altamente recomendável que você use um driver cliente que dê suporte à execução especulativa e que configure seu cliente adequadamente. Para um driver Java V4, uma demonstração ilustra como esse processo funciona e como habilitar a política neste exemplo.
Monitorar gargalos de desempenho
Desempenho da CPU
Como todo sistema de banco de dados, o Cassandra funciona melhor se a utilização da CPU estiver em torno de 50% e nunca ultrapassar 80%. Para exibir as métricas de CPU, no portal do Azure, na seção Monitoramento , abra a guia Métricas .
Para uma exibição de CPU realista, adicione um filtro e use Usage kind=usage_idle para dividir a propriedade. Se esse valor for inferior a 20%, aplique 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, resultando em vários timeouts no cliente. Nesse cenário, recomendamos que você execute as seguintes ações:
- Escalar verticalmente até uma camada de produto com mais núcleos de CPU, especialmente se os núcleos forem apenas 8 ou menos.
- Escalone horizontalmente adicionando mais nós. Conforme mencionado anteriormente, o número de nós deve ser um múltiplo do fator de replicação.
Se o uso de CPU for alto para apenas alguns nós e baixo para os demais, isso indica uma partição quente. Esse cenário precisa de uma investigação mais aprofundada.
A alteração da camada de produto é suportada pelo uso do portal do Azure, da CLI do Azure e da implantação do modelo do Azure Resource Manager (ARM template). Você pode implantar ou editar um modelo do ARM e substituir a camada do 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 damos suporte à transição entre famílias de produtos. Por exemplo, se você atualmente possui um Standard_DS13_v2 e deseja atualizar para um produto maior, como Standard_DS14_v2, essa opção não está disponível. Abra um tíquete de suporte para solicitar uma atualização para o produto mais recente.
Desempenho do disco
O serviço é executado em discos gerenciados do Azure P30, que permitem IOPS dinâmicos. O monitoramento cuidadoso é necessário quando se trata de gargalos de desempenho relacionados ao disco. Nesse caso, é importante examinar as métricas de IOPS.
Se as métricas mostrarem uma ou todas as seguintes características, talvez seja necessário escalar verticalmente:
- 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.
- Suas métricas são consistentemente maiores ou iguais ao máximo de IOPS permitido para a camada de produto para gravações.
- Sua camada de produto dá suporte ao armazenamento em cache (cache de escrita), e esse número é menor que o IOPS dos discos gerenciados. Esse valor é o limite superior para o IOPS de leitura.
Se você vir o IOPS elevado para apenas alguns nós, talvez você tenha uma partição ativa e precise examinar os seus dados para obter uma possível distorção.
se as IOPS forem menores do que o que sua camada de produto suporta, mas maiores ou iguais às IOPS de disco, execute as seguintes ações:
- Adicione mais nós para ampliar os datacenters.
Se o IOPS atingir o limite superior compatível com a camada de produto, você poderá:
- Escalar verticalmente para uma camada de produto diferente que dê suporte a mais IOPS.
- Adicione mais nós para escalar verticalmente os datacenters.
Para obter mais informações, consulte o desempenho da máquina virtual e do disco.
Desempenho de rede
Normalmente, o desempenho de rede é suficiente. Se você estiver transmitindo dados com frequência como aumento/diminuição de escala horizontal frequente, ou houver grandes movimentações de dados de entrada/saída, esse desempenho pode se tornar um problema. Talvez seja necessário avaliar o desempenho de rede da camada do produto. Por exemplo, a camada de Standard_DS14_v2 produto dá suporte a 12.000 Mb/s. Compare esse valor com o byte-in/out nas métricas.
Se você vir a rede elevada para apenas alguns nós, pode ser que haja uma partição de acesso frequente. Revise os padrões de distribuição e acesso de dados para identificar um possível desequilíbrio.
- Aumente verticalmente para um nível de produto diferente, oferecendo suporte a mais E/S de rede.
- Escalar horizontalmente o cluster adicionando mais nós.
Muitos clientes conectados
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 ao 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 à baixa utilização do disco. No entanto, recomendamos que você revise ocasionalmente as métricas de espaço em disco. Cassandra acumula vários discos e os reduz quando a compactação é iniciada. É importante examinar o uso do disco por períodos mais longos para estabelecer tendências, como quando a compactação não consegue recuperar espaço.
Observação
Para garantir o 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, pode ser que haja uma partição ativa. Revise os padrões de distribuição e acesso de dados para detectar uma possível distorção.
- Adicione mais discos, mas esteja atento aos limites de IOPS impostos por sua camada de produto.
- Expanda o cluster horizontalmente.
Memória JVM
Nossa fórmula padrão atribui metade da memória da máquina virtual à JVM (Máquina Virtual Java) 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 as que têm leituras frequentes entre partições ou verificações de intervalo, podem ter um desafio relacionado à memória.
Na maioria dos casos, a memória é recuperada efetivamente pelo coletor de lixo Java. Se a CPU estiver geralmente acima de 80%, não há ciclos de CPU suficientes disponíveis para o coletor de lixo. Resolva problemas de desempenho da CPU antes de verificar os problemas de memória.
Se a CPU se mantiver abaixo de 70% e a coleta de lixo não conseguir recuperar a memória, talvez seja necessário mais memória para a JVM. Mais memória JVM poderá ser necessária se você estiver em uma camada de produto com memória limitada. Na maioria dos casos, você precisa examinar as suas consultas e configurações de cliente e reduzir fetch_size junto com o que é escolhido em limit na sua consulta do Cassandra Query Language (CQL).
Se você precisar de mais memória, poderá:
- Dimensione verticalmente para uma camada de produto que tenha mais memória disponível.
Marcas de exclusão
Executamos reparos a cada sete dias com o reaper, que remove linhas com tempo de vida (TTL) expirado. Essas linhas são chamadas de pedras de tumba. Algumas cargas de trabalho são excluídas 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 do Cassandra. Alguns erros indicam que uma consulta não pôde ser atendida devido a pedras de tumba excessivas.
Uma mitigação de curto prazo se as consultas não forem atendidas é aumentar o valor tombstone_failure_threshold na configuração do Cassandra dos 100.000 padrão para um valor mais alto.
Também recomendamos que você examine o TTL no keyspace e, potencialmente, execute reparos diariamente para limpar mais marcas de exclusão. Se os TTLs forem curtos (por exemplo, menos de dois dias) e os fluxos de dados forem excluídos rapidamente, recomendamos que você examine a estratégia de compactação e favoreça Leveled Compaction Strategy. Em alguns casos, essas ações podem indicar que uma revisão do modelo de dados é necessária.
Avisos em 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 as suas consultas para ficar abaixo do tamanho de lote recomendado. Em casos raros e como uma mitigação de curto prazo, aumente batch_size_fail_threshold_in_kb na Configuração do Cassandra do 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 do Stack Overflow. Esse problema pode causar graves problemas de desempenho e deve ser resolvido.
Otimizações especializadas
Compactação
O Cassandra permite a seleção de um algoritmo de compactação apropriado quando uma tabela é criada. O padrão é LZ4, que é excelente para taxa de transferência e CPU, mas consome mais espaço em disco. O uso de Zstandard (Cassandra 4.0 ou superior) economiza cerca de 12% espaço com sobrecarga mínima de CPU.
Otimizar o espaço de heap memtable
O padrão é usar um quarto do heap 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 à liberação frequente e sstables fragmentadas, que exigem mais compactação. Aumentar para pelo menos 4.048 pode ser bom. Essa abordagem requer uma avaliação criteriosa de desempenho para garantir que outras operações (por exemplo, operações de leitura) não sejam afetadas.