Comments 5
Как-то много всего написано без подтверждения тестами.
Доступно множество решений, включая NMVe и SSD-накопители.
Первое правило — отделить диск WAL от диска данных.
Мой опыт: на современных серверных накопителях wal не вызывает какой-либо заметной нагрузки.
Писал про это не раз, например.
Да, рецепт был актуален в эпоху hdd, которые «не любят» смешанной нагрузки. Однако даже тогда в случае использования контроллера, умеющего writeback кэширование, этот рецепт чаще приносил вред, чем пользу.
Не в рекламу, давно пользуюсь этим инструментом рассчета, у автора написанные грамотно книги с множеством редакций
Начиная с версии 2.15.0 tuned пакет включает в себя профиль для PostgreSQL
$ dnf info tuned-profiles-postgresql
Last metadata expiration check: 0:00:14 ago on Mon Feb 13 14:49:29 2023.
Available Packages
Name : tuned-profiles-postgresql
Version : 2.19.0
Release : 1.el8
Architecture : noarch
Size : 38 k
Source : tuned-2.19.0-1.el8.src.rpm
Repository : appstream
Summary : Additional tuned profile(s) targeted to PostgreSQL server loads
URL : http://www.tuned-project.org/
License : GPLv2+
Description : Additional tuned profile(s) targeted to PostgreSQL server loads.
Так все таки выключить huge pages или настроить?
странно что work_mem не учитывает max_connections, мне кажется очень сомнительное значение мы получим при большом объеме ОЗУ и большом количестве подключений. Даже при использовании pgbouncer в режиме transaction будет многократное выделение work_mem + для OLT нагрузки значение получается завышенное. Мне кажется тут лучше сделать меньше и отталкиваться от мониторинга временных файлов наличие которых покажет необходимость увеличения work_mem
Неплохо бы раскрыть подробнее vm.overcommit_memoryт.к. разные значения используются в разных кейсах.
для arhive я использую связку для первичной настройки
archive_mode = on
archive_command = '/bin/true'
т.к. изменение archive_mode требует перезапуска службы а archive_command нет.
PostgreSQL: настройка и оптимизация производительности. Часть 1