Procedure consigliate per prestazioni ottimali
Azure Istanza gestita per Apache Cassandra è un servizio completamente gestito per cluster Apache Cassandra open source puri. Il servizio consente anche di eseguire l'override delle configurazioni, a seconda delle esigenze specifiche di ogni carico di lavoro, consentendo la massima flessibilità e controllo dove necessario. Questo articolo fornisce suggerimenti su come ottimizzare le prestazioni.
Configurazione e configurazione ottimali
Fattore di replica, numero di dischi, numero di nodi e SKU
Poiché supporto tecnico di Azure tre zone di disponibilità nella maggior parte delle aree e Cassandra Istanza gestita esegue il mapping delle zone di disponibilità ai rack, è consigliabile scegliere una chiave di partizione con cardinalità elevata per evitare partizioni ad accesso frequente. Per il miglior livello di affidabilità e tolleranza di errore, è consigliabile configurare un fattore di replica pari a 3. È anche consigliabile specificare un multiplo del fattore di replica come numero di nodi, ad esempio 3, 6, 9 e così via.
Viene usato un RAID 0 oltre il numero di dischi di cui si effettua il provisioning. Per ottenere le operazioni di I/O al secondo ottimali, è quindi necessario verificare il numero massimo di operazioni di I/O al secondo nello SKU scelto insieme alle operazioni di I/O al secondo di un disco P30. Ad esempio, lo Standard_DS14_v2 SKU supporta 51.200 operazioni di I/O al secondo non memorizzate, mentre un singolo disco P30 ha prestazioni di base pari a 5.000 operazioni di I/O al secondo. Quindi, quattro dischi portano a 20.000 operazioni di I/O al secondo, ben al di sotto dei limiti del computer.
È consigliabile eseguire un benchmarking completo del carico di lavoro rispetto allo SKU e al numero di dischi. Il benchmarking è particolarmente importante nel caso di SKU con soli otto core. La ricerca dimostra che otto CPU core funzionano solo per i carichi di lavoro meno impegnativi e la maggior parte dei carichi di lavoro richiede almeno 16 core per ottenere prestazioni elevate.
Carichi di lavoro analitici e transazionali
I carichi di lavoro transazionali richiedono in genere un data center ottimizzato per una bassa latenza, mentre i carichi di lavoro analitici usano spesso query più complesse, che richiedono più tempo per l'esecuzione. Nella maggior parte dei casi è necessario separare i data center:
- Una ottimizzata per la bassa latenza
- Uno ottimizzato per i carichi di lavoro analitici
Ottimizzazione per i carichi di lavoro analitici
È consigliabile che i clienti applichino le impostazioni seguenti cassandra.yaml per i carichi di lavoro analitici (vedere qui su come applicare)
Timeout
| Value | Impostazione predefinita di Cassandra MI | Raccomandazione per il carico di lavoro analitico |
|---|---|---|
| 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 |
Cache
| Value | Impostazione predefinita di Cassandra MI | Raccomandazione per il carico di lavoro analitico |
|---|---|---|
| file_cache_size_in_mb | 2,048 | 6.144 |
Altre raccomandazioni
| Value | Impostazione predefinita di Cassandra MI | Raccomandazione per il carico di lavoro analitico |
|---|---|---|
| commitlog_total_space_in_mb | 8,192 | 16,384 |
| column_index_size_in_kb | 64 | 16 |
| compaction_throughput_mb_per_sec | 128 | 256 |
Impostazioni del client
È consigliabile aumentare i timeout del driver client Cassandra in base ai timeout applicati al server.
Ottimizzazione per bassa latenza
Le impostazioni predefinite sono già adatte per carichi di lavoro a bassa latenza. Per garantire prestazioni ottimali per le latenze della parte finale, è consigliabile usare un driver client che supporta l'esecuzione speculativa e configurare di conseguenza il client. Per il driver Java V4, è possibile trovare una demo che illustra come funziona e come abilitare i criteri qui.
Monitoraggio dei colli di bottiglia delle prestazioni
Prestazioni della CPU
Come ogni sistema di database, Cassandra funziona meglio se l'utilizzo della CPU è circa il 50% e non supera mai l'80%. È possibile visualizzare le metriche della CPU nella scheda Metriche all'interno di Monitoraggio dal portale:
Se la CPU supera in modo permanente l'80% per la maggior parte dei nodi, il database diventerà in overload manifesting in più timeout del client. In questo scenario è consigliabile eseguire le azioni seguenti:
- aumentare verticalmente fino a uno SKU con più core CPU (soprattutto se i core sono solo 8 o meno).
- ridimensionare orizzontalmente aggiungendo altri nodi (come indicato in precedenza, il numero di nodi deve essere multiplo del fattore di replica).
Se la CPU è elevata solo per alcuni nodi, ma bassa per le altre, indica una partizione ad accesso frequente e richiede ulteriori indagini.
Nota
Attualmente la modifica dello SKU è supportata solo tramite la distribuzione di modelli di Resource Manager. È possibile distribuire/modificare il modello di Resource Manager e sostituire lo SKU con uno dei seguenti.
- 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
Prestazioni dei dischi
Il servizio viene eseguito su dischi gestiti di Azure P30, che consentono operazioni di I/O al secondo con burst. Quando si tratta di colli di bottiglia relativi alle prestazioni del disco, è necessario un monitoraggio accurato. In questo caso è importante esaminare le metriche delle operazioni di I/O al secondo:
Se le metriche mostrano una o tutte le caratteristiche seguenti, può indicare che è necessario aumentare le prestazioni.
- Costantemente superiore o uguale al numero di operazioni di I/O al secondo di base(ricordarsi di moltiplicare 5.000 operazioni di I/O al secondo per il numero di dischi per nodo).
- Costantemente superiore o uguale al numero massimo di operazioni di I/O al secondo consentite per lo SKU per le scritture.
- Lo SKU supporta l'archiviazione memorizzata nella cache (write-through-cache) e questo numero è inferiore alle operazioni di I/O al secondo dai dischi gestiti (questo sarà il limite superiore per le operazioni di I/O al secondo di lettura).
Se vengono visualizzate solo le operazioni di I/O al secondo elevate per alcuni nodi, potrebbe essere presente una partizione ad accesso frequente ed è necessario esaminare i dati per individuare potenziali differenze.
Se le operazioni di I/O al secondo sono inferiori a quelle supportate dallo SKU scelto, ma superiori o uguali alle operazioni di I/O al secondo del disco, è possibile eseguire le azioni seguenti:
- Aggiungere altri dischi per migliorare le prestazioni. L'aumento dei dischi richiede la generazione di un caso di supporto.
- Aumentare le prestazioni dei data center aggiungendo altri nodi.
Se il numero massimo di operazioni di I/O al secondo supporta lo SKU, è possibile:
- aumentare le prestazioni fino a uno SKU diverso che supporta più operazioni di I/O al secondo.
- Aumentare le prestazioni dei data center aggiungendo altri nodi.
Per altre informazioni, vedere Macchine virtuali e prestazioni del disco.
Prestazioni di rete
Nella maggior parte dei casi le prestazioni di rete sono sufficienti. Tuttavia, se si esegue spesso lo streaming di dati (ad esempio, aumento/riduzione delle prestazioni orizzontali frequenti) o si verificano enormi spostamenti di dati in ingresso/uscita, questo può diventare un problema. Potrebbe essere necessario valutare le prestazioni di rete dello SKU. Ad esempio, lo Standard_DS14_v2 SKU supporta 12.000 Mb/s, confrontarlo con il byte-in/out nelle metriche:
Se viene visualizzata solo la rete con privilegi elevati per un numero ridotto di nodi, potrebbe essere presente una partizione ad accesso frequente ed è necessario esaminare la distribuzione dei dati e/o i modelli di accesso per una potenziale asimmetria.
- Aumentare verticalmente fino a uno SKU diverso che supporta più I/O di rete.
- Aumentare orizzontalmente il cluster aggiungendo altri nodi.
Troppi client connessi
Le distribuzioni devono essere pianificate e sottoposte a provisioning per supportare il numero massimo di richieste parallele necessarie per la latenza desiderata di un'applicazione. Per una determinata distribuzione, l'introduzione di un carico maggiore al di sopra di una soglia minima aumenta la latenza complessiva. Monitorare il numero di client connessi per assicurarsi che questo non superi i limiti tollerabili.
Spazio su disco
Nella maggior parte dei casi, lo spazio su disco è sufficiente perché le distribuzioni predefinite sono ottimizzate per le operazioni di I/O al secondo, con un basso utilizzo del disco. Tuttavia, è consigliabile esaminare occasionalmente le metriche dello spazio su disco. Cassandra accumula un sacco di disco e quindi lo riduce quando viene attivata la compattazione. Di conseguenza, è importante esaminare l'utilizzo del disco in periodi più lunghi per stabilire tendenze, ad esempio la compattazione non è in grado di recuperare spazio.
Nota
Per garantire lo spazio disponibile per la compattazione, l'utilizzo del disco deve essere mantenuto intorno al 50%.
Se questo comportamento viene visualizzato solo per alcuni nodi, potrebbe essere presente una partizione ad accesso frequente e potrebbe essere necessario esaminare la distribuzione dei dati e/o i modelli di accesso per una potenziale asimmetria.
- aggiungere altri dischi, ma tenere presente i limiti di IOPS imposti dallo SKU
- aumentare orizzontalmente il cluster
Memoria JVM
La formula predefinita assegna metà della memoria della macchina virtuale alla JVM con un limite massimo di 31 GB, che nella maggior parte dei casi rappresenta un buon equilibrio tra prestazioni e memoria. Alcuni carichi di lavoro, in particolare quelli con letture frequenti tra partizioni o analisi di intervallo, potrebbero verificarsi problemi di memoria.
Nella maggior parte dei casi la memoria viene recuperata in modo efficace dal Garbage Collector Java, ma soprattutto se la CPU è spesso superiore all'80% non ci sono abbastanza cicli di CPU per il Garbage Collector lasciato. Pertanto, eventuali problemi di prestazioni della CPU devono essere affrontati prima dei problemi di memoria.
Se la CPU passa al di sotto del 70% e l'operazione di Garbage Collection non è in grado di recuperare memoria, potrebbe essere necessaria una quantità maggiore di memoria JVM. Questo è soprattutto il caso in cui si usa uno SKU con memoria limitata. Nella maggior parte dei casi, è necessario esaminare le query e le impostazioni client e ridurre fetch_size insieme a ciò che viene scelto all'interno limit della query CQL.
Se è effettivamente necessaria più memoria, è possibile:
- Inviare un ticket per aumentare le impostazioni di memoria JVM
- Ridimensionare verticalmente a uno SKU con più memoria disponibile
Lapidi
Vengono eseguite riparazioni ogni sette giorni con un pannolino che rimuove le righe il cui TTL è scaduto (chiamato "rimozione definitiva"). Alcuni carichi di lavoro hanno eliminazioni più frequenti e visualizzano avvisi come Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) nei log cassandra o anche errori che indicano che non è stato possibile soddisfare una query a causa di un numero eccessivo di blocchi.
Una mitigazione a breve termine se le query non vengono soddisfatte consiste nell'aumentare l'oggetto tombstone_failure_threshold nella configurazione cassandra dal valore predefinito 100.000 a un valore superiore.
Oltre a questo, ti consigliamo di esaminare il TTL sul keyspace e potenzialmente eseguire riparazioni ogni giorno per cancellare più tombe. Se i TTLs sono brevi, ad esempio meno di due giorni e i flussi di dati in e vengono eliminati rapidamente, è consigliabile esaminare la strategia di compattazione e favorire Leveled Compaction Strategy. In alcuni casi, tali azioni possono essere un'indicazione che è necessaria una revisione del modello di dati.
Avvisi batch
Questo avviso potrebbe verificarsi in CassandraLogs e potenzialmente errori correlati:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
In questo caso è consigliabile esaminare le query per rimanere al di sotto delle dimensioni batch consigliate. In rari casi e come mitigazione a breve termine è possibile aumentare batch_size_fail_threshold_in_kb la configurazione di Cassandra dal valore predefinito 50 a un valore superiore.
Avviso di partizione di grandi dimensioni
È possibile che venga visualizzato questo avviso in CassandraLogs:
Writing large partition <table> (105.426MiB) to sstable <file>
Indica un problema nel modello di dati. Ecco un articolo di overflow dello stack che illustra in dettaglio. Ciò può causare gravi problemi di prestazioni e deve essere risolto.
Ottimizzazioni specializzate
Compressione
Cassandra consente la selezione di un algoritmo di compressione appropriato quando viene creata una tabella (vedere Compressione) L'impostazione predefinita è LZ4, che è eccellente per la velocità effettiva e la CPU, ma usa più spazio su disco. L'uso di Zstd (Cassandra 4.0 e versioni su) consente di risparmiare circa il 12% di spazio con un sovraccarico minimo della CPU.
Ottimizzazione dello spazio heap memtable
L'impostazione predefinita consiste nell'usare 1/4 dell'heap JVM per memtable_heap_space in cassandra.yaml. Per l'applicazione orientata alla scrittura e/o sugli SKU con memoria ridotta, ciò può causare frequenti scaricamenti estabili frammentati, richiedendo così una maggiore compattazione. In questi casi l'aumento di almeno 4048 potrebbe essere utile, ma richiede un'attenta benchmarking per assicurarsi che altre operazioni (ad esempio le letture) non siano interessate.
Passaggi successivi
In questo articolo sono state illustrate alcune procedure consigliate per ottenere prestazioni ottimali. È ora possibile iniziare a usare il cluster: