Настройки по умолчанию postgresql.conf написаны для "слабой" конфигурации железа
max_connections - определяет максимальное количество одновременных соединений, обслуживаемые сервером
При необходимости - ошибка "too many clients" - увеличивайте значение
На поддержку каждого активного соединения тратится большое количество ресурсов
Если необходимо добиться производительности 1000+ активных соединений - используйте менеджеры pgpool и pgbouncer
shared_buffers — определяет размер буферного кеша
Используется для работы с наиболее часто используемыми данными
Хранит эти данные в оперативной памяти для избегажания обращений к диску
Параметр оптимально указать с 25% от общего объема ОЗУ и увеличивать по необходимости
Проводите тестирование сервера нагрузками для получения оптимального результата параметра
Слишком большое значение более 40% скорее всего негативно скажется на производительности
При увеличении shared_buffers потребуется увеличить max_wal_size
Необходимо для растягивания процесса записи на более продолжительное время большого объема новых или измененных данных
effective_cache_size "подсказывает" pgsql, на какой общий размер кеша рассчитывать, включая кеш операционной системы
Чем выше это значение, тем большее предпочтение отдается индексам.
Оптимально указать около 50–70% от объема ОЗУ
work_mem - объем памяти, выделяемый для выполнения сортировки и построения хеш-таблиц при выполнении соединения
Признаком того, что памяти недостаточно, является активное использование временных файлов и падения производительности
Значение по умолчанию - 4МБ, в большинстве случаев подойдет увеличение минимум в несколько раз
maintenance_work_mem - размер памяти, выделяемой служебным процессам
Увеличение может ускорить построение индексов и процесс очистки - vacuum
Оптимально назначить в несколько раз превышающее значения work_mem
Не стоит устанавливать значение по умолчанию слишком большим
Когда выполняется автоочистка, этот объем может быть занят autovacuum_max_workers
Вероятно лучше управлять объемом памяти для автоочистки отдельно через autovacuum_work_mem
Пример ОЗУ = 64ГБ:
shared_buffers = '16GB'
effective_cache_size = '48GB'
work_mem = '256MB'
maintenance_work_mem = '1GB'
random_page_cost и seq_page_cost
Отношение двух параметров должно соответствовать отношению скоростей произвольного и последовательного доступа к диску
По умолчанию значения для: произвольный доступ в 4 раза медленнее последовательного в расчете на обычные HDD-диски
Для SSD-дисков значение random_page_cost надо уменьшить, попробуйте random_page_cost = 1.2
Никогда не изменяйте значение seq_page_cost = 1
Настройка автоочистки - autovacuum, занимается "сборкой мусора" и выполняет ряд других не менее важных для задач
Уменьшите значение например autovacuum_vacuum_scale_factor = 0.01, чтоб очистка выполнялась чаще и меньшими порциями
Журнал транзакций pgsql работает следующим образом:
Все изменения в файлах данных (таблицы и индексы) производятся после того, как они были занесены в журнал транзакций
Записи в журнале транзакций при этом должны быть гарантированно записаны на диск
В этом случае нет необходимости сбрасывать на диск изменения данных при каждом успешном завершении транзакции:
В случае сбоя БД может быть восстановлена по записям в журнале
Таким образом, данные из буферов сбрасываются на диск при проходе контрольной точки
Либо при заполнении нескольких (параметр checkpoint_segments, по умолчанию 3) сегментов журнала транзакций
Либо через определенный интервал времени (параметр checkpoint_timeout, измеряется в секундах, по умолчанию 300)
Изменение этих параметров прямо не влияет на скорость чтения, но может нести пользу, если данные БД активно изменяются
Добиться хорошего прироста производительности — разнести файлы БД и журнала транзакций по разным дискам
Данные в сегменты журнала пишутся последовательно, более того, записи в журнале транзакций сразу сбрасываются на диск
Не делайте так!
Выключение автоочистки (autovacuum = off)
Приведет к накоплению "мусора" в данных и росту таблиц и индексов
Приведет к остановке нормального функционирования БД
Выключение синхронизации с диском (fsync = off)
Любой сбой сервера (программный или аппаратный) приведет к полной потере баз данных
Восстановить систему можно будет только из резервной копии!
Эталонные тесты - утилита pgbench
Вычисляет среднюю скорость транзакции (количество транзакций в секунду) (transactions per second – TPS)
Установка (указана версия 15):
sudo yum install postgresql15-contrib -y
sudo apt install postgresql15-contrib -y
cp /usr/pgsql-15/bin/pgbench /usr/bin
флаг -i служит для создания в базе данных тестовых таблиц
table # of rows
---------------------------------
pgbench_branches 1
pgbench_tellers 10
pgbench_accounts 100000
pgbench_history 0
По умолчанию простая БД в 16MB
флаг -s используется для умножения количества строк, введенных в каждую таблицу
В приведенной выше команде мы ввели опцию "масштабирования", равную 50
pgbench создаст базу данных в 50 раз больше размера по умолчанию
Теперь таблица pgbench_accounts теперь содержит 5,000,000 записей
Размер нашей БД теперь составляет 800MB ( 50 x 16MB )
$ pgbench -i -s 50 test_db
Базовая линия
Служит для измерения того, повлияли ли внесенные вами изменения на увеличение или снижение производительности
Установим базовый уровень для нашего экземпляра:
$ pgbench -c 10 -j 2 -t 10000 test_db
флаги:
-c (клиенты), количество "клиентов", с которыми нужно соединиться, в примере открывает 10 одновременных сессий
-j (threads), определяет количество рабочих процессов, в примере 2
-t (транзакции), количество транзакций, которые нужно выполнить, в примере каждая сессия выполнит 10000 транзакций
Наш тестовый запуск:
состоял из 2 рабочих процессов pgbench
имитировано 10000 транзакций от 10 клиентов
в общей сложности было выполнено 100000 транзакций
После выполнения команд обратите внимание на показатели (пример):
tps = 1456.328201 (including connections establishing)
tps = 1456.923372 (excluding connections establishing)
Наша базовая линия составила 1,456 транзакции базы данных в секунду
Смотрим кол-во памяти для выделения (пример, вывод обрезан):
$ free -m
..... total ... available
Mem:. 2000 .... 1000
В примере мы видим 2000MB физической памяти, available - 1000MB доступных, которые можно использовать
Рекомендуемое значение shared_buffers - 25% системной памяти = 512MB:
shared_buffers = 512MB
После выполнения команд обратите внимание на показатели (пример):
tps = 2456.328201 (including connections establishing)
tps = 2456.923372 (excluding connections establishing)
В примере мы видим, что изменение параметра дало рост производительности с 1,5 до 2,5 транзакций в секунду
Комментарии пользователей
Эту новость ещё не комментировалиНаписать комментарий
Анонимам нельзя оставоять комментарии, зарегистрируйтесь!
Код обмена баннерами