Zapytania Postgres w produkcji skutkują nienormalnie wysokimi operacjami we/wy odczytu dysku

To zapytanie nie przyniosło żadnych operacji we/wy na dysku – wszystkie bloki są odczytywane ze współdzielonych buforów. Ale ponieważ zapytanie odczytuje 73424 bloki (około 574 MB), spowoduje znaczne obciążenie we/wy, gdy tabela nie jest buforowana.

Ale są dwie rzeczy, które można poprawić.

• Masz przegrane dopasowania bloków w skanowaniu sterty. Oznacza to, że work_mem nie jest wystarczająco duży, aby pomieścić bitmapę z bitem na wiersz tabeli, a zamiast tego 26592 bity mapują blok tabeli. Wszystkie wiersze muszą zostać ponownie sprawdzone, a 86733 wiersze są odrzucane, z których większość to fałszywe alarmy ze stratnych dopasowań bloków.

  Jeśli zwiększysz work_mem , bitmapa z bitem na wiersz tabeli zmieści się do pamięci, a liczba ta zmniejszy się, zmniejszając pracę podczas skanowania sterty.

• 190108 wierszy jest odrzucanych, ponieważ nie pasują do dodatkowego warunku filtru w skanowaniu sterty bitmapy. To tam prawdopodobnie spędza się większość czasu. Jeśli możesz zmniejszyć tę kwotę, wygrasz.

  Idealne indeksy dla tego zapytania to:

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

  Jeśli transaction_type nie jest bardzo selektywny (tj. większość wierszy ma wartość Sale ), możesz pominąć tę kolumnę.

EDYTUJ:

Badanie vmstat i iostat pokazuje, że zarówno procesor, jak i podsystem we/wy cierpią z powodu ogromnego przeciążenia:wszystkie zasoby procesora są zużywane na oczekiwanie we/wy i czas kradzieży maszyny wirtualnej. Potrzebujesz lepszego systemu we/wy i systemu hosta z większą ilością wolnych zasobów procesora. Zwiększenie pamięci RAM migjt złagodzi problem I/O, ale tylko dla odczytów dysku.