Оптимизируйте PostgreSQL для множества обновлений INSERTS и Bytea

Что мы имеем (софт):

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

Оборудование:

• Intel Core i7-3770 3,9 ГГц
• 32 ГБ ОЗУ
• Накопитель WDC WD10EZRX-00L4HBAta (1000 ГБ, SATA III)

Итак, мы должны загрузить в БД aprox. 100.000.000 строки с BYTEA колонке, и более простой 500.000.000 строк (без LOBs). Есть 2 varcharиндекса на 1-й таблице (с длиной 13, 19) и 2 varcharиндекса на 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деталями выполнения запроса и т. Д.