Zoptymalizuj PostgreSQL pod kątem wielu WSTAWEK i aktualizacji bajtów

Co mamy (oprogramowanie):

• PostrgeSQL 9.3 z konfiguracją podstawową (bez zmian postgresql.conf)
• Windows 7 64-bitowy

Sprzęt komputerowy:

• Intel Core i7-3770 3,9 GHz
• 32 GB pamięci RAM
• WDC WD10EZRX-00L4HBAta Drive (1000 Gb, SATA III)

Tak więc musimy załadować do DB aprox. 100 000 000 wierszy z kolumną bytea i prostszych 500 000 000 wierszy (bez LOB). Istnieją 2 varcharindeksy na 1. stole (o długości 13, 19) i 2 varcharindeksy na 2. stole (18, 10 długości). Istnieją również sekwencje generowania identyfikatorów dla każdej tabeli.

Do tej pory te operacje są wykonywane przy 8 połączeniach równoległych z wielkością partii 50 JDBC. Poniższy rysunek pokazuje obciążenie systemu: zerowe obciążenie postgresqlprocesów. Po 24 godzinach załadowania załadowaliśmy tylko 10 000 000 wierszy, co jest wynikiem bardzo wolnym.

Prosimy o pomoc w strojeniu PostrgreSQLkonfiguracji w celu:

1) w przypadku bardzo szybkiego ładowania tej ilości danych jest to operacja jednorazowa, więc może być konfiguracją tymczasową

2) dla trybu produkcyjnego do wykonywania umiarkowanej liczby SELECT w tych 2 tabelach według ich indeksów bez łączenia i bez sortowania.

Aby uzyskać informacje o insertwydajności, zobacz Przyspieszenie wydajności wstawiania w PostgreSQL i wstawiania zbiorczego w PostgreSQL .

Marnujesz czas na wsadowe przetwarzanie JDBC insert. PgJDBC nie robi nic użytecznego z insertpartiami, po prostu uruchamia każdą instrukcję . <- Nie jest to już prawdą w nowszych wersjach PgJDBC, które mogą teraz grupować przygotowane instrukcje, aby znacznie skrócić czas podróży w obie strony. Ale nadal lepiej jest:

COPYZamiast tego użyj ; patrz kopia partii PgJDBC i CopyManager. Jeśli chodzi o liczbę współbieżnych programów ładujących: celuj w parę na dysk, jeśli operacje są związane z dyskowymi operacjami we / wy. Osiem to prawdopodobnie najbardziej, czego będziesz chciał.

W przypadku „trybu produkcyjnego” sugeruję załadowanie próbki danych, skonfigurowanie zapytań, które mają zostać uruchomione, i użycie explain analyzedo zbadania wydajności. Wyłącznie do celów testowych użyj parametrów, enable_aby zbadać różne opcje wyboru planu. Ustawianie parametrów kosztowych Planowanie query ( random_page_cost, seq_page_cost, effective_cache_sizeitp) odpowiednio dla danego systemu i upewnij się, że shared_buffersjest odpowiednio ustawione. Kontynuuj monitorowanie, dodając symulowane obciążenie produkcyjne, używając auto_explainmodułu, log_min_duration_statementustawienia, pg_stat_statementsrozszerzenia itp.

Szczegółowe informacje można znaleźć w instrukcji obsługi PostgreSQL. Sugeruję wrócić tutaj, gdy masz bardziej konkretny problem ze explain analyzeszczegółami wykonania zapytania itp.