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à.

Instance-specific monitoraggio delle prestazioni e delle risorse

Il monitoraggio a livello di istanza è fondamentale per comprendere la distorsione della connessione, la distorsione del carico di lavoro e la distorsione dei dati, nonché per capire quando aggiungere router o split shard per aumentare la scalabilità e ottenere un throughput più elevato con una latenza mantenuta.

Panoramica di

Quando l'applicazione invia una query su Amazon Aurora PostgreSQL Limitless Database, tale richiesta attraversa un sofisticato sistema distribuito prima di restituire i risultati. Un apparentemente semplice SELECT un'istruzione potrebbe riguardare più istanze di database, ognuna delle quali svolge un ruolo distinto nell'elaborazione della richiesta. La comprensione di questo percorso e delle istanze che lo alimentano trasforma il modo in cui si progettano applicazioni, interpretano i dati di monitoraggio e diagnosticano i problemi di prestazioni.

Questa guida fornisce informazioni tecniche approfondite sull'architettura delle istanze di Aurora PostgreSQL Limitless Database:

Nozioni fondamentali sull'architettura delle istanze

Aurora PostgreSQL Limitless Database raggiunge la scalabilità orizzontale attraverso la separazione funzionale tra due tipi di istanze specializzati:

Questa separazione consente ad Aurora PostgreSQL Limitless Database di scalare la gestione delle connessioni, il coordinamento delle query e l'archiviazione dei dati in modo indipendente in base alle caratteristiche del carico di lavoro.

Confronto tra router e shard

Monitoraggio delle prestazioni dell’istanza

La comprensione delle prestazioni a livello di istanza è fondamentale per il funzionamento efficace di Aurora PostgreSQL Limitless Database. Instance-specific il monitoraggio rivela i modelli di distribuzione che influiscono sulle prestazioni: distorsione della connessione, distorsione del carico di lavoro e distorsione dei dati.

Rilevamento dell'asimmetria

In una distribuzione ideale di Aurora PostgreSQL Limitless Database, il carico di lavoro e le risorse vengono distribuiti uniformemente tra le istanze. In pratica, le applicazioni presentano spesso una distribuzione asimmetrica, ossia una distribuzione non uniforme che concentra il carico su istanze specifiche.

Tre tipi di inclinazione da monitorare:

distribuzione del carico di Database Insights

Il modo più rapido per valutare lo stato di salute a livello di istanza è la visualizzazione Load Distribution di Database Insights, che offre una visibilità immediata sulla distribuzione delle sessioni attive tra le istanze.

Per accedere a Load Distribution:

Schema sano: Carico distribuito in modo relativamente uniforme tra le istanze

Per quanto riguarda il modello: Concentrazione significativa su casi specifici

CloudWatch metriche

Per un'analisi più approfondita oltre a Database Insights, CloudWatch fornisce metriche specifiche per le istanze che rivelano i modelli di utilizzo delle risorse.

Il ServerlessDatabaseCapacity metrica con dimensione DBShardGroupInstance mostra il consumo di ACU per istanza, fornendo la visione più diretta dell'utilizzo delle risorse.

Quando indagare:

Monitoraggio e risoluzione dei problemi del router

I router possono riscontrare problemi di prestazioni dovuti a due cause principali: distribuzione non uniforme della connessione e concentrazione del carico di lavoro tra più parti.

Sessioni distribuite in modo non uniforme

Sintomo: Un router gestisce una quota sproporzionata di connessioni

Causa principale: La memorizzazione nella cache DNS causa la risoluzione di più richieste di connessione sullo stesso endpoint del router.

Più comune durante:

Rimedi:

Monitoraggio e risoluzione dei problemi relativi agli shard

Gli shard presentano problemi di prestazioni dovuti a tre cause principali: vincoli di risorse, distorsione dei dati e distorsione del carico di lavoro.

Utilizzo delle risorse condivise

Uno shard con le chiavi shard più diffuse conterrà più dati e carichi di lavoro più elevati. Ciò si manifesta con l'utilizzo delle risorse, ovvero l'istanza consumerà più ACU.

Strategie di riparazione:

Quando dividere i frammenti:

Volumi di dati condivisi

Usa le funzioni SQL di Aurora PostgreSQL Limitless Database per interrogare i volumi di dati:

SELECT subcluster_id, subcluster_type, pg_size_pretty(db_size) 
FROM rds_aurora.limitless_stat_database_size('postgres_limitless') 
ORDER BY 1;
            

Per visualizzare i dati per tabella e per frammento:

SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public', 'table_name');
            

Risoluzione dell'utilizzo irregolare

Quando il carico di lavoro o la distorsione dei dati si concentra su frammenti specifici, la suddivisione degli shard ridistribuisce il carico su più istanze.

Considerazioni importanti:

La suddivisione degli shard consente un ulteriore ridimensionamento e la suddivisione consecutiva degli shard consente di aumentare il throughput e l'ulteriore scalabilità, mantenendo al contempo una bassa latenza.

Limitazioni

Siate consapevoli di questi vincoli operativi:

Limitazioni del router:

Limitazioni condivise:

Strategie di mitigazione: