Postgres-förfrågningar i produktionen resulterar i onormalt hög diskläsnings-I/O

Den här frågan producerade ingen disk I/O – alla block läses från delade buffertar. Men eftersom frågan läser 73424 block (cirka 574 MB), kommer den att producera betydande I/O-belastning när tabellen inte är cachad.

Men det finns två saker som kan förbättras.

• Du har förlustiga blockmatchningar i högskanningen. Det betyder att work_mem är inte tillräckligt stor för att innehålla en bitmapp med en bit per tabellrad, och 26592 bitar mappar ett tabellblock istället. Alla rader måste kontrolleras igen och 86733 rader kasseras, varav de flesta är falska positiva från de förlustiga blockmatchningarna.

  Om du ökar work_mem , kommer en bitmapp med en bit per tabellrad att passa in i minnet, och detta antal kommer att krympa, vilket minskar arbetet under heap-skanningen.

• 190108 rader kasseras eftersom de inte matchar det ytterligare filtervillkoret i bitmappshögskanningen. Det är nog där den mesta tiden spenderas. Om du kan minska det beloppet kommer du att vinna.

  De idealiska indexen för den här frågan skulle vara:

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

  Om transaction_type är inte särskilt selektiv (dvs. de flesta rader har värdet Sale ), kan du utelämna den kolumnen.

EDIT:

Undersökning av vmstat och iostat visar att både CPU och I/O-undersystemet lider av massiv överbelastning:alla CPU-resurser spenderas på I/O-väntetid och VM stjäl tid. Du behöver ett bättre I/O-system och ett värdsystem med mer lediga CPU-resurser. Ökat RAM-minne kan lindra I/O-problemet, men bara för diskläsningar.