Postgres DISK IO bardzo wysoki. Co mogę zrobić, aby to natychmiast zmniejszyć?

Zdaję sobie sprawę, że dyski szybsze niż te, które używam, pomogą, ale ich instalacja zajmie więcej czasu i staram się zastosować środki awaryjne, aby zmniejszyć IO dysku. atop niemal stale raportuje użycie DSK na czerwonym. Dotyczy to postgres 8.3.

Moje ustawienie shared_buffers wynosi 24 MB, chociaż serwer ma 16 GB pamięci RAM, które nie są w pełni wykorzystane. Moją pierwszą myślą było dać bazie danych tyle pamięci RAM, ile tylko mogła, ale nie jestem pewien, jak to zrobić (jest to dedykowany serwer bazy danych).

Każde rozwiązanie, które nie wymaga ponownego uruchomienia jest lepsze, ale wezmę to, co mogę w tym momencie.

Dzięki!

Ustawienie 24 MB shared_buffers jest konserwatywnym domyślnym, powiedziałbym, że powinno być znacznie wyższe dla dedykowanej bazy danych z dostępną 16 GB pamięci RAM. Ale tak, musisz ponownie uruchomić serwer, aby zmienić jego rozmiar. http://wiki.postgresql.org/wiki/Performance_Optimization to dobre miejsce na rozpoczęcie od wytycznych dotyczących konfiguracji wydajności. Ustawienie shared_buffers na 4 GB lub 6 GB wydaje się bardziej rozsądne.

Zauważ, że w Linuksie musisz zmienić ustawienie sysctl kernel.shmmax (w /etc/sysctl.conf lub po prostu pisząc / proc / sys / kernel / shmmax), aby przydzielić blok tej pamięci współdzielonej. Jeśli nie, pojawi się błąd określający, o ile zażądano, musisz ustawić kernel.shmmax wyżej.

Ponieważ masz dużo pamięci, możesz również rozważyć ustawienie domyślnej wartości work_mem na wyższą, co sprawi, że sortowanie i skróty (grupa / kolejność / odrębne itp.) Będą miały tendencję do pracy w pamięci zamiast używania plików tymczasowych. W tym celu nie trzeba ponownie uruchamiać serwera, wystarczy zaktualizować plik konfiguracyjny, ponownie załadować usługę, a nowe sesje otrzymają nowe ustawienie. Domyślna pamięć robocza dla sesji wynosi 1 MB, można obliczyć maksimum, które może być użyte jednocześnie, work_mem * max_client_connectionsi oszacować, jaki będzie to miało wpływ.

Powinieneś także zwiększyć efektywny rozmiar_cache_wybrania, aby poinformować planistę, że warstwa FS jądra prawdopodobnie buforuje wiele stron w pamięci poza współdzielonymi buforami postgresql.

itd. itp. mam nadzieję, że to zapewni dobry start.

Ponownie zamontuj dyski z Noatime

Oprócz podanych tutaj sugestii, możesz również zajrzeć do ustawień automatycznego szczepienia. Domyślnie uruchamia się po około 50 aktualizacjach, a jeśli twoja baza danych wykonuje wiele aktualizacji / wstawek, może to spowodować niepotrzebną liczbę instrukcji próżni, które wygenerują dużo IO.

W systemie, który jest bardzo zbliżony do maksymalnej przepustowości we / wy podczas normalnej pracy, możesz zwiększyć wartość checkpoint_completion_target, aby zmniejszyć obciążenie we / wy z punktów kontrolnych . Wadą tego jest to, że przedłużanie punktów kontrolnych wpływa na czas powrotu do zdrowia, ponieważ trzeba będzie zachować więcej segmentów WAL, aby możliwe było ich wykorzystanie

Zobacz więcej tutaj .

Jeśli diskio postgresql jest bardzo wysokie, powinieneś sprawdzić uruchomione instrukcje, szczególnie dla instrukcji, wykonując „sortowanie na dysku” i ustawić właściwe indeksy.

Wystarczy google dla „Postgresql Performance Tuning”, znajdziesz wystarczająco dużo tylnych miejsc, od których możesz zacząć.