L'acquisizione delle prestazioni di Cloud SQL per MySQL ti aiuta a diagnosticare e risolvere problemi di prestazioni complessi e temporanei nel tuo database MySQL causati dall'evoluzione della domanda del sistema. Man mano che i carichi di lavoro delle applicazioni vengono scalati e l'infrastruttura circostante diventa più complessa, i database sono soggetti a richieste sempre più elevate e imprevedibili. Queste pressioni del sistema esterno possono causare rallentamenti o blocchi del database.
Quando il rendimento del database peggiora, le metriche standard possono essere insufficienti per identificare la causa principale nel contesto della tua infrastruttura più grande. L'acquisizione delle prestazioni risolve questo problema acquisendo snapshot dettagliati e point-in-time del database nel momento in cui viene rilevato un problema. Puoi utilizzare trigger configurabili per acquisire snapshot a livello di sistema quando si verificano problemi temporanei. I trigger possono anche rilevare transazioni a lunga esecuzione, che possono essere le cause principali dei problemi di prestazioni. Puoi configurare i trigger in modo che terminino automaticamente le transazioni a lunga esecuzione.
Esempi di casi d'uso
Questa sezione elenca esempi di casi d'uso per l'utilizzo dell'acquisizione delle prestazioni dopo averla abilitata per l'istanza.
| Caso d'uso | Condizione trigger | Informazioni diagnostiche |
|---|---|---|
| Rallentamento a livello di sistema dovuto all'accumulo di log di annullamento | Lunghezza dell'elenco della cronologia | Identifica quando il processo di eliminazione InnoDB è in ritardo a causa di letture a lunga esecuzione o di operazioni di linguaggio di manipolazione dei dati (DML) di grandi dimensioni. Il ritardo può comportare un aumento della pressione di archiviazione e un peggioramento delle prestazioni. |
| Blocco del database causato da conflitti interni del motore | Attese di semafori | Utile per diagnosticare un database che non risponde. Questo trigger può rilevare conflitti di blocco mutex o di lettura-scrittura all'interno del motore di archiviazione InnoDB, come l'indice hash adattivo (AHI) o il conflitto del buffer pool. |
| Conflitti di blocco a livello di applicazione o query non indicizzate | Attese di blocco delle transazioni | Si attiva quando un numero elevato di transazioni è in stato LOCK WAIT, il che indica conflitti a livello di riga o transazioni inattive a lunga esecuzione. |
| Sovraccarico dell'istanza dovuto a ordinamento o aggregazione complessi | Utilizzo elevato della CPU | Acquisisce lo stato durante l'utilizzo elevato della CPU del container, spesso causato da query inefficienti o da picchi di concorrenza massicci. |
| Rischio di riavvii per esaurimento della memoria (OOM) | Memoria utilizzata elevata | Ti aiuta a diagnosticare problemi come buffer per thread di dimensioni eccessive o perdite di memoria prima che causino l'arresto anomalo di un'istanza. |
| Picchi di traffico improvvisi o app client con colli di bottiglia | Thread in esecuzione | Un indicatore generale del carico dell'istanza, utile per identificare aumenti improvvisi delle connessioni attive simultanee. |
| Dati obsoleti sulla replica a causa di carichi di lavoro di scrittura elevati | Secondi di ritardo rispetto all'origine | Monitora il ritardo di replica sulle repliche di lettura per diagnosticare i ritardi nella sincronizzazione dei dati dall'istanza principale. |
| Query a lunga esecuzione che bloccano l'eliminazione | Transazioni a lunga esecuzione | Identifica le transazioni aperte da troppo tempo e che potrebbero contenere blocchi critici. Inoltre, puoi terminare automaticamente le transazioni a lunga esecuzione. |
Come vengono acquisiti i dati sul rendimento
L'acquisizione delle prestazioni funziona come un servizio basato su agenti che monitora l'istanza. Quando abiliti l'acquisizione delle prestazioni, l'istanza Cloud SQL esegue le seguenti operazioni per acquisire i dati sul rendimento:
L'agente esegue il probing della configurazione dell'istanza per leggere i trigger basati su soglia che hai definito. L'agente esegue quindi il probing delle metriche dell'istanza a un intervallo configurabile,
probingIntervalSeconds, impostato su 30 secondi per impostazione predefinita.Se viene rilevato un problema e la soglia di un trigger è stata superata, l'agente continua a confrontare lo stato live dell'istanza con le regole. Per evitare falsi allarmi dovuti a picchi temporanei, l'agente attiva un'acquisizione completa delle prestazioni. Un'acquisizione viene attivata solo se la condizione viene soddisfatta durante i probing consecutivi per la
probeThresholdconfigurata, il cui valore predefinito è3. Questa soglia consecutiva impedisce le acquisizioni dovute a picchi temporanei.Ad esempio, l'agente potrebbe attivare un'acquisizione delle prestazioni se rileva che il numero di thread è elevato per tre probing consecutivi.
Se sono configurate più condizioni trigger, Cloud SQL avvia un'acquisizione se viene soddisfatta una qualsiasi delle condizioni.
Quando viene attivata un'acquisizione, l'acquisizione delle prestazioni si connette al database ed esegue una serie di comandi di diagnostica per acquisire uno snapshot dettagliato.
Le informazioni acquisite vengono formattate in voci di log e inviate direttamente a Cloud Logging del progetto per l'istanza Cloud SQL in un flusso di log specifico denominato
mysql-performance-capture.log.
Periodi di raffreddamento e backoff adattivi
Per evitare il logging eccessivo e l'overhead del sistema, l'acquisizione delle prestazioni implementa un periodo di attesa dopo un'acquisizione.
Raffreddamento standard
Dopo un'acquisizione riuscita, l'acquisizione delle prestazioni avvia un periodo di raffreddamento standard di 30 minuti. Durante questo periodo, l'agente non attiva nuove acquisizioni anche se l'istanza si trova in uno stato di problema esteso.
Raffreddamento e backoff adattivi
Se un'istanza attiva ripetutamente acquisizioni per la stessa violazione, l'acquisizione delle prestazioni utilizza un meccanismo di backoff adattivo del periodo di raffreddamento. Questo meccanismo aiuta a limitare il volume di logging e il costo delle soglie configurate in modo errato.
Nell'ambito di questo meccanismo:
- Il periodo di raffreddamento si estende a 24 ore.
- L'acquisizione delle prestazioni entra in modalità di sospensione, che sospende tutti i controlli dei trigger e le acquisizioni diagnostiche.
- L'istanza è limitata a una singola acquisizione delle prestazioni al giorno.
Trigger di acquisizione delle prestazioni
Questa sezione elenca i trigger disponibili per l'acquisizione delle prestazioni di MySQL. Tutti i trigger elencati nella tabella, tranne dove indicato, utilizzano i valori di configurazione del probing probingIntervalSeconds e probeThreshold per convalidare le condizioni di trigger sostenute.
| Nome della condizione trigger | Nome API | Descrizione | Valore predefinito | Intervallo di configurazione |
|---|---|---|---|---|
| Utilizzo elevato della CPU |
cpuUtilizationThresholdPercent
|
Attiva un'acquisizione quando l'utilizzo complessivo della CPU dell'istanza del database supera costantemente questa percentuale. Questo aiuta a rilevare il sovraccarico dell'istanza, spesso causato da query inefficienti con ordinamento e aggregazione massicci, indicizzazione insufficiente o concorrenza molto elevata. Per evitare acquisizioni su picchi minori, configura il valore predefinito in modo che rientri nell'intervallo di percentuale più elevato per la tua istanza. | 0 (disattivato)
|
0 o 10-99 (%)
|
| Utilizzo elevato della memoria |
memoryUsageThresholdPercent
|
Attiva un'acquisizione quando la memoria utilizzata del container del database supera costantemente questa percentuale della memoria allocata dell'istanza. Questo trigger può aiutare a diagnosticare potenziali problemi di esaurimento della memoria, perdite di memoria o configurazione della memoria inefficiente. Per evitare l'acquisizione di picchi minori, imposta il valore predefinito sull'estremità superiore dell'intervallo per la tua istanza. | 0 (disattivato)
|
0 o 10-99 (%)
|
| Utilizzo elevato dei file temporanei |
Non configurabile. Questo trigger è abilitato automaticamente per MySQL 8.0 e versioni successive. | Attiva automaticamente un'acquisizione quando si verifica un aumento significativo dell'utilizzo del disco da parte dei file temporanei creati dal processo MySQL.
Spesso i file temporanei vengono eliminati, ma rimangono aperti da un processo MySQL. La soglia per questo trigger utilizza un modello di escalation progressiva per le soglie di differenza. Inizia da 100 GB e raddoppia in sequenza fino a 200 GB, 400 GB, fino a 1,6 TB dopo ogni periodo di assestamento. Utilizzando un modello di escalation progressiva, l'acquisizione delle prestazioni si verifica solo se la differenza nell'utilizzo dei file temporanei aumenta a un livello elevato. |
Abilitato | n/a |
| Lunghezza dell'elenco della cronologia |
historyListLengthThresholdCount
|
Attiva un'acquisizione quando la lunghezza dell'elenco della cronologia (HLL) di InnoDB supera il valore configurato. Un HLL costantemente elevato indica che il processo di eliminazione InnoDB non è in grado di tenere il passo e il conteggio delle transazioni non eliminate è in aumento, spesso a causa di transazioni a lunga esecuzione. Questo numero elevato può comportare un aumento del consumo di spazio di archiviazione e problemi di prestazioni. Questa soglia dipende dal carico di lavoro. Alcune istanze possono funzionare in modo sufficiente anche con HLL costantemente elevati. Tuttavia, puoi comunque utilizzare questo trigger per evidenziare potenziali problemi come letture a lunga esecuzione, istruzioni DML (Data Manipulation Language) di grandi dimensioni o colli di bottiglia dei thread di eliminazione. |
0 (disattivato)
|
0 o 10000-10000000
|
| Transazioni a lunga esecuzione |
transactionDurationThreshold
|
Una transazione viene registrata se viene eseguita per una durata superiore a quella configurata in secondi. Questo trigger è utile per identificare le operazioni che potrebbero contenere blocchi per periodi eccessivi o consumare risorse per troppo tempo. Le transazioni che superano transactionDurationThreshold vengono valutate dopo ogni intervallo specificato nella configurazione probingIntervalSeconds (valore predefinito 30 secondi). Tuttavia, per gestire il volume dei log, i dettagli di un massimo di 10 di queste transazioni a lunga esecuzione vengono inviati a Cloud Logging al massimo una volta ogni periodo di attesa (30 minuti).
Il testo completo della query fino a 1024 byte da INFORMATION_SCHEMA.INNODB_TRX è incluso in ogni voce di log per le prime 10 transazioni. |
3600 (secondi)
|
60 o più
|
| Errore del thread SQL/IO della replica |
Non configurabile. Questo trigger è abilitato automaticamente per impostazione predefinita su tutte le istanze di replica e non può essere disattivato. | Attiva immediatamente un'acquisizione se il thread SQL di replica o il thread IO su un'istanza di replica rileva un errore e si arresta. Questo trigger è fondamentale per mantenere l'integrità della replica e identificare gli errori di replica. Questo trigger non utilizza alcuna impostazione di configurazione del probing, come probingIntervalseconds o probeThreshold, per convalidare le condizioni di acquisizione delle prestazioni. |
Abilitato | n/a |
| Thread in esecuzione | runningThreadsThreshold
|
Attiva un'acquisizione quando il numero di thread attivi in esecuzione in base alla variabile di stato threads_running supera il valore specificato. Ad esempio, puoi configurare la soglia per eseguire l'acquisizione delle prestazioni se il numero di thread attivi in esecuzione supera 100.Questo trigger è obbligatorio per l'acquisizione delle prestazioni. Se non configuri questo trigger in modo esplicito, il valore predefinito viene calcolato in base al numero di vCPU appartenenti all'istanza. |
MIN(600,
cpuCount * 20)
|
10 o più
|
| Secondi di ritardo rispetto all'origine |
secondsBehindSourceThreshold
|
Attiva un'acquisizione quando il ritardo di replica sull'istanza di replica di lettura, misurato in secondi, supera il valore specificato. Puoi utilizzare questo trigger per monitorare e diagnosticare i ritardi nella replica. Questo trigger è abilitato automaticamente per le istanze di replica. Se non configuri il trigger in modo esplicito, il valore predefinito è 900 secondi. Ti consigliamo di configurare il valore sull'estremità superiore per evitare acquisizioni eccessive e periodi di raffreddamento frequenti. | 900 (secondi)
|
1 o più
|
| Attese di semafori | semaphoreWaitThresholdCount
|
Attiva un'acquisizione quando il numero di thread in attesa di semafori InnoDB interni supera il valore configurato di questo trigger. Questa metrica avanzata indica un conflitto, utilizzando un blocco mutex o di lettura-scrittura, all'interno del motore di archiviazione InnoDB stesso.
I conflitti più comuni sono il conflitto dell'indice hash adattivo (AHI), il conflitto del buffer pool e il conflitto di I/O del disco. Viene attivata un'acquisizione anche se il tempo di attesa massimo per un singolo semaforo supera i 200 secondi, indipendentemente dal valore configurato di questo trigger. |
0 (disattivato)
|
0 o 10-10000
|
| Attese di blocco delle transazioni |
transactionLockWaitThresholdCount
|
Attiva un'acquisizione quando il numero di transazioni in stato LOCK WAIT supera il conteggio configurato. Un numero ridotto di transazioni in stato di attesa di blocco può essere normale in un sistema occupato, ma un numero costantemente elevato di attese di blocco è un forte indicatore di conflitti di blocco a livello di applicazione, DML non indicizzati, transazioni inattive a lunga esecuzione e conflitti di riga a concorrenza elevata che possono compromettere gravemente le prestazioni e la velocità effettiva. |
0 (disattivato)
|
0 o 10-10000
|
Prezzi
L'acquisizione delle prestazioni è disponibile in tutte le regioni Cloud SQL senza costi aggiuntivi. Vengono applicati addebiti standard solo per le risorse del database sottostanti. L'acquisizione delle prestazioni archivia i log in Cloud Logging, il che può comportare costi di archiviazione aggiuntivi di Cloud Logging.
Per ulteriori informazioni sui prezzi per l'archiviazione dei log in Logging, consulta Prezzi.
Limitazioni
- Per utilizzare l'acquisizione delle prestazioni, devi abilitare Query Insights. Se disabiliti Query Insights, viene disabilitata anche l'acquisizione delle prestazioni.
- L'acquisizione delle prestazioni è disponibile solo per Cloud SQL per MySQL 5.7 e versioni successive.
Passaggi successivi
- Configurare l'acquisizione delle prestazioni
- Visualizzare i log di acquisizione delle prestazioni
- Monitorare le istanze