Ottimizzazione del carico di lavoro di query - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Ottimizzazione del carico di lavoro di query

Un carico di lavoro ben ottimizzato ti aiuterà a raggiungere una soluzione stabile per l'ipercrescita. Se il carico di lavoro non è ben ottimizzato, indipendentemente dalla potenza del cluster Amazon Aurora che utilizzi, incontrerai colli di bottiglia che ridurranno le prestazioni e influiranno sull'esperienza utente della tua applicazione. È preferibile adottare fin dall'inizio un processo che consenta di identificare e ottimizzare le query problematiche nel sistema.

Monitoraggio e ottimizzazione delle query problematiche nel carico di lavoro

In caso di ipercrescita, disporre di un carico di lavoro ben calibrato è metà dell'opera. Per comprendere la natura dei carichi di lavoro in tempo reale e i problemi di prestazioni che il tuo cluster Aurora deve affrontare, assicurati che il tuo team raccolga le query problematiche sia dalle istanze di scrittura che da quelle di lettura. Queste query problematiche devono essere ottimizzate affinché il carico di lavoro venga eseguito in uno stato ottimale. Amazon Aurora edizione compatibile con MySQL offre due modi per farlo:

  • Approfondimenti sulle prestazioni

  • Log delle query lente

Uso di Approfondimenti sulle prestazioni

Performance Insights tiene traccia del carico sull'istanza di scrittura o di lettura Aurora in base alle sessioni attive medie (AAS). Il valore delle AAS viene calcolato utilizzando il campionamento e il numero di sessioni attive in attesa che una CPU raccolga il carico di lavoro delle query e lo elabori. Performance Insights fornisce un'interfaccia grafica da cui è possibile controllare le istruzioni SQL che generano il carico più elevato in base alle attese delle sessioni attive.

Grafici e diagrammi di Performance Insights.

Nella schermata precedente, la chiamata alla stored procedure my_sqrt fa attendere in media 13,03 sessioni per l'elaborazione dei carichi. Il passaggio logico successivo consiste nell'ottimizzare questa procedura. È necessario identificare le istruzioni SQL per la lettura e la scrittura che causano il carico sulle rispettive istanze e ottimizzarle per migliorare le prestazioni fino a quando i valori delle AAS non scenderanno e rimarranno al di sotto della linea tratteggiata Max vCPU in Performance Insights. Se hai raggiunto lo sforzo di ottimizzazione massimo e vedi ancora le AAS oltre la linea Max vCPU, puoi optare per una classe di istanze più ampia per gestire il tuo carico di lavoro. Non optare per un'istanza più grande senza prima aver provato a ottimizzare il carico di lavoro delle query, perché l'aumento del traffico comincerà a esporre le linee di errore create da query errate nel carico di lavoro.

Utilizzo di log di query lenti e pubblicazione su CloudWatch

Il log delle query lente è una funzionalità nativa di MySQL ed è complementare a Performance Insights. È preferibile utilizzare entrambi questi metodi per anticipare le query problematiche che possono causare danni alle istanze. Il log delle query lente registra qualsiasi query più lenta della variabile dinamica long_query_time. Questa variabile può essere configurata senza riavviare le istanze del cluster.

Per garantire flessibilità e isolamento nell'esercizio di ottimizzazione, usa gruppi di parametri separati per le istanze di scrittura e lettura. È un aspetto particolarmente importante se si utilizza la divisione di lettura e scrittura. Imposta un limite per long_query_time nelle istanze del cluster che sia comodo per le tue esigenze. Mentre ottimizzi il carico, puoi puntare a valori aggressivi per la variabile long_query_time, perché è possibile impostare la soglia a livello di millisecondi. Con un'elevata simultaneità e un carico di lavoro ben ottimizzato, quasi tutte le query dovrebbero essere eseguite entro alcuni millisecondi.

Quando imposti Amazon Aurora edizione compatibile con MySQL per il log delle query lente su un file, Aurora compatibile con MySQL scriverà i log delle query lente sul file system compatibile con Aurora MySQL e li conserverà per 24 ore. Per conservare i log delle query lente per un periodo più lungo per l'analisi, pubblicali su Amazon CloudWatch. Puoi anche creare una CloudWatch dashboard per monitorare le tue query lente. Per ulteriori informazioni, consulta il post del blog Creazione di una CloudWatch dashboard Amazon per monitorare Amazon RDS e Amazon Aurora MySQL. Oltre ad analizzare le tue query lente su Amazon CloudWatch, puoi profilare i log delle query lente utilizzando uno strumento in pt-query-digest Percona Toolkit.

Puoi anche scegliere di automatizzare questo processo di download e profilazione delle query per una maggiore efficienza del tuo team. Il team dovrebbe verificare la presenza di query che vengono eseguite frequentemente e per intervalli più lunghi e dare priorità alla loro ottimizzazione. Cerca di creare uno stato in cui vengano registrate pochissime query nel log delle query lente; così potrai ridurre il long_query_time e ottenere valori più aggressivi man mano che comprendi e ottimizzi il tuo carico di lavoro.