Postgres-forespørgsler i produktionen resulterer i unormalt høj disklæsnings-I/O

Denne forespørgsel producerede ikke nogen disk I/O - alle blokkene læses fra delte buffere. Men da forespørgslen læser 73424 blokke (ca. 574 MB), vil den producere betydelig I/O-belastning, når tabellen ikke er cachelagret.

Men der er to ting, der kan forbedres.

• Du har tabsgivende blokmatcher i heap-scanningen. Det betyder, at work_mem er ikke stor nok til at indeholde en bitmap med en bit pr. tabelrække, og 26592 bits mapper en tabelblok i stedet. Alle rækkerne skal kontrolleres igen, og 86733 rækker kasseres, hvoraf de fleste er falske positive fra de tabsgivende blokmatcher.

  Hvis du øger work_mem , vil en bitmap med en bit pr. tabelrække passe ind i hukommelsen, og dette tal vil skrumpe, hvilket reducerer arbejdet under heap-scanningen.

• 190108 rækker kasseres, fordi de ikke matcher den ekstra filterbetingelse i bitmap-heap-scanningen. Det er nok her det meste af tiden bliver brugt. Hvis du kan reducere det beløb, vil du vinde.

  De ideelle indekser for denne forespørgsel ville være:

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

  Hvis transaction_type er ikke særlig selektiv (dvs. de fleste rækker har værdien Sale). ), kan du udelade den kolonne.

EDIT:

Undersøgelse af vmstat og iostat viser, at både CPU og I/O-undersystemet lider af massiv overbelastning:alle CPU-ressourcer bruges på I/O-ventetid og VM-stjæletid. Du har brug for et bedre I/O-system og et værtssystem med flere ledige CPU-ressourcer. Forøgelse af RAM kan afhjælpe I/O-problemet, men kun for disklæsninger.