Procedure consigliate per prestazioni ottimali
Istanza gestita di Azure 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.
Impostazione e configurazione ottimali
Fattore di replica, numero di dischi, numero di nodi e SKU
Poiché Azure supporta tre zone di disponibilità nella maggior parte delle aree e le zone di disponibilità di Istanza gestita di Cassandra eseguono 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. Si consiglia anche di 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 nell'SKU scelto insieme alle operazioni di I/O al secondo di un disco P30. Ad esempio, l'SKU Standard_DS14_v2 supporta 51.200 operazioni di I/O al secondo non memorizzate nella cache, 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 all'SKU e al numero di dischi. Il benchmarking è particolarmente importante nel caso di SKU con soli otto core. La ricerca dimostra che le CPU a 8 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.
Dati analitici e Carichi di lavoro 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 cassandra.yaml seguenti per i carichi di lavoro analitici (vedere qui su come applicarle).
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 di coda, è consigliabile usare un driver client che supporti l'esecuzione speculativa e configurare di conseguenza il client. Per il driver Java V4, una demo che illustra il funzionamento e come abilitare i criteri è disponibile qui.
Monitoraggio dei colli di bottiglia delle prestazioni
Prestazioni 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:
Suggerimento
Per una visualizzazione della CPU realistica, aggiungere un filtro e dividere la proprietà per Usage kind=usage_idle. Se questo valore è inferiore al 20%, è possibile applicare la suddivisione per ottenere l'utilizzo in base a tutti i tipi di utilizzo.
Se la CPU supera sempre l'80% di utilizzo per la maggior parte dei nodi, il database diventa in overload e si riscontrano più timeout del client. In questo scenario è consigliabile eseguire le azioni seguenti:
- aumentare verticalmente fino a un SKU con più core CPU (soprattutto se i core sono solo 8 o meno).
- dimensionare 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 altri, ciò indica una partizione ad accesso frequente che richiede ulteriori indagini.
Nota
La modifica dell'SKU è supportata tramite il portale di Azure, l'interfaccia della riga di comando di Azure e la distribuzione di modelli di Azure Resource Manager. È possibile distribuire/modificare il modello di Resource Manager e sostituire l'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
Si noti che attualmente non è supportata la transizione tra famiglie di SKU. Ad esempio, se attualmente si dispone di un Standard_DS13_v2 e si è interessati all'aggiornamento a un SKU più grande come Standard_DS14_v2, questa opzione non è disponibile. Tuttavia, è possibile aprire un ticket di supporto per richiedere un aggiornamento all'SKU superiore.
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, potrebbe essere 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 l'SKU per le scritture.
- L'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 operazioni di I/O al secondo elevate solo 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 dall'SKU scelto, ma sono 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 creazione di un caso di supporto.
- Aumentare le prestazioni dei data center aggiungendo altri nodi.
Se il numero massimo di operazioni di I/O raggiunge il valore massimo supportato dall'SKU, è possibile:
- aumentare le prestazioni fino a un SKU diverso che supporta più operazioni di I/O al secondo.
- Aumentare le prestazioni dei data center aggiungendo altri nodi.
Per altre informazioni, vedere Macchina virtuale 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 l'aumento/riduzione frequenti delle prestazioni) o si verificano enormi spostamenti di dati in ingresso/uscita, questo può diventare un problema. Potrebbe essere necessario valutare le prestazioni di rete dell'SKU. Ad esempio, l'SKU Standard_DS14_v2 supporta 12.000 Mb/s, confrontarlo con il byte-in/out nelle metriche:
Se si vede solo la rete elevata 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 alla ricerca di una potenziale asimmetria.
- Aumentare verticalmente fino a un SKU diverso che supporta più I/O di rete.
- Dimensionare 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 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 molti dischi e quindi li riduce quando viene attivata la compattazione. È quindi importante esaminare l'utilizzo del disco in periodi più lunghi per stabilire tendenze, ad esempio se la compattazione non è in grado di recuperare spazio.
Nota
Per garantire uno spazio disponibile sufficiente per la compattazione, l'utilizzo del disco deve essere mantenuto intorno al 50%.
Se questo comportamento viene riscontrato 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 alla ricerca di una potenziale asimmetria.
- aggiungere altri dischi, ma tenere presente i limiti di IOPS imposti dall'SKU
- aumentare le dimensioni del 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, specialmente quelli con letture o analisi di intervalli tra partizioni frequenti, potrebbero riscontrare problemi di memoria insufficiente.
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 rimanenti per il Garbage Collector. 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. Ciò vale soprattutto se si usa un 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 in limit all'interno della query CQL.
Se è effettivamente necessaria più memoria, è possibile:
- Inviare un ticket per aumentare le impostazioni di memoria JVM
- Ridimensionare verticalmente a un SKU con più memoria disponibile
Rimozioni definitive
Le riparazioni vengono eseguite ogni sette giorni con un raccoglitore, che rimuove le righe la cui durata TTL è scaduta (operazione denominata "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 di Cassandra o anche errori che indicano che non è stato possibile soddisfare una query a causa di rimozioni definitive eccessive.
Una mitigazione a breve termine se le query non vengono soddisfatte consiste nell'aumentare tombstone_failure_threshold nella configurazione di Cassandra dal valore predefinito di 100.000 a un valore superiore.
Oltre a questo, è consigliabile di esaminare il TTL sul keyspace e potenzialmente eseguire riparazioni ogni giorno per cancellare più tombe. Se i TTL sono brevi, ad esempio meno di due giorni, e i dati vengono inseriti ed eliminati rapidamente, è consigliabile esaminare la strategia di compattazione e preferire Leveled Compaction Strategy. In alcuni casi, tali azioni possono indicare che è necessaria una revisione del modello di dati.
Avvisi batch
È possibile che venga visualizzato questo avviso nei CassandraLogs insieme a errori potenzialmente 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 nella 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 il tutto in modo più dettagliato. 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). Il valore predefinito è 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 successive) 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 e instabili frammentati, richiedendo così una maggiore compattazione. In questi casi, l'aumento a un valore minimo di 4048 potrebbe essere utile, ma richiede un benchmarking attento 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. A questo punto è possibile iniziare a usare il cluster: