Query di diagnostica utili in Azure Cosmos DB for PostgreSQL
SI APPLICA A: 
Azure Cosmos DB for PostgreSQL (basato sull'estensione di database Citus per PostgreSQL)
Individuazione del nodo contenente dati per un tenant specifico
Nel caso d'uso multi-tenant è possibile determinare quale nodo di lavoro contiene le righe per un tenant specifico. Azure Cosmos DB for PostgreSQL raggruppa le righe di tabelle distribuite in partizioni e inserisce ogni partizione in un nodo di lavoro nel cluster.
Si supponga che i tenant dell'applicazione siano archivi e si voglia trovare il nodo di lavoro che contiene i dati per l'ID archivio=4. In altre parole, si vuole trovare la posizione per la partizione contenente righe la cui colonna di distribuzione ha valore 4:
SELECT shardid, shardstate, shardlength, nodename, nodeport, placementid
FROM pg_dist_placement AS placement,
pg_dist_node AS node
WHERE placement.groupid = node.groupid
AND node.noderole = 'primary'
AND shardid = (
SELECT get_shard_id_for_distribution_column('stores', 4)
);
L'output contiene l'host e la porta del database di lavoro.
┌─────────┬────────────┬─────────────┬───────────┬──────────┬─────────────┐
│ shardid │ shardstate │ shardlength │ nodename │ nodeport │ placementid │
├─────────┼────────────┼─────────────┼───────────┼──────────┼─────────────┤
│ 102009 │ 1 │ 0 │ 10.0.0.16 │ 5432 │ 2 │
└─────────┴────────────┴─────────────┴───────────┴──────────┴─────────────┘
Individuazione del nodo che ospita uno schema distribuito
Gli schemi distribuiti vengono associati automaticamente a singoli gruppi di condivisione, in modo che le tabelle create in tali schemi vengano convertite in tabelle distribuite con percorso condiviso senza una chiave di partizione. È possibile trovare la posizione in cui risiede uno schema distribuito tramite join di citus_shards con citus_schemas:
select schema_name, nodename, nodeport
from citus_shards
join citus_schemas cs
on cs.colocation_id = citus_shards.colocation_id
group by 1,2,3;
schema_name | nodename | nodeport
-------------+-----------+----------
a | localhost | 9701
b | localhost | 9702
with_data | localhost | 9702
È anche possibile eseguire query citus_shards filtrando direttamente il tipo di tabella dello schema per ottenere un elenco dettagliato per tutte le tabelle.
select * from citus_shards where citus_table_type = 'schema';
table_name | shardid | shard_name | citus_table_type | colocation_id | nodename | nodeport | shard_size | schema_name | colocation_id | schema_size | schema_owner
----------------+---------+-----------------------+------------------+---------------+-----------+----------+------------+-------------+---------------+-------------+--------------
a.cities | 102080 | a.cities_102080 | schema | 4 | localhost | 9701 | 8192 | a | 4 | 128 kB | citus
a.map_tags | 102145 | a.map_tags_102145 | schema | 4 | localhost | 9701 | 32768 | a | 4 | 128 kB | citus
a.measurement | 102047 | a.measurement_102047 | schema | 4 | localhost | 9701 | 0 | a | 4 | 128 kB | citus
a.my_table | 102179 | a.my_table_102179 | schema | 4 | localhost | 9701 | 16384 | a | 4 | 128 kB | citus
a.people | 102013 | a.people_102013 | schema | 4 | localhost | 9701 | 32768 | a | 4 | 128 kB | citus
a.test | 102008 | a.test_102008 | schema | 4 | localhost | 9701 | 8192 | a | 4 | 128 kB | citus
a.widgets | 102146 | a.widgets_102146 | schema | 4 | localhost | 9701 | 32768 | a | 4 | 128 kB | citus
b.test | 102009 | b.test_102009 | schema | 5 | localhost | 9702 | 8192 | b | 5 | 32 kB | citus
b.test_col | 102012 | b.test_col_102012 | schema | 5 | localhost | 9702 | 24576 | b | 5 | 32 kB | citus
with_data.test | 102180 | with_data.test_102180 | schema | 11 | localhost | 9702 | 647168 | with_data | 11 | 632 kB | citus
Ricerca della colonna di distribuzione per una tabella
Ogni tabella distribuita ha una "colonna di distribuzione". (Per altre informazioni, vedere Modellazione dei dati distribuita). Può essere importante sapere quale colonna si tratta. Ad esempio, quando si esegue il join o si filtrano tabelle, è possibile che vengano visualizzati messaggi di errore con hint come "aggiungere un filtro alla colonna di distribuzione".
Le tabelle pg_dist_* nel nodo coordinatore contengono metadati diversi relativi al database distribuito. In particolare pg_dist_partition contiene informazioni sulla colonna di distribuzione per ogni tabella. È possibile usare una funzione di utilità pratica per cercare il nome della colonna di distribuzione dai dettagli di basso livello nei metadati. Ecco un esempio e il relativo output:
-- create example table
CREATE TABLE products (
store_id bigint,
product_id bigint,
name text,
price money,
CONSTRAINT products_pkey PRIMARY KEY (store_id, product_id)
);
-- pick store_id as distribution column
SELECT create_distributed_table('products', 'store_id');
-- get distribution column name for products table
SELECT column_to_column_name(logicalrelid, partkey) AS dist_col_name
FROM pg_dist_partition
WHERE logicalrelid='products'::regclass;
Output di esempio:
┌───────────────┐
│ dist_col_name │
├───────────────┤
│ store_id │
└───────────────┘
Rilevamento di blocchi
Questa query verrà eseguita in tutti i nodi di lavoro e identificherà i blocchi, per quanto tempo sono stati aperti e le query che causano un errore:
SELECT run_command_on_workers($cmd$
SELECT array_agg(
blocked_statement || ' $ ' || cur_stmt_blocking_proc
|| ' $ ' || cnt::text || ' $ ' || age
)
FROM (
SELECT blocked_activity.query AS blocked_statement,
blocking_activity.query AS cur_stmt_blocking_proc,
count(*) AS cnt,
age(now(), min(blocked_activity.query_start)) AS "age"
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity
ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED
AND blocking_locks.GRANTED
GROUP BY blocked_activity.query,
blocking_activity.query
ORDER BY 4
) a
$cmd$);
Output di esempio:
┌───────────────────────────────────────────────────────────────────────────────────┐
│ run_command_on_workers │
├───────────────────────────────────────────────────────────────────────────────────┤
│ (10.0.0.16,5432,t,"") │
│ (10.0.0.20,5432,t,"{""update ads_102277 set name = 'new name' where id = 1; $ sel…│
│…ect * from ads_102277 where id = 1 for update; $ 1 $ 00:00:03.729519""}") │
└───────────────────────────────────────────────────────────────────────────────────┘
Esecuzione di query sulle dimensioni delle partizioni
Questa query fornirà le dimensioni di ogni partizione di una determinata tabella distribuita, denominata my_distributed_table:
SELECT *
FROM run_command_on_shards('my_distributed_table', $cmd$
SELECT json_build_object(
'shard_name', '%1$s',
'size', pg_size_pretty(pg_table_size('%1$s'))
);
$cmd$);
Output di esempio:
┌─────────┬─────────┬───────────────────────────────────────────────────────────────────────┐
│ shardid │ success │ result │
├─────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ 102008 │ t │ {"shard_name" : "my_distributed_table_102008", "size" : "2416 kB"} │
│ 102009 │ t │ {"shard_name" : "my_distributed_table_102009", "size" : "3960 kB"} │
│ 102010 │ t │ {"shard_name" : "my_distributed_table_102010", "size" : "1624 kB"} │
│ 102011 │ t │ {"shard_name" : "my_distributed_table_102011", "size" : "4792 kB"} │
└─────────┴─────────┴───────────────────────────────────────────────────────────────────────┘
Esecuzione di query sulle dimensioni di tutte le tabelle distribuite
Questa query ottiene un elenco delle dimensioni per ogni tabella distribuita più le dimensioni degli indici.
SELECT
tablename,
pg_size_pretty(
citus_total_relation_size(tablename::text)
) AS total_size
FROM pg_tables pt
JOIN pg_dist_partition pp
ON pt.tablename = pp.logicalrelid::text
WHERE schemaname = 'public';
Output di esempio:
┌───────────────┬────────────┐
│ tablename │ total_size │
├───────────────┼────────────┤
│ github_users │ 39 MB │
│ github_events │ 98 MB │
└───────────────┴────────────┘
Si noti che sono disponibili altre funzioni di Azure Cosmos DB for PostgreSQL per l'esecuzione di query sulle dimensioni della tabella distribuita. Vedere Determinare le dimensioni della tabella.
Identificazione degli indici inutilizzati
La query seguente identifica gli indici inutilizzati nei nodi di lavoro per una determinata tabella distribuita (my_distributed_table)
SELECT *
FROM run_command_on_shards('my_distributed_table', $cmd$
SELECT array_agg(a) as infos
FROM (
SELECT (
schemaname || '.' || relname || '##' || indexrelname || '##'
|| pg_size_pretty(pg_relation_size(i.indexrelid))::text
|| '##' || idx_scan::text
) AS a
FROM pg_stat_user_indexes ui
JOIN pg_index i
ON ui.indexrelid = i.indexrelid
WHERE NOT indisunique
AND idx_scan < 50
AND pg_relation_size(relid) > 5 * 8192
AND (schemaname || '.' || relname)::regclass = '%s'::regclass
ORDER BY
pg_relation_size(i.indexrelid) / NULLIF(idx_scan, 0) DESC nulls first,
pg_relation_size(i.indexrelid) DESC
) sub
$cmd$);
Output di esempio:
┌─────────┬─────────┬───────────────────────────────────────────────────────────────────────┐
│ shardid │ success │ result │
├─────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ 102008 │ t │ │
│ 102009 │ t │ {"public.my_distributed_table_102009##some_index_102009##28 MB##0"} │
│ 102010 │ t │ │
│ 102011 │ t │ │
└─────────┴─────────┴───────────────────────────────────────────────────────────────────────┘
Monitoraggio del numero di connessioni client
La query seguente conta le connessioni aperte nel coordinatore e le raggruppa per tipo.
SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;
Output di esempio:
┌────────┬───────┐
│ state │ count │
├────────┼───────┤
│ active │ 3 │
│ idle │ 3 │
│ ∅ │ 6 │
└────────┴───────┘
Visualizzazione delle query di sistema
Query attive
La vista pg_stat_activity mostra le query attualmente in esecuzione. È possibile applicare un filtro per trovare quelle attivamente in esecuzione, insieme all'ID processo del rispettivo back-end:
SELECT pid, query, state
FROM pg_stat_activity
WHERE state != 'idle';
Perché le query sono in attesa
È anche possibile eseguire query per visualizzare i motivi più comuni per cui le query non inattive sono in attesa. Per una spiegazione dei motivi, vedere la documentazione di PostgreSQL.
SELECT wait_event || ':' || wait_event_type AS type, count(*) AS number_of_occurences
FROM pg_stat_activity
WHERE state != 'idle'
GROUP BY wait_event, wait_event_type
ORDER BY number_of_occurences DESC;
Output di esempio durante l'esecuzione di pg_sleep in una query separata contemporaneamente:
┌─────────────────┬──────────────────────┐
│ type │ number_of_occurences │
├─────────────────┼──────────────────────┤
│ ∅ │ 1 │
│ PgSleep:Timeout │ 1 │
└─────────────────┴──────────────────────┘
Percentuale di riscontri nell'indice
Questa query fornirà la frequenza di riscontri nell'indice in tutti i nodi. La frequenza di riscontri nell'indice è utile per determinare la frequenza di utilizzo degli indici durante l'esecuzione di query. Un valore del 95% o superiore è ideale.
-- on coordinator
SELECT 100 * (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) AS index_hit_rate
FROM pg_statio_user_indexes;
-- on workers
SELECT nodename, result as index_hit_rate
FROM run_command_on_workers($cmd$
SELECT 100 * (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) AS index_hit_rate
FROM pg_statio_user_indexes;
$cmd$);
Output di esempio:
┌───────────┬────────────────┐
│ nodename │ index_hit_rate │
├───────────┼────────────────┤
│ 10.0.0.16 │ 96.0 │
│ 10.0.0.20 │ 98.0 │
└───────────┴────────────────┘
Percentuale riscontri nella cache
La maggior parte delle applicazioni accede in genere a una piccola frazione dei dati totali contemporaneamente. PostgreSQL mantiene i dati a cui si accede di frequente in memoria per evitare letture lente dal disco. È possibile visualizzare le statistiche relative alla vista pg_statio_user_tables.
Una misura importante è la percentuale di dati provenienti dalla cache della memoria rispetto al disco nel carico di lavoro:
-- on coordinator
SELECT
sum(heap_blks_read) AS heap_read,
sum(heap_blks_hit) AS heap_hit,
100 * sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) AS cache_hit_rate
FROM
pg_statio_user_tables;
-- on workers
SELECT nodename, result as cache_hit_rate
FROM run_command_on_workers($cmd$
SELECT
100 * sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) AS cache_hit_rate
FROM
pg_statio_user_tables;
$cmd$);
Output di esempio:
┌───────────┬──────────┬─────────────────────┐
│ heap_read │ heap_hit │ cache_hit_rate │
├───────────┼──────────┼─────────────────────┤
│ 1 │ 132 │ 99.2481203007518796 │
└───────────┴──────────┴─────────────────────┘
Se ci si trova con un rapporto significativamente inferiore al 99%, è probabile che si voglia prendere in considerazione l'aumento della cache disponibile per il database.
Passaggi successivi
- Informazioni su altre tabelle di sistema utili per la diagnostica