Obecnie stoi przed problemem z kilkoma wyborem przez klucz podstawowy. Wybór czasami zajmuje więcej niż 10 sekund, aby zwrócić wiersz. Przeanalizowałem plan egzekucji i zweryfikowałem, że jest w porządku.

Zacząłem wyglądać zapytania biegające w bazie danych z następującymi wyborem:

select wait_event_type, wait_event, count(1)
from pg_stat_activity
where state <> ‘idle’
and state is not null
group by wait_event_type, wait_event
order by count(1) desc;

Potem widziałem wiele sesji czekających w Lock_manager: Wait_Event_type / wait_event według Liczba

Następnie poszedłem do pg_locks, aby zobaczyć, jaki rodzaj zamka powoduje wydanie: Blokada według trybu . Najczęstszym trybem blokady był AccessShaRelock . Widziałem też przeciętny zamek PID i było około 3000. Większość zamków znajdują się w tabelach podzielonych (mój wybór przechodzi przez stół główny, a AccessSharelock są we wszystkich partycjach i indeksy partycji). Zwiększyłem max_locks_per_transaction od 128 do 5120, ale nie miał żadnych ulepszeń.

Kolejną rzeczą, którą robię, był prowadzony perf top i zobacz, co była "funkcją gorącej": hash_search_with_hash_value. Perf Top

Maszyna serwera jest z niskim użytkowaniem procesora: 20%.

Czy masz dla tego jakieś rozwiązanie? Potrzebujesz więcej informacji?

1
Fabio Brandão 19 październik 2020, 22:05

1 odpowiedź

Najlepsza odpowiedź

Pierwszą rzeczą byłoby uaktualnienie z V11 do (przynajmniej) V12. Rozpocznienie stało się znacznie bardziej wydajne, z kolei blokowania dla pojedynczej partycji wyboru, w tej wersji.

1
jjanes 20 październik 2020, 17:08