Używamy Postgres 9.1.3 i ostatnio zaczęliśmy borykać się z poważnymi problemami z wydajnością na jednym z naszych serwerów.

Nasze zapytania działały przez pewien czas, ale od 1 sierpnia dramatycznie spowolniły. Wydaje się, że większość problematycznych zapytań to zapytania Select (zapytania z count (*) są szczególnie złe), ale generalnie baza danych działa po prostu bardzo wolno.

Biegliśmyto zapytanie na serwerze i były to zmiany, które wprowadziliśmy w domyślnym pliku konfiguracyjnym (Uwaga: serwer działał dobrze z tymi zmianami wcześniej, więc prawdopodobnie nie mają większego znaczenia):

       name            |                                                current_setting
---------------------------+---------------------------------------------------------------------------------------------------------------
version                   | PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by  gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51), 64-bit
autovacuum                | off
bgwriter_delay            | 20ms
checkpoint_segments       | 6
checkpoint_warning        | 0
client_encoding           | UTF8
default_statistics_target | 1000
effective_cache_size      | 4778MB
effective_io_concurrency  | 2
fsync                     | off
full_page_writes          | off
lc_collate                | en_US.UTF-8
lc_ctype                  | en_US.UTF-8
listen_addresses          | *
maintenance_work_mem      | 1GB
max_connections           | 100
max_stack_depth           | 2MB
port                      | 5432
random_page_cost          | 2
server_encoding           | UTF8
shared_buffers            | 1792MB
synchronous_commit        | off
temp_buffers              | 16MB
TimeZone                  | US/Eastern
wal_buffers               | 16MB
wal_level                 | minimal
wal_writer_delay          | 10ms
work_mem                  | 16MB
(28 rows)

Time: 210.231 ms

Zwykle, gdy pojawiają się takie problemy, pierwszą rzeczą, którą ludzie polecają jest odkurzanie i próbowaliśmy tego. Przeanalizowaliśmy większość bazy danych w próżni, ale to nie pomogło.

UżyliśmyExplain w niektórych naszych zapytaniach i zauważyliśmy, że Postgres uciekał się do skanowania sekwencyjnego, mimo że tabele miały indeksy.

Wyłączono skanowanie sekwencyjne, aby zmusić planistę zapytań do korzystania z indeksów, ale to również nie pomogło.

Potem spróbowaliśmyto zapytanie, aby zobaczyć, czy mamy dużo niewykorzystanego miejsca na dysku, przez które Postgres przechodził, aby znaleźć to, czego szuka. Niestety, podczas gdy niektóre nasze tabele miały trochę luzu, nie wydawało się to wystarczająco istotne, aby spowolnić ogólną wydajność systemu.

Uważamy, że spowolnienie może być związane z I / O, ale nie możemy określić szczegółów. Czy Postgres jest po prostu głupi, a jeśli tak, to w jakiej części? Czy jest coś nie tak z maszyną wirtualną, a może coś jest nie tak z samym sprzętem fizycznym?

Czy macie jakieś inne sugestie dotyczące rzeczy, które możemy wypróbować lub sprawdzić?

EDYTOWAĆ:

Przepraszam, że nie zaktualizowałem tego wcześniej. Dostałem się w inne rzeczy.

Na tej konkretnej maszynie nasza wydajność znacznie się poprawiła, wprowadzając jedną małą modyfikację ustawień maszyny wirtualnej.

Jest ustawienie, które zajmuje się buforowaniem IO. Pierwotnie był ustawiony na ON. Uznaliśmy, że ciągłe buforowanie rzeczy spowalnia pracę i mieliśmy rację. Wyłączyliśmy go i wszystko drastycznie się poprawiło.

Co ciekawe, większość naszych innych serwerów już miała wyłączone to ustawienie.

Są inne problemy i jestem pewien, że przyjmiemy wiele twoich sugestii, więc dziękuję bardzo za pomoc.