Zbyt dużo operacji we / wy generowanych przez proces zbierania statystyk postgres

10

Używam XenServer z kilkoma maszynami wirtualnymi z lokalnymi bazami danych Postgres. Nawet gdy wszystkie aplikacje są nieużywane, a bazy danych są bezczynne, każda maszyna wirtualna powoduje stały ruch sieciowy w pamięci masowej, co zmniejsza wydajność urządzenia pamięci masowej iscsi.

Po uruchomieniu iotopzauważyłem, że proces gromadzenia statystyk postgres ciągle zapisuje na dysk z prędkością około 2 MB / s.

Następnie wyłączyłem zbieranie statystyk, edytując /etc/postgresql/8.4/main/postgresql.conf:

#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------

# - Query/Index Statistics Collector -

track_activities = off
track_counts = off
...

jak sugerowano w http://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htm .

To wyeliminowało ciągłe pisanie, ale czy są jakieś wady wyłączające śledzenie statystyk?

Czy powinienem raczej umieścić katalog pg_stat_tmp na ramdysku, aby uniknąć ruchu dysku / sieci?

System to aktualny Debian 6.0.7 (squeeze) z postgres 8.4 i około 20 bazami danych z około 50 tabelami, całkowity rozmiar pliku zrzutu jest mniejszy niż 100 MB.

performance postgresql performance-tuning database-performance nn4l
źródło

Odpowiedzi:

7

Ponieważ aktualizacja PostgreSQL nie jest opcją, próbowałem umieścić katalog pg_stat_tmp w systemie plików tmpfs, co zapewniło znaczną poprawę wydajności. Pracuję teraz na kilkudziesięciu systemach od kilku miesięcy bez zauważalnych wad.

Aby to zrobić, po prostu zamontuj pg_stat_tmp z tmpfs w pliku / etc / fstab:

# <file system> <mount point>                                <type>  <options>  <dump>  <pass>
tmpfs           /var/lib/postgresql/8.4/main/pg_stat_tmp     tmpfs   defaults,noatime,mode=1777,uid=postgres,gid=postgres,nosuid,nodev 0 0
nn4l
źródło
Zrobiłem to dla Postgresql 9.1. Jeden z moich serwerów miał ciągły zapis 1 MB / s przez cały dzień. To sprawiło, że spadło prawie do zera. Zostało to zatwierdzone przez doktorów BTW: „... Wskazanie tego na system plików oparty na pamięci RAM zmniejszy fizyczne wymagania we / wy i może poprawić wydajność.”
Halfgaar
0

Zaktualizuj PostgreSQL. Przy absolutnym minimum upewnij się, że korzystasz z najnowszej wersji 8.4; jeśli to nie rozwiązuje problemu i warto to zrobić, prawdopodobnie powinieneś zaktualizować do wersji 9.2. Przynajmniej niektóre problemy wokół modułu gromadzącego statystyki zostały rozwiązane od 8.4, a ich koniec będzie za około rok . Możesz znaleźć więcej informacji, przeszukując archiwa listy mailingowej pgsql-general .

Nie powinieneś mieć zbyt wielu problemów z aktualizacją z wersji 8.4 do 9.2, ale jak zwykle musisz przeczytać sekcję dotyczącą aktualizacji informacji o wydaniu dla każdej wersji .0 pomiędzy (9.0, 9.1 i 9.2). Zwróć szczególną uwagę na standard_conforming_stringsi bytea_output.

Craig Ringer
źródło
0

Mam ten sam problem. Wyłączyłem również track_*i tak dalej.

Efektem ubocznym jest autovacuumwykorzystanie zebranych danych do uruchomienia.

Staram się więc zaplanować co wieczór vacuumdb.

Innym rozwiązaniem jest ustawienie autovacuum_naptimewystarczająco wyższej, aby system mógł spoczywać.

Gelma
źródło