Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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. Questa funzionalità consente la massima flessibilità e controllo, se necessario. Questo articolo fornisce suggerimenti su come ottimizzare le prestazioni.
Impostazione e configurazione ottimali
Fattore di replica, numero di dischi, numero di nodi e livelli di prodotto
Azure supporta tre zone di disponibilità nella maggior parte delle aree. Azure Managed Instance per Apache Cassandra associa le zone di disponibilità ai rack. Si consiglia di scegliere una chiave di partizione con alta cardinalità per evitare partizioni calde. 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, usare 3, 6, 9 e così via.
Azure usa un RAID 0 oltre il numero di dischi di cui si effettua il provisioning. Per ottenere il numero ottimale di operazioni di input/output al secondo (IOPS), verificare il numero massimo di IOPS nel livello del prodotto scelto insieme al numero di IOPS di un disco P30. Ad esempio, il Standard_DS14_v2 livello prodotto supporta 51.200 operazioni di I/O al secondo non memorizzate nella cache. Un singolo disco P30 ha prestazioni di base di 5.000 operazioni di I/O al secondo. 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 al livello di prodotto e al numero di dischi. Il benchmarking è particolarmente importante per i livelli di prodotto con soli otto core. La ricerca mostra che le CPU a otto core funzionano solo per i carichi di lavoro meno impegnativi. La maggior parte dei carichi di lavoro richiede almeno 16 core per l'esecuzione corretta.
Carichi di lavoro analitici e transazionali
I carichi di lavoro transazionali richiedono in genere un data center ottimizzato per una bassa latenza. I carichi di lavoro analitici usano spesso query più complesse, che richiedono più tempo per l'esecuzione. Nella maggior parte dei casi, si preferiscono data center separati con:
- Una ottimizzata per la bassa latenza.
- Uno ottimizzato per i carichi di lavoro analitici.
Ottimizzare i carichi di lavoro analitici
È consigliabile applicare le impostazioni seguenti cassandra.yaml per i carichi di lavoro analitici. Per altre informazioni su come applicare queste impostazioni, vedere Aggiornare la configurazione di Cassandra.
Timeout
| Valore | 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
| Valore | Impostazione predefinita di Cassandra MI | Raccomandazione per il carico di lavoro analitico |
|---|---|---|
file_cache_size_in_mb |
2,048 | 6.144 |
Altre raccomandazioni
| Valore | 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.
Ottimizzare per la 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 un driver Java V4, una demo illustra il funzionamento di questo processo e come abilitare i criteri in questo esempio.
Monitorare i 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%. Per visualizzare le metriche della CPU, dal portale di Azure, nella sezione Monitoraggio aprire la scheda Metriche .
Per una visualizzazione della CPU realistica, aggiungere un filtro e usare Usage kind=usage_idle per suddividere la proprietà. Se questo valore è inferiore al 20%, applicare la suddivisione per ottenere l'utilizzo in base a tutti i tipi di utilizzo.
Se la CPU è costantemente sopra 80% per la maggior parte dei nodi, il database viene sovraccaricato, che si manifesta con molteplici timeout dei client. In questo scenario è consigliabile eseguire le azioni seguenti:
- Aumentare verticalmente fino a un livello di prodotto con più core CPU, soprattutto se i core sono solo 8 o meno.
- Ridimensionare orizzontalmente aggiungendo altri nodi. Come accennato in precedenza, il numero di nodi deve essere un multiplo del fattore di replica.
Se la CPU è elevata solo per pochi nodi, ma bassa per gli altri, indica una partizione calda. Questo scenario richiede ulteriori indagini.
La modifica del livello di prodotto è supportata tramite il portale di Azure, l'interfaccia della riga di comando di Azure e la distribuzione del modello di Azure Resource Manager (modello arm). È possibile implementare o modificare un modello di ARM e sostituire il livello prodotto con uno dei seguenti valori:
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
Attualmente non è supportata la transizione tra le famiglie di prodotti. Ad esempio, se attualmente si dispone di un Standard_DS13_v2 e si vuole aggiornare a un prodotto più grande, come Standard_DS14_v2, questa opzione non è disponibile. Aprire un ticket di supporto per richiedere un aggiornamento al prodotto 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 degli IOPS.
Se le metriche mostrano una o tutte le caratteristiche seguenti, potrebbe essere necessario aumentare le prestazioni:
- Le metriche sono costantemente superiori o uguali agli IOPS di base. Ricordarsi di moltiplicare 5.000 operazioni di I/O al secondo per il numero di dischi per nodo per ottenere il numero.
- Le metriche sono costantemente superiori o uguali al numero massimo di operazioni di I/O al secondo consentite per il livello di prodotto per le scritture.
- Il tuo livello di prodotto supporta l'archiviazione memorizzata nella cache (cache write-through), e questo numero è inferiore alle IOPS dei dischi gestiti. Questo valore è il limite superiore per le operazioni di I/O al secondo di lettura.
Se vedi gli IOPS elevati solo per pochi nodi, potrebbe essere presente una partizione calda e devi esaminare i dati per individuare un potenziale squilibrio.
Se gli IOPS sono inferiori a quelli supportati dal tier del prodotto, ma superiori o uguali agli IOPS del disco, seguire le azioni seguenti:
- Aggiungere altri nodi per aumentare le prestazioni dei data center.
Se le operazioni di I/O al secondo raggiungono il limite massimo supportato dal livello del prodotto, è possibile:
- Passa a un livello di prodotto diverso che supporta più IOPS.
- Aggiungere altri nodi per aumentare le prestazioni dei data center.
Per altre informazioni, vedere Prestazioni della macchina virtuale e del disco.
Prestazioni di rete
In genere, le prestazioni di rete sono sufficienti. Se esegui frequentemente lo streaming dei dati, come ad esempio la scalabilità orizzontale frequente o la riduzione della scalabilità, o si verificano ingenti movimenti di dati in ingresso/uscita, queste prestazioni possono diventare un problema. Potrebbe essere necessario valutare le prestazioni di rete del livello prodotto. Ad esempio, il Standard_DS14_v2 livello prodotto supporta 12.000 MB/s. Confrontare questo valore con il byte-in/out nelle metriche.
Se l'utilizzo della rete è elevato solo per alcuni nodi, potrebbe essere presente una partizione ad accesso frequente. Esaminare i modelli di distribuzione dei dati e di accesso per individuare potenziali differenze.
- Aumentare verticalmente fino a un livello di prodotto diverso supportando più I/O di rete.
- Dimensionare orizzontalmente il cluster aggiungendo altri nodi.
Troppi client connessi
Pianificare e attivare le implementazioni per gestire il numero massimo di richieste simultanee necessarie per la latenza desiderata di un'applicazione. Per una distribuzione specifica, l'introduzione di un maggior carico al sistema al di sopra di una soglia minima aumenta la latenza complessiva. Monitorare il numero di client connessi per assicurarsi che questa situazione non superi i limiti tollerabili.
Spazio su disco
Nella maggior parte dei casi, lo spazio su disco è sufficiente. Le distribuzioni predefinite sono ottimizzate per IOPS, che porta a un basso utilizzo del disco. Tuttavia, è consigliabile esaminare occasionalmente le metriche dello spazio su disco. Cassandra accumula numerosi dischi e li riduce quando viene attivata la compattazione. È importante esaminare l'utilizzo del disco in periodi più lunghi per stabilire tendenze, ad esempio quando la compattazione non è in grado di recuperare spazio.
Note
Per garantire lo spazio disponibile per la compattazione, mantenere l'utilizzo del disco a circa 50%.
Se viene visualizzato questo comportamento solo per alcuni nodi, potrebbe essere presente una partizione calda. Esaminare i modelli di distribuzione dei dati e di accesso per individuare potenziali differenze.
- Aggiungere altri dischi, ma tenere presente i limiti di IOPS imposti dal livello di prodotto.
- Aumentare la capacità del cluster.
Memoria JVM
La formula predefinita assegna metà della memoria della macchina virtuale alla macchina virtuale Java (JVM) con un limite massimo di 31 GB. Nella maggior parte dei casi, questo approccio è un buon equilibrio tra prestazioni e memoria. Alcuni carichi di lavoro, in particolare quelli che effettuano letture frequenti tra partizioni o scansioni di intervallo, potrebbero avere difficoltà di memoria.
Nella maggior parte dei casi, la memoria viene recuperata in modo efficace dal Garbage Collector Java. Se l'utilizzo della CPU è spesso superiore all'80%, non sono disponibili cicli di CPU sufficienti per il Garbage Collector. Risolvere i problemi di prestazioni della CPU prima di controllare eventuali problemi di memoria.
Se la CPU passa al di sotto di 70% e l'operazione di Garbage Collection non riesce a recuperare memoria, potrebbe essere necessaria una quantità maggiore di memoria JVM. Se si usa un livello di prodotto con memoria limitata, potrebbe essere necessaria una quantità maggiore di memoria JVM. Nella maggior parte dei casi, è necessario esaminare le query e le impostazioni client e ridurre fetch_size insieme a quanto scelto all'interno di limit della query CQL (Cassandra Query Language).
Se è necessaria più memoria, è possibile:
- Ridimensionare verticalmente fino a un livello di prodotto con più memoria disponibile.
Rimozioni definitive
Vengono eseguite riparazioni ogni sette giorni con Reaper, che rimuove le righe la cui durata (TTL) è scaduta. Queste righe sono denominate lapide. Alcuni carichi di lavoro eliminano più frequentemente e mostrano avvisi come Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) nei log di Cassandra. Alcuni errori indicano che non è stato possibile soddisfare una query a causa un numero eccessivo di rimozioni definitive.
Una mitigazione a breve termine se le query non vengono soddisfatte consiste nell'aumentare il tombstone_failure_threshold valore nella configurazione di Cassandra dal valore predefinito 100.000 a un valore superiore.
È anche consigliabile esaminare la durata (TTL) sul keyspace ed eseguire le riparazioni ogni giorno per cancellare più rimozioni definitive. Se i TTL sono brevi (ad esempio, meno di due giorni) e i dati vengono elaborati e eliminati rapidamente, è consigliabile esaminare la strategia di compattazione e preferire Leveled Compaction Strategy. In alcuni casi, tali azioni potrebbero indicare che è necessaria una revisione del modello di dati.
Avvisi batch
È possibile che venga visualizzato l'avviso seguente in CassandraLogs e potenzialmente errori correlati:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Rivedi le tue query per mantenerti al di sotto della dimensione di batch consigliata. In rari casi e come mitigazione a breve termine, 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 l'avviso seguente in CassandraLogs:
Writing large partition <table> (105.426MiB) to sstable <file>
Questo messaggio indica un problema nel modello di dati. Per altre informazioni, vedere questo articolo Stack Overflow. Questo problema 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. Il valore predefinito è LZ4, che è eccellente per la velocità effettiva e la CPU, ma usa più spazio su disco. L'uso di Zstandard (Cassandra 4.0 e versioni su) consente di risparmiare circa 12% spazio con un sovraccarico minimo della CPU.
Ottimizzare lo spazio dell'heap memtable
L'impostazione predefinita consiste nell'usare un quarto dell'heap JVM per memtable_heap_space nel cassandra.yaml file. Per le applicazioni orientate alla scrittura o sui livelli di prodotto con piccole quantità di memoria, questo problema può causare frequenti svuotamenti e frammentazione sstables, che richiedono una maggiore compattazione. L'aumento di almeno 4.048 potrebbe essere buono. Questo approccio richiede un benchmarking accurato per assicurarsi che altre operazioni (ad esempio, letture) non siano influenzate.