Оптимізуйте PostgreSQL для багатьох оновлень INSERTS та bytea

Що ми маємо (програмне забезпечення):

• PostrgeSQL 9.3 з базовою конфігурацією (без змін у postgresql.conf)
• Windows 7 64 біт

Обладнання:

• Intel Core i7-3770 3,9 ГГц
• 32 Гб оперативної пам’яті
• Привід WDC WD10EZRX-00L4HBAta (1000Gb, SATA III)

Отже, ми маємо завантажити в aprox БД. 100.000.000 рядків зі стовпцем байта та більш простими 500 000 000 рядків (без LOB). На varchar1 таблиці (з довжиною 13, 19) є 2 varcharіндекси та 2 індекси на 2 таблиці (18, 10 довжини). Існують також послідовності для створення ідентифікаторів для кожної таблиці.

На сьогоднішній день ці операції виконуються з 8 з'єднань паралельно з розміром партії 50 JDBC. На малюнку нижче показано навантаження системи: воно на нульовому рівні завантажується postgresql. Після 24 годин завантаження ми завантажили лише 10 000 000 рядків, що є дуже повільним результатом.

Ми просимо допомоги в налаштуванні PostrgreSQLконфігурації в цілях:

1) для надшвидкого завантаження цього обсягу даних це лише один раз операція, тому це може бути тимчасова конфігурація

2) для режиму виробництва для виконання помірної кількості SELECT в ці 2 таблиці за їх індексами без приєднання та без сортування.

Для insertпродуктивності див. Прискорення продуктивності вставок у PostgreSQL та масової вставки в PostgreSQL .

Ви витрачаєте свій час на партію JDBC insert. PgJDBC не робить нічого корисного з insertпартіями, він просто запускає кожну операцію . <- Це більше не стосується нових версій PgJDBC, які тепер можуть створювати підготовлені заяви, щоб значно скоротити час в обидва кінці. Але все ж краще:

Використовувати COPYзамість цього; див. пакетну копію PgJDBC та CopyManager. Що стосується кількості одночасних навантажувачів: Націліться на пару на диск, якщо операції пов'язані з диском вводу / виводу. Вісім, мабуть, найбільше вам захочеться.

Для вашого "режиму виробництва" я пропоную завантажити зразок даних, налаштувати запити, які ви очікуєте виконувати, та використовувати explain analyzeдля дослідження ефективності. Тільки для тестування використовуйте enable_парами для вивчення різних виборів плану. Встановіть параметри витрат планувальник запитів ( random_page_cost, seq_page_cost, effective_cache_size, і т.д.) відповідно для вашої системи, і переконайтеся , що shared_buffersїї правильно встановлено чином . Продовжуйте контролювати, додаючи модельоване виробниче навантаження, використовуючи auto_explainмодуль, log_min_duration_statementналаштування, pg_stat_statementsрозширення тощо.

Детальніше див. У посібнику користувача PostgreSQL. Я пропоную вискакувати тут, коли у вас є конкретніша проблема з explain analyzeдеталями виконання запитів тощо.