Le query Postgres in produzione determinano un I/O di lettura del disco anormalmente elevato

Questa query non ha prodotto alcun I/O del disco:tutti i blocchi vengono letti da buffer condivisi. Ma poiché la query legge 73424 blocchi (circa 574 MB), produrrà un carico di I/O sostanziale quando la tabella non è memorizzata nella cache.

Ma ci sono due cose che possono essere migliorate.

• Hai corrispondenze a blocchi con perdita nella scansione dell'heap. Ciò significa che work_mem non è abbastanza grande da contenere una bitmap con un bit per riga di tabella e 26592 bit mappano invece un blocco di tabella. Tutte le righe devono essere ricontrollate e 86733 righe vengono scartate, la maggior parte delle quali sono falsi positivi dalle corrispondenze di blocchi con perdita.

  Se aumenti work_mem , una bitmap con un bit per riga di tabella entrerà in memoria e questo numero si ridurrà, riducendo il lavoro durante la scansione dell'heap.

• 190108 righe vengono eliminate perché non corrispondono alla condizione di filtro aggiuntiva nell'analisi dell'heap bitmap. Questo è probabilmente il luogo in cui viene trascorsa la maggior parte del tempo. Se riesci a ridurre tale importo, vincerai.

  Gli indici ideali per questa query sarebbero:

  CREATE INDEX ON map_listing(transaction_type, la);
  CREATE INDEX ON map_listing(transaction_type, lo);
  

  Se transaction_type non è molto selettivo (ovvero, la maggior parte delle righe ha il valore Sale ), puoi omettere quella colonna.

MODIFICA:

Esame di vmstat e iostat mostra che sia la CPU che il sottosistema di I/O soffrono di un enorme sovraccarico:tutte le risorse della CPU vengono spese in attesa di I/O e tempo di furto della VM. Hai bisogno di un sistema I/O migliore e di un sistema host con più risorse CPU libere. L'aumento della RAM migjt allevia il problema di I/O, ma solo per le letture del disco.