Назад | Перейти на главную страницу

PostgreSQL: множество больших массивов и записей

Я запускаю программу python, которая порождает 8 потоков, и каждый поток запускает свой собственный процесс postmaster через psycopg2. Это сделано для максимального использования ядер ЦП (8). Каждый поток вызывает серию функций SQL. Большинство этих функций проходят через многие тысячи строк, каждая из которых связана с большим массивом FLOAT8 [] (250–300) значений, используя unnest () и умножая каждый FLOAT8 на другой FLOAT8, связанный с каждой строкой. Этот подход с использованием массивов минимизировал размер индексов и таблиц. Функция заканчивается вставкой в ​​другую таблицу строки той же формы (pk INT4, массив FLOAT8 []). Некоторые функции SQL, вызываемые python, обновляют строку таких таблиц (с большими массивами).

В настоящее время я настроил PostgreSQL на использование большей части памяти для кеша (по-моему, effective_cache_size 57 ГБ) и лишь небольшой ее части для общей памяти (1 ГБ, по-моему). Во-первых, мне было интересно, в чем разница между кешем и общей памятью в отношении PostgreSQL (и моего приложения).

Я заметил, что только около 20-40% от общей вычислительной мощности моего процессора используется во время наиболее интенсивных операций чтения в приложениях (Select unnest (array) и т. Д.). Итак, во-вторых, мне было интересно, что я могу сделать, чтобы улучшить это, чтобы использовать 100% ЦП. Судя по моим наблюдениям, похоже, что это не имеет ничего общего с python или его GIL.

Спасибо

Похоже, вы столкнулись с узким местом ввода-вывода. У вас много кэш-памяти, но насколько велик набор данных? Какая текущая конфигурация диска? Насколько заняты диски? Может ли узким местом быть сеть?

Еще одна вещь, которую нужно проверить, - это сколько рабочей памяти имеет каждый процесс. Вполне возможно, что трафик памяти очень большой без причины.

Этот сайт есть хороший обзор для настройки postgres.

Effective_cache_size не меняет никаких настроек памяти, он используется только для оценки при планировании запросов. Увеличьте shared_buffers примерно до 25% доступной оперативной памяти и посмотрите, есть ли различия в скорости.

Кроме того, используйте EXPLAIN, чтобы получить план запроса и посмотреть, нужны ли вам дополнительные индексы или лучшая конфигурация.