Оптимизация производительности Postgresql
Оптимизация производительности
По умолчанию конфигурация PostgreSQL рассчитана для работоспособности с наименьшим колличеством ресурсов
PostgreSQL использует свой собственный буфер и буферизованный IO ядра
Буфер PostgreSQL называется shared_buffer. Postgresql не использует прямой ввод/вывод
Параметр shared_buffer устанавливает сколько выделенной памяти будет использоваться для кеширования
Рекомендуемое значение shared_buffer составляет 25% от общего объема оперативной памяти машины, однако изменяя этот параметр в меньшую или в большую сторону, можно получить более высокую производительность
Выделять для shared_buffers более 40% ОЗУ вряд ли будет полезно. При увеличении shared_buffers обычно требуется соответственно увеличить max_wal_size, чтобы растянуть процесс записи большого объёма новых или изменённых данных на более продолжительное время
SHOW shared_buffers;
wal_buffers - объем разделяемой памяти, которая будет использоваться для буферизации данных в буфер WAL, которые еще не записаны на диск
Postgresql сначала записывает в WAL (журнал предзаписи), потом эти записи сбрасываются на диск.
Если много одновременных подключений, то более высокое значение может повысить производительность
Значение по умолчанию, равное -1, задаёт размер, равный 1/32 (около 3%) от shared_buffers, но не меньше чем 64 КБ и не больше чем размер одного сегмента WAL (обычно 16 МБ)
Если это значение задаётся без единиц измерения, оно считается заданным в блоках WAL (размер которых равен XLOG_BLCKSZ байт, обычно это 8 КБ)
Содержимое буферов WAL записывается на диск при фиксировании каждой транзакции, очень большие значения вряд ли принесут пользу. Однако значение как минимум в несколько мегабайт может увеличить быстродействие при записи на нагруженном сервере, когда сразу множество клиентов фиксируют транзакции.
Автонастройка, действующая при значении по умолчанию (-1), в большинстве случаев выбирает разумные значения
max_wal_size - Максимальный размер, до которого может вырастать WAL во время автоматических контрольных точек
Значение по умолчанию — 1 ГБ
Увеличение этого параметра может привести к увеличению времени, которое потребуется для восстановления после сбоя
effective_io_concurrency - задаёт допустимое число параллельных операций ввода/вывода, которое говорит PostgreSQL о том, сколько операций ввода/вывода могут быть выполнены одновременно.
Чем больше это число, тем больше операций ввода/вывода будет пытаться выполнить параллельно PostgreSQL в отдельном сеансе.
Допустимые значения лежат в интервале от 1 до 1000, а нулевое значение отключает асинхронные запросы ввода/вывода
Если продолжать увеличивать это значение при полной загрузке дисков, это приведёт только к увеличению нагрузки на процессор. Диски SSD и другие виды хранилища в памяти часто могут обрабатывать множество параллельных запросов, так что оптимальным числом может быть несколько сотен.
Возможные причины тормозов
Бывает, что приложение не оптимизировано под многоядерную архитектуру: использует на 100% только одно ядро, а остальные простаивают без нагрузки.
Также можно попробовать проверить настройки энергопотребления в BIOS сервера. Многие администраторы включают в BIOS режим High Performance и тем самым отключают технологии энергосбережения C-states и P-states. В современных процессорах Intel используется технология Turbo Boost, которая увеличивает частоту отдельных ядер процессора за счет других ядер. Но она работает только при включенных технологиях энергосбережения. Если мы их отключаем, то процессор не может уменьшить энергопотребление ядер, которые не нагружены.
VMware рекомендует не отключать технологии энергосбережения на серверах, а выбирать режимы, которые максимально отдают управление энергопотреблением гипервизору. При этом в настройках энергопотребления гипервизора нужно выбрать High Performance.
Если у вас в инфраструктуре отдельные ВМ (или ядра ВМ) требуют повышенную частоту CPU, корректная настройка энергопотребления может значительно улучшить их производительность.