Postgres-query's in productie resulteren in abnormaal hoge schijflees-I/O

Deze query heeft geen schijf-I/O opgeleverd - alle blokken worden gelezen uit gedeelde buffers. Maar aangezien de query 73424 blokken (ongeveer 574 MB) leest, zal deze een aanzienlijke I/O-belasting produceren wanneer de tabel niet in de cache wordt opgeslagen.

Maar er zijn twee dingen die verbeterd kunnen worden.

• Je hebt lossy block matches in de heapscan. Dat betekent dat work_mem is niet groot genoeg om een ​​bitmap met een bit per tabelrij te bevatten, en 26592 bits brengt in plaats daarvan een tabelblok in kaart. Alle rijen moeten opnieuw worden gecontroleerd en 86733 rijen worden weggegooid, waarvan de meeste valse positieven zijn van de lossy block-overeenkomsten.

  Als u work_mem . verhoogt , zal een bitmap met een bit per tabelrij in het geheugen passen, en dit aantal zal kleiner worden, waardoor het werk tijdens de heapscan wordt verminderd.

• 190108 rijen worden weggegooid omdat ze niet overeenkomen met de aanvullende filtervoorwaarde in de bitmap-heapscan. Hier wordt waarschijnlijk de meeste tijd aan besteed. Als je dat bedrag kunt verlagen, win je.

  De ideale indexen voor deze zoekopdracht zijn:

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

  Als transaction_type is niet erg selectief (d.w.z. de meeste rijen hebben de waarde Sale ), kunt u die kolom weglaten.

BEWERKEN:

Onderzoek van vmstat en iostat laat zien dat zowel de CPU als het I/O-subsysteem te lijden hebben onder enorme overbelasting:alle CPU-bronnen worden besteed aan I/O-wachttijd en VM-steeltijd. U hebt een beter I/O-systeem en een hostsysteem met meer vrije CPU-bronnen nodig. Het vergroten van het RAM-geheugen zou het I/O-probleem kunnen verlichten, maar alleen voor het lezen van de schijf.