Jak automatycznie ustawić cache i statystyki po restarcie serwera

0

Witajcie,

Mam nietypowy problem. Jest sobie baza postgresql 9.6 nie jest to duża baza natomiast główna tabela będzie zawierać jakieś 99% miejsca dyskowego i jakieś 75% wszystkich zapytań będzie na tej tabeli.

Problem jest następujący. Takie zapytanie select * from najwieksza_tabela trwa jakieś 20-30 sekund przy obecnej liczbie 22mln rekordów. Sęk w tym, że ten czas jest tylko przy pierwszym uruchomieniu. Po tym pierwszym czasie oczekiwania postgres sobie prawdopodobnie cachuje to zapytanie i kolejne zapytania nawet z dodatkowymi "wariacjami" typu join, where, order, group by działają bardzo szybko max 3-4 sek.

Niestety system nie działa 24h tylko jest "okresowo" włączany - w razie potrzeb. Po każdym restarcie serwera to pierwsze wywołanie trwa dość długo i zastanawiałem się czy dałoby się jakoś zmusić postgresql aby sobie tego cacha z automatu po restarcie przywrócił. Mogę w cronie dodać zadanie gdzie wykonam select'a ale gdzieś mi się obiło o uszy/oczy, że da się jakoś te statystyki zautomatyzować. Macie pomysł?

Chyba szybciej napisałem niż dobrze poszukałem. Załatwię to poprzez https://www.postgresql.org/docs/9.2/monitoring-stats.html ?

0

Hmm, mam wrażenie, że statystyki nie pomogą. Z tego co napisałeś, to problemem wydaje mi się rozgrzanie cache systemowego. Pierwsze zapytanie, które leci po całej tabelce powoduje odczyt bloków danych z dysku, przy okazji tych odczytów system operacyjny umieszcza te bloki w cache.

Nie wiem pod jakim systemem masz tego postgresa, więc zakładam, że to Linux ;) Możesz zerknąć na różne narzędzia, które pomogą wrzucić plik do cache systemowego. Procedura uruchamiania postgresa mogłaby zawierać element "rozgrzewania cache" (np. fadvise i wskazanie, że plik będzie wkrótce używany, a później np. md5sum na pliku powinno wymusić podniesienie bloków pliku do cache).

To tylko moje podejrzenia i sugestie klasy 'hack', ale jak masz czas i potrzebę na zweryfikowanie różnych możliwości, to chętnie się dowiem jak poszło i zaktualizuję bazę wiedzy ;-)

edycja:
Inna opcja, to tuż po starcie postgresa wywołać select * from tabelka i też cache powinien zostać rozgrzany. Znowu jako element skryptu startowego.

0
yarel napisał(a):

Hmm, mam wrażenie, że statystyki nie pomogą. Z tego co napisałeś, to problemem wydaje mi się rozgrzanie cache systemowego. Pierwsze zapytanie, które leci po całej tabelce powoduje odczyt bloków danych z dysku, przy okazji tych odczytów system operacyjny umieszcza te bloki w cache.

Nie wiem pod jakim systemem masz tego postgresa, więc zakładam, że to Linux ;) Możesz zerknąć na różne narzędzia, które pomogą wrzucić plik do cache systemowego. Procedura uruchamiania postgresa mogłaby zawierać element "rozgrzewania cache" (np. fadvise i wskazanie, że plik będzie wkrótce używany, a później np. md5sum na pliku powinno wymusić podniesienie bloków pliku do cache).

To tylko moje podejrzenia i sugestie klasy 'hack', ale jak masz czas i potrzebę na zweryfikowanie różnych możliwości, to chętnie się dowiem jak poszło i zaktualizuję bazę wiedzy ;-)

edycja:
Inna opcja, to tuż po starcie postgresa wywołać select * from tabelka i też cache powinien zostać rozgrzany. Znowu jako element skryptu startowego.

Dzięki w wolnej chwili sprawdzę. Natomiast link, który zamieściłem - póki co rozwiązał temat.

0
woolfik napisał(a):

Dzięki w wolnej chwili sprawdzę. Natomiast link, który zamieściłem - póki co rozwiązał temat.

Co konkretnie ustawiałeś?

Postgres nie raz mnie zaskakiwał, ale takiej magii nie rozumiem i chętnie się dowiem co i dlaczego :) Statystyki wg mojej wiedzy mają wpływ na planistę zapytań, ale dla zapytań typu select * from tabelka trzeba podnieść wszystkie bloki do pamięci.

Na razie tłumaczę sobie to tak, że szybkie działanie po wprowadzonych zmianach, może być efektem ubocznym procedury testowej :-)
Np. mogła wyglądać tak:

  • Postgres został podniesiony, poleciało zapytanie select * from tabelka i trwało ~20 sekund (przy czym bloki danych trafiły do cache systemowego)
  • Postgres został zatrzymany, jakaś magia na statystykach, postgres został ponownie podniesiony i zapytanie trwało szybko (bo dane były w cache systemowym, który nie został wyczyszczony przed podniesieniem bazy)
1

też jestem ciekaw co to za sposób z tymi statystykami, jakieś wymuszenie przebudowania statystyk na starcie? co powinno spowodować podniesienie całej bazy do pamięci...

w każdym razie postgress ma dedykowane rozwiązanie do rozgrzania cache:
pg_prewarm

1 użytkowników online, w tym zalogowanych: 0, gości: 1