Несколько лет назад стартовал проект  Рostgres pro. Это специализированный Postgre SQL для работы с 1с и не только.

И так, для работы мы выбрали именно PG от этого производителя, на момент написания статьи уже вышел PG 12-ого релиза. Но пока мы его не будем рассматривать, так как он еще в начале своего пути, дождемся когда он перейдет в более стабильны и протестированные релиз версии. Ранее релиза 12.2 я считаю нет смысла внедрять его в продакшн и на боевые сервера, только как тестинг.

Наша рабочая конфигурация которую будем тюнинговать:
OS Debian 9 в связке с Postgre SQL 11.6.1.
HDD 1 Tb RAID из 8 SSD дисков.
MEM 120 Gb
CPU Intel(R) Xeon(R) CPU X5690 @ 3.47GHz, 24 ядра.

И так, как нам уже известно, Postgre SQL по своей производительности в связке с 1с во многих аспектах уже догнал и даже обогнал хваленую MS SQL.
Но как только мы ставим PG из коробки и настриваем ее для работы с нашей 1с, мы видим крайне удручающие показатели... И гдеже хваленая производительность спросите Вы? Что же, ответ очевиден: Нужно тюненговать PG для работы с Вашей системой. К сожалению PG в отличии от того же MS SQL все еще не научилась автоматически подстариваться под работу вашего сервера. Давайте рассмотрим первоначальный этап настройки:

Для этого нам понадобится сервис PGTune. Тут нам нужно заполнить данные нашего сервера, должно получиться что вроде этого, на примере моего сервера:

Вот так заполненено у меня. Тут имеется кнопка "Copy configuration" Забудьте про нее, если Вы скопипастите этот конфиг просто в конфиг PG то он у Вас упадет.
Заходим на серер по SSH от имени root или через su, sudo. На серере нам нужно найти конфигурационный файл PG, в моем случае он находится в директории

/var/lib/pgpro/std-11/data/

PS: Перед началом работ советую сделать бэкап файла postgresql.conf

Далее я буду писать все команды как на моем сервере Debian 9 и PG 11.

cd /var/lib/pgpro/std-11/data
nano postgresql.conf

В этом файле мы меняем параметры которые берем с сайта PGTune. Опять же повторюсь, не весь конфиг меняем, а только те строчки что есть на сайте PGTune.
В моем случае это:

max_connections = 150
shared_buffers = 30GB
effective_cache_size = 90GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 500
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 8738kB
min_wal_size = 4GB
max_wal_size = 8GB
max_worker_processes = 24
max_parallel_workers_per_gather = 12
max_parallel_workers = 24

Остальные строчки оставляем как есть. 

Перезапускаем службу PG

/etc/init.d/postgrespro-std-11 stop
/etc/init.d/postgrespro-std-11 restart

Проверяем скорость работы Вашей 1с, должна вырасти в разы.

Но это не все, можно еще ускорить работу, для этого нам понадобится заняться тюнингом самой системы, а именно... У PG есть сервис "Stats Collector". В кратце, это сервис по сбору статистики работы баз данных, без этого сервиса некуда, но он грузит дисковый массив больше чем сами базы, этот факт не очень нас устраивает.
На моем сервере на котором уже лежит 56 баз данных, общим объемом в 320 гигабайт, эта служба сильно грузит RAID массив, в среднем 70 Mb/s идет чтение и запись на массиве, это как то не радует.
Поэтому я предлагаю избавиться от той ненужной нам нагрузки, заодно в моем случае еще и продлим срок службы SSD дисков...

PS: отключать данный сервис нельзя, так как без него стабильно PG работать небудет.

Мы его будем переносить полностью в оперативную память, пусть ее грузит а не диски, да и объем этих файлов крайне не велик, калеблится  районе от 36mb, до 250mb. 
Для этого нам понадобится создать в системе ram диск.
Для начала создадим каталог монтирования

mkdir /mnt/tmpfs/

Дадим на него полные права

chmod 777 /mnt/tmpfs/

Сменим пользователя из-под которого запущен наш PG

chown -R postgres:postgres /mnt/tmpfs/

Подмонтируем новый диск к системе. Что бы перестраховаться, так как баз у меня много и будут еще увеличиваться, я беду размер диска 512mb, с запасом.

mount -t tmpfs -o size=512M tmpfs /mnt/tmpfs/

Идем в файл fstab и переписываем запись этого диска для автоматического подключения после перезагрузки.

nano /etc/fstab

Вот так должна выглядеть запись в fstab по данному диску

tmpfs   /mnt/tmpfs      tmpfs   size=524288k,relatime   0       0

Добавим новый путь в Postgres

nano /var/lib/pgpro/std-11/data/postgresql.conf

Тут нужно прописать путь к новому место хранения Stats Collector

stats_temp_directory = '/mnt/tmpfs'

Перезагружаем сервер, все должно работать.

Проверить работоспособность можно зайдя в этот каталог, в нем примерно через 30 минут работы должны появиться файлы:

 Далее только для SSD дисков или RAID массивов.

Это все нам позволило снять ненужную нам нагрузку с дискового массива, теперь рассмотрим следующее, это наоборот нагрузит наш дисковый массив, но уже нагрузит его для ускорения работы, нам нужно изменить параметр checkpoint_completion_target, он у нас отвечает за:

 — это доля времени между контрольными точками для завершения контрольной точки. Высокая частота контрольных точек может повлиять на производительность. Для плавного выполнения задания контрольной точки, checkpoint_timeout должен иметь низкое значение. В противном случае ОС будет накапливать все грязные страницы до тех пор, пока соотношение не будет соблюдено, а затем производить большой сброс.

Мы уменьшим время ожидания, меньше ожидания, быстрее запись.
Для этого вводим в терминале:

nano /var/lib/pgpro/std-11/data/postgresql.conf

И меняем параметр на

checkpoint_completion_target = 0.1

Закрываем конфиг с сохранением и перезапускам PG

/etc/init.d/postgrespro-std-11 stop
/etc/init.d/postgrespro-std-11 restart

Проверяем скорость работы 1с.

Автор статьи: Ершов И.Д.

Добавить комментарий