Melhores práticas para um desempenho otimizado
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, permitindo o máximo de 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 SKUs
Como o Azure dá suporte a três zonas de disponibilidade na maioria das regiões e a Instância Gerenciada do Cassandra mapeia zonas de disponibilidade para racks, recomendamos escolher uma chave de partição com alta cardinalidade para evitar partições ativas. Para o melhor nível de confiabilidade e de 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 em relação ao número de discos que você provisiona. Portanto, para obter o IOPS ideal, você precisa verificar o IOPS máximo na SKU que escolheu junto com o IOPS de um disco P30. Por exemplo, a SKU Standard_DS14_v2 dá suporte a 51.200 IOPS sem cache, enquanto um único disco P30 tem um desempenho base de 5.000 IOPS. Portanto, quatro discos resultariam em 20.000 IOPS, o que está bem abaixo dos limites do computador.
É altamente recomendável fazer um parâmetro de comparação abrangente de sua carga de trabalho em relação à SKU e ao número de discos. O parâmetro de comparação é especialmente importante no caso de SKUs com apenas oito núcleos. Nossa pesquisa mostra que as CPUs de oito núcleos 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 ter data centers 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 configurações de cassandra.yaml para cargas de trabalho analíticas (veja aqui como aplicar).
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 |
| write_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 |
Configurações de 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 de cauda, é altamente recomendável usar um driver de cliente que ofereça suporte à execução especulativa e configurar seu cliente adequadamente. Para o driver Java J4, você pode encontrar uma demonstração que ilustra como isso funciona e como habilitar a política aqui.
Monitoramento de 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%. Você pode visualizar as métricas da CPU na guia Métricas dentro do Monitoramento no portal:
Se a CPU estiver permanentemente acima de 80% na maioria dos nós, o banco de dados ficará sobrecarregado, resultando em vários tempos limites nos clientes. Nesse cenário, recomendamos tomar as seguintes medidas:
- Escalar verticalmente para uma SKU com mais núcleos de CPU (especialmente se os núcleos forem apenas 8 ou menos).
- escalar 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 estiver alta apenas em alguns nós, mas baixa nos outros, ela indica uma partição ativa e precisa de mais investigação.
Observação
A alteração da SKU tem suporte por meio do portal do Azure, da CLI do Azure e da implantação do modelo do ARM. Você pode implantar/editar o modelo do ARM e substituir a SKU por uma das seguintes opções.
- 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, no momento, não há suporte para a transição entre famílias de SKU. Por exemplo, se você possui um Standard_DS13_v2 e está interessado em atualizar para um SKU maior, como Standard_DS14_v2, por exemplo, essa opção não está disponível. No entanto, você pode abrir um tíquete de suporte para solicitar uma atualização para o SKU mais alto.
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. Nesse caso, é importante revisar as métricas de IOPS:
Se as métricas apresentarem uma ou todas as características a seguir, isso pode indicar que você precisa escalar verticalmente.
- 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 máximo de IOPS permitido para a SKU para gravações.
- Sua SKU dá suporte ao armazenamento em cache (write-through-cache) e esse número é menor que o IOPS dos discos gerenciados (esse será o limite superior para seu IOPS de leitura).
Se você vir apenas o IOPS elevado para alguns nós, talvez tenha uma partição ativa e precise revisar seus dados quanto a uma possível distorção.
Se o seu IOPS for menor do que o suportado pela SKU escolhida, mas maior ou igual ao IOPS do disco, você poderá tomar as seguintes medidas:
- Adicionar mas discos para aumentar o desempenho. O aumento de discos requer a criação de um caso de suporte.
- Escalar verticalmente o(s) data center(s) adicionando mais nós.
Se o seu IOPS atingir o máximo suportado pela SKU, você poderá:
- escalar verticalmente para um SKU diferente que suporte mais IOPS.
- Escalar verticalmente o(s) data center(s) adicionando mais nós.
Para obter mais informações, consulte Desempenho de máquina virtual e disco.
Desempenho de rede
Geralmente, o desempenho da rede é suficiente. No entanto, 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, isso pode se tornar um problema. Talvez seja necessário avaliar o desempenho da rede de sua SKU. Por exemplo, a SKU Standard_DS14_v2 dá suporte a 12.000 Mb/s, compare isso com a entrada/saída de bytes nas métricas:
Se você vir apenas a rede elevada para poucos nós, talvez seja uma partição ativa e precise revisar a distribuição de dados e/ou os padrões de acesso para verificar uma possível distorção.
- Escalar verticalmente para uma SKU diferente com suporte a mais E/S de rede.
- Escalar horizontalmente o cluster adicionando mais nós.
Muitos clientes conectados
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 ultrapasse os limites toleráveis.
Espaço em disco
Na maioria dos casos, há espaço suficiente em disco, pois as implantações padrão são otimizadas para IOPS, o que leva a baixa utilização do disco. No entanto, recomendamos revisar ocasionalmente as métricas de espaço em disco. O Cassandra acumula muitos discos e depois os reduz quando a compactação é acionada. Portanto, é importante examinar o uso do disco por períodos mais longos para estabelecer tendências, como a compactação incapaz de recuperar espaço.
Observação
Para garantir o espaço disponível para compactação, a utilização do disco deve ser mantida em torno de 50%.
Se você observar esse comportamento apenas em alguns nós, talvez tenha uma partição ativa e precise revisar a distribuição de dados e/ou os padrões de acesso para verificar se há uma possível distorção.
- adicione mais discos, mas esteja atento aos limites de IOPS impostos por sua SKU
- Escale 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 verificações de intervalo, podem ter problemas de memória.
Na maioria dos casos, a memória é recuperada de forma eficaz pelo coletor de lixo do Java, mas, especialmente se a CPU estiver frequentemente acima de 80%, não haverá ciclos de CPU suficientes para o coletor de lixo. Portanto, qualquer problema de desempenho da CPU deve ser resolvido antes dos problemas de memória.
Se a CPU estiver abaixo de 70% e a coleta de lixo não for capaz de recuperar a memória, talvez você precise de mais memória JVM. Esse é especialmente o caso se você estiver em uma SKU com memória limitada. Na maioria dos casos, você precisará revisar suas consultas e configurações de cliente e reduzir fetch_size juntamente com o que for escolhido em limit na consulta CQL.
Se você realmente precisar de mais memória, poderá:
- Registrar um tíquete para que possamos aumentar as configurações de memória JVM para você
- Escalar verticalmente para uma SKU que tenha mais memória disponível
Marcas de exclusão
Executamos reparos a cada sete dias com o reaper, que remove as linhas cujo TTL expirou (chamado de "marca de exclusão"). 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 do Cassandra, ou até mesmo erros indicando que uma consulta não pôde ser atendida devido ao excesso de marcas de exclusão.
Uma mitigação de curto prazo se as consultas não forem atendidas é aumentar tombstone_failure_threshold na Configuração do Cassandra do valor padrão de 100.000 para um valor mais alto.
Além disso, recomendamos revisar o TTL no espaço de chaves e, possivelmente, executar reparos diariamente para limpar mais marcas de exclusão. Se os TTLs forem curtos, por exemplo, menos de dois dias, e os dados fluírem e forem excluídos rapidamente, recomendamos revisar a estratégia de compactação e dar preferência a Leveled Compaction Strategy. Em alguns casos, essas ações podem ser uma indicação de que é necessária uma revisão do modelo de dados.
Avisos em 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 do Cassandra do padrão de 50 para um valor mais alto.
Aviso de partição grande
Você pode encontrar esse 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 excedente de pilha que fornece mais detalhes. Isso pode causar problemas graves de desempenho e precisa ser resolvido.
Otimizações especializadas
Compactação
O Cassandra permite a seleção de um algoritmo de compactação apropriado quando uma tabela é criada (consulte Compactação). O padrão é LZ4, que é excelente para a taxa de transferência e a CPU, mas consome mais espaço no disco. O uso do Zstd (Cassandra 4.0 e superior) economiza cerca de aproximadamente 12% de espaço com o mínimo de sobrecarga de CPU.
Otimizando o espaço de heap da memtable
Nosso padrão é usar 1/4 do heap da JVM para memtable_heap_space no cassandra.yaml. Para aplicativos orientados para gravação e/ou em SKUs com pouca memória, isso pode levar a liberação frequente e sstables fragmentados, exigindo, portanto, mais compactação. Nesses casos, aumentá-lo para pelo menos 4048 pode ser benéfico, mas requer um parâmetro de comparação cuidadoso para garantir que outras operações (por exemplo, leituras) não sejam afetadas.
Próximas etapas
Neste artigo, apresentamos algumas práticas recomendadas para obter o desempenho ideal. Você já pode começar a trabalhar com o cluster: