Обновление платформы 1с на postgresql. Устанавливаем PostgreSQL

Как только размер файловой базы данных 1С:Предприятие одного из наших клиентов достиг размера в 32Гб (да, 32Гб), в следствии чего всё постепенно начало тормозить, а потом и встало намертво, наши клиенты попросили нас решить эту проблемы. SSD Enterprise класса ненадолго подсластил пилюлю, но через некоторое время всё вернулось в исходную точку. Ну что ж, тут и к бабке не ходи - переходим на SQL версию БД.

Поскольку мы ярые пользователи Windows, доступно нам только два варианта СУБД - это MSSql и PostgreSQL. Первый хорош до безумия, но стоимость не порадовала. А ещё больше не порадовала новость о дополнительных лицензиях 1С для работы с MSSQL. Поэтому PostgreSQL.

Подробная инструкция с видео доступна . В этой статье мы пройдёмся по ключевым моментам.

Не забываем про резервное копирование баз данных 1С!

Исходные данные:

ОС Windows Server 2008R2,
Intel Core i7-2600K 3.40GHz,
32Gb RAM,
Intel SSD DC3700 100Gb (только под БД, ОС на отдельном SSD),
от 10 до 20 пользователей в БД ежедневно,
обмен с 5 узлами распределённой БД в фоне.

Зловеще, не правда ли? Приступим.

1. Установка PostgreSQL и pgAdmin.

Никаких откровений по поводу того, откуда качать PostgreSQL не будет — это наш любимый сайт https://releases.1c.ru , раздел «Технологические дистрибутивы». Скачиваем, ставим. Не забываем установить MICROSOFT VISUAL C++ 2010 RUNTIME LIBRARIES WITH SERVICE PACK 1, который идёт в архиве с дистрибутивом. Сами попались на это: не установили, испытали много боли.

Инициализируем кластер базы данных (галочка). А вот здесь задаём параметры учётной записи для PostgreSQL! Важно: у Вас должна быть запущена служба «Secondary Logon» (или на локализированных ОС: «Вторичный вход в систему» ). Кодировка UTF8 — это тоже важно!

pgAdmin в этой сборке староват. Идём на https://www.postgresql.org/ftp/pgadmin3/release/ . На момент написания статьи самая свежая версия 1.22.1. Качаем её, ставим. Заходим.

На процессе установки оснастки «Администрирование серверов 1С Предприятия» не будем останавливаться. Это совсем другая тема. Да и сложного там ничего нет.

Создаём SQL БД в этой оснастке, проверяем в pgAdmin — БД там появиться, если всё указано верно.

2. Тюнинг PostgreSQL 9.4.2.

pg_hba.conf
postgresql.conf
pgpass.conf

которые лежат здесь:

C:\Program Files\PostgreSQL\9.4.2-1.1C\data

Если Вы ошибётесь хоть в одной букве, после обновления конфигурации PostgreSQL не запуститься. Выяснить что же стало причиной будет сложно, даже смотря в журналы Windows. Поэтому не меняйте много параметров сразу и делайте резервные копии.

Для правки конфига есть удобный инструмент, доступный прямо из главного окна pgAdmin. Вот он:

Что мы здесь меняем:

shared_buffers — Количество памяти, выделенной PgSQL для совместного кеша страниц. Эта память разделяется между всеми процессами PgSQL. Делим доступную ОЗУ на 4. В нашем случае это 8Gb.
effective_cache_size — Оценка размера кэша файловой системы. Считается так: ОЗУ — shared_buffers. В нашем случае это 32Gb — 8Gb = 24Gb. Но лично я оставляю этот параметр ещё ниже, где-то 20Gb — всё-таки ОЗУ нужна не только для PostgreSQL.
random_page_cost = 1.5 — 2.0 для RAID, 1.1 — 1.3 для SSD. Стоимость чтения рандомной страницы (по-умолчанию 4). Чем меньше seek time дисковой системы тем меньше (но > 1.0) должен быть этот параметр. Излишне большое значение параметра увеличивает склонность PgSQL к выбору планов с сканированием всей таблицы (PgSQL считает, что дешевле последовательно читать всю таблицу, чем рандомно индекс). И это плохо.
temp_buffers = 256Mb. Максимальное количество страниц для временных таблиц. То есть это верхний лимит размера временных таблиц в каждой сессии.
work_mem — Считается так: ОЗУ / 32..64 — в нашем случае получается 1Gb. Лимит памяти для обработки одного запроса. Эта память индивидуальна для каждой сессии. Теоретически, максимально потребная память равна max_connections * work_mem, на практике такого не встречается потому что большая часть сессий почти всегда висит в ожидании.
bgwrite_delay — 20ms. Время сна между циклами записи на диск фонового процесса записи. Данный процесс ответственен за синхронизацию страниц, расположенных в shared_buffers с диском. Слишком большое значение этого параметра приведет к возрастанию нагрузки на checkpoint процесс и процессы, обслуживающие сессии (backend). Малое значение приведет к полной загрузке одного из ядер.
synchronous_commit — off. ОПАСНО! Выключение синхронизации с диском в момент коммита. Создает риск потери последних нескольких транзакций (в течении 0.5-1 секунды), но гарантирует целостность базы данных, в цепочке коммитов гарантированно отсутствуют пропуски. Но значительно увеличивает производительность.

Это далеко не всё, что удалось узнать из Интернета и статей на https://its.1c.ru . НО! Даже этих настроек хватит, чтобы видимо ускорить работу 1С:Предприятие на PostgreSQL.

В этом конкретном случае после перехода на PostgreSQL пользователи стали жаловаться, что 1С начала тормозить ещё сильнее, чем в файловом варианте. Но после этого тюнинга база «полетела». Теперь все наслаждаются быстрой работой. Однако есть и свои минусы в виде блокировок. Останавливаться на это мы не планируем, будем копать дальше и выкладывать полезные изменения конфигурации PostgreSQL сюда.

1 Ноя 2012 Преимущества использования свободно распространяемого программного обеспечения очевидны. К сожалению, очевидны и недостатки - нет официальной поддержки, зачастую документация противоречива, неполна и разбросана по разным источникам. Эта статья поможет разобраться с процессом установки PosgreSQL для "1С:Предприятие 8", избежав подводные камни, которые не описаны в официальной документации.

Необходимые компоненты для установки

СУБД PostgreSQL распространяется бесплатно и входит в комплект поставки сервера приложений "1С". Сервер приложений "1С:Предприятие 8" поставляется в двух вариантах: 32-разрядный и 64-разрядный. Postgre может работать с обоими.

Итак, имеем на руках дистрибутивы:

Postgre: postgresql-9_1_2-1_1Cx64.zip, любезно предоставленный фирмой "1С".
Дистрибутив сервера приложений "1С:Предприятие" для Windows x64, версии 8.2.16.368.

Казалось бы, чего проще - запусти и установится. Легко! Но установка в стандартном режиме даст одно небольшое ограничение: кластер у нас будут лежать в папке "Program Files". Не всем это понравится. Рассмотрим два варианта установки, простой и расширенный.

Статья разбита на 5 разделов:

1) Установка сервера 1C.

2) Установка PostgreSQL в стандартном виде, достаточном для запуска 1С без дополнительных настроек.

3) Установка PostgreSQL с выбором папки хранения кластера.

4) Создание новой информационной базы 1С.

5) Указание папки хранения файлов базы данных на сервере СУБД.

Перед установкой обязательно прочитайте всю статью целиком!

Установка сервера приложений 1С

Запускаем setup.exe из папки с дистрибутивом сервера 1С.

В том случае, если вы установите сервер приложений не как сервис, нужно будет вручную его запускать каждый раз. Требуется такой вариант редко. Устанавливаем как службу (сервис), и решаем, под каким пользователем он будет запускаться. Из соображений безопасности лучше создать отдельного пользователя USR1CV82, а не разрешать сервису работать под полными правами.

После установки сервера приложений система предложит установить драйвер ключа защиты HASP. Соглашаемся:

Дожидаемся сообщения:

Если сообщение будет другим, в системе, скорее всего, остались "хвосты" от предыдущих установок драйверов HASP. Удаляйте их все, и пробуйте заново.

Готово, сервер приложений "1С:Предприятие 8" мы установили успешно.

Установка PostgreSQL в стандартном виде, достаточном для запуска 1С без дополнительных настроек

Запускаем "postgresql-9.1.2-1.1C(x64).msi"

Опции установки можно не менять, 1С работать будет. Далее.

Postgre, как и сервер 1С, может сам создать пользователя, под которым будете запускаться служба. Обращаю ваше внимание на то, что если указать учетную запись с правами администратора, то служба корректно работать не будет. Обязательно создавайте нового пользователя.

Следующее окно установки.

Инициализируем кластер. Если у нас сервер баз данных и сервер приложений 1С находятся на разных компьютерах, тогда устанавливаем галочку «Поодерживать подсоединения с любых IP», иначе не трогаем. Обязательно указываем кодировку UTF8. Создаем суперпользователя СУБД. Далее…

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

Результат наших усилий - готовый к работе PostgreSQL. Если нас устраивает, что базы будут лежать в Program Files\PostgreSQL\9.1.2-1.1C\data - заканчиваем на этом, раскрываем базы и наслаждаемся процессом. Однако, чаще все-таки базы данных "лежат" на специально предназначенных для этого дисковых массивах, а не на системном диске. Для того, чтобы настроить расположение данных, перед установкой прочитайте следующий раздел.

Установка Postgre с выбором места хранения кластера

Приступаем к установки Postgre и выполняем все шаги до тех пор, пока нам не предложат инициализировать кластер:

Снимаем галочку "Инициализировать кластер базы данных" и нажимаем "Далее".

Да, уверены.

Снимаем галочку "По выходу запустить Stack Builder" и завершаем установку.

1. Необходимо выдать полные права на папку в которую мы установили PostgreSQL, обычно это C:\Program Files\PostgreSQL

2. Из под админских прав запускаем cmd. Если это делаете в win7, то запускаем от Администратора.

3. Создаем папку где будет храниться кластер. Например d:\postgredata.

md d:\postgredata

4. Проводим инициализацию кластера вручную с указанием пути где он будет находиться.

“C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\initdb.exe” -D d:\postgredata --locale=Russian_Russia --encoding=UTF8 -U postgres

5. Удаляем службу PostgreSQL, которая была установлена в ходе установки.

sc delete pgsql-9.1.2-1.1C-x64

Где pgsql-9.1.2-1.1C-x64 - Это название службы. Если не знаете название точно, можно посмотреть свойствах службы “PostgreSQL Database Server…” (Пуск – Панель управления – Администрирование – Службы)

6. Создаем новый сервис с указанием нашего кластера

“C:\Program Files\PostgreSQL\9.1.2-1.1C\bin\pg_ctl” register -N pgsql -U postgresql -P пароль -D d:/postgredata

7. Теперь заходим в службы. Пуск – Панель управления – Администрирование – Службы и стартуем нашу службу.

Создание новой базы данных 1С на сервере с PostgreSQL

Есть несколько вариантов создания базы данных. Можно попробовать создавать базу через pgAdmin3, консоль администрирования серверов 1С. Но тут вы столкнетесь с массой непонятных вопросов и кучей ошибок, ответы на которые будете долго искать. Оставьте это для специалистов. Наша задача получить работоспособную базу с минимальными усилиями. Опишем самый простой путь добиться этого.

Запускаем клиент 1С.

Нажимаем "Добавить...".

Придумываем название базы, указываем "На сервере 1С:Предприятия", далее.

Кластер серверов 1С:Предприятия – localhost, если мы создаем базу на том же компьютере, где установлен сервер 1С, или имя сервера приложений 1С, если на другом.

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

Тип СУБД – Выбираем PostgreSQL.

Сервер баз данных - указываем название сервера PostgreSQL. Если создаем базу на сервере, так же указываем localhost.

Имя базы данных – с таким название будет создана база в PostgreSQL.

Пользователь, пароль – имя пользователя, которого мы указывали как суперпользователя при установке PostgreSQL. Обязательно поднимаем галочку "Создать базу данных в случае ее отсутствия".

Возникает вопрос - а где база будет храниться физически? В папке Base указанного кластера. А если мы не хотим, чтоб она лежала там, где лежат все базы? Тут пока ничего поделать нельзя, просто создаем базу и двигаемся дальше. Далее…

Указание папки хранения базы данных

Итак, мы создали базу. В большинстве случаев на этом установка заканчивается. Однако, если баз много, и есть несколько дисковых массивов для разных групп баз, нужно указать, где физически должны располагаться базы. Чтобы сделать это, запускаем pgAdmin3 из Пуск – Программы – PostgreSQL. Подключаемся к нашему серверу.

При первом подключении Postgre попросит пароль для пользователя postgres (которого мы создавали при установке).

Создаем новый TableSpace, это будет та папка, в которой будут храниться наши базы.

Указали место хранения файлов базы. Ок.

Теперь открываем свойства уже созданной ранее базы данных, размещение которой мы хотим изменить.

Меняем свойство Tablespace. После нажатия "ОК" файлы базы данных будут автоматически перемещены. Готово! Надеемся, что статья была вам полезна. Если это так - оставляйте комментарии, делитесь ссылками на эту страницу. Спасибо!

Поскольку мы ярые пользователи Windows, доступно нам только два варианта СУБД – это MSSql и PostgreSQL. Первый хорош до безумия, но стоимость не порадовала. А ещё больше не порадовала новость о дополнительных лицензиях 1С для работы с MSSQL. Поэтому PostgreSQL.

Подробная инструкция с видео доступна . В этой статье мы пройдёмся по ключевым моментам.

Не забываем про баз данных 1С!

Исходные данные:

ОС Windows Server 2008R2,
Intel Core i7-2600K 3.40GHz,
32Gb RAM,
Intel SSD DC3700 100Gb (только под БД, ОС на отдельном SSD),
от 10 до 20 пользователей в БД ежедневно,
обмен с 5 узлами распределённой БД в фоне.

Зловеще, не правда ли? Приступим.

1. Установка PostgreSQL и pgAdmin.

Инициализируем кластер базы данных (галочка). А вот здесь задаём параметры учётной записи для PostgreSQL! Важно: у Вас должна быть запущена служба «Secondary Logon» (или на локализированных ОС: «Вторичный вход в систему» ). Кодировка UTF8 — это тоже важно!

Создаём SQL БД в этой оснастке, проверяем в pgAdmin — БД там появиться, если всё указано верно.

2. Тюнинг PostgreSQL 9.4.2.

pg_hba.conf
postgresql.conf
pgpass.conf

которые лежат здесь:

C:\Program Files\PostgreSQL\9.4.2-1.1C\data

Для правки конфига есть удобный инструмент, доступный прямо из главного окна pgAdmin. Вот он:

Что мы здесь меняем:

shared_buffers — Количество памяти, выделенной PgSQL для совместного кеша страниц. Эта память разделяется между всеми процессами PgSQL. Делим доступную ОЗУ на 4. В нашем случае это 8Gb.
effective_cache_size — Оценка размера кэша файловой системы. Считается так: ОЗУ — shared_buffers. В нашем случае это 32Gb — 8Gb = 24Gb. Но лично я оставляю этот параметр ещё ниже, где-то 20Gb — всё-таки ОЗУ нужна не только для PostgreSQL.
random_page_cost = 1.5 — 2.0 для RAID, 1.1 — 1.3 для SSD. Стоимость чтения рандомной страницы (по-умолчанию 4). Чем меньше seek time дисковой системы тем меньше (но > 1.0) должен быть этот параметр. Излишне большое значение параметра увеличивает склонность PgSQL к выбору планов с сканированием всей таблицы (PgSQL считает, что дешевле последовательно читать всю таблицу, чем рандомно индекс). И это плохо.
temp_buffers = 256Mb . Максимальное количество страниц для временных таблиц. То есть это верхний лимит размера временных таблиц в каждой сессии.
work_mem — Считается так: ОЗУ / 32..64 — в нашем случае получается 1Gb . Лимит памяти для обработки одного запроса. Эта память индивидуальна для каждой сессии. Теоретически, максимально потребная память равна max_connections * work_mem, на практике такого не встречается потому что большая часть сессий почти всегда висит в ожидании.
bgwrite_delay — 20ms. Время сна между циклами записи на диск фонового процесса записи. Данный процесс ответственен за синхронизацию страниц, расположенных в shared_buffers с диском. Слишком большое значение этого параметра приведет к возрастанию нагрузки на checkpoint процесс и процессы, обслуживающие сессии (backend). Малое значение приведет к полной загрузке одного из ядер.
synchronous_commit — off . ОПАСНО! Выключение синхронизации с диском в момент коммита. Создает риск потери последних нескольких транзакций (в течении 0.5-1 секунды), но гарантирует целостность базы данных, в цепочке коммитов гарантированно отсутствуют пропуски. Но значительно увеличивает производительность.

Если с базой данных возникли какие-то проблемы, возможно, Вам поможет .

Остались вопросы?

Что-то пошло не так? Специалисты нашей компании помогут Вам разобраться с возникшими проблемами! Обращайтесь! →

Инструкция по установке PostgreSQL 9.0.3-3.1C на Windows Server 2008 x64

Для установки используем пакет - PostgreSQL 9.0.3-1C (x 86 или x 64).

Запускаем msi-пакет:

Отмечаем галочкой, если не отмечено «Директория с данными», «psql » и «pgAdmin III ». Далее.

Устанавливаем "как сервис". Для работы этого сервиса потребуется специальный пользователь. Указываем учетную запись, домен (если имеется) и пароль. Далее.

Если такого пользователя в системе нет, тогда мастер сам предложит создать нового. Отвечаем "да" - пользователь создается. Далее.

Теперь инициализируем БД. Указываем порт 5432. Проверяем, что кодировка UTF 8. Задаем логин и пароль пользователя PostgreSQL (система предупреждает, что пароль пользователя системы и пароль пользователя PostgreSQL НЕ ДОЛЖНЫ совпадать – учитываем это). Если кластер серверов 1С и PostgreSQL на разных машинах, то ставим галочку «Поддерживать подсоединения с любых IP , а не только с localhost ». Далее.

Может возникнуть ошибка «Secondary Logon » . Тогда идем в «Администрирование» – «Службы». Стартуем службу «Вторичный вход в систему» или «Secondary Logon »:

Программа устанавливается.

Через меню "Пуск" - "Все программы" запускаем утилиту администрирования «pgAdmin III ».

Подключаемся к серверу. Там вводим пароль для пользователя «postgres ». Если подключиться удалось, попробуем создать новую базу средствами самой 1С.

Запускаем клиентскую часть 1С. Жмем кнопку "Добавить", ставим галочку "Сервер предприятия 1С". Далее заполняем следующее: сервер базы данных (IP или DNS имя того сервера, куда ставили PostgreSQL) - если тот же, что и кластер 1С, то указываем 127.0.0.1. Имя базы данных: [любое_имя]. Пользователь: "postgres" Пароль: [ваш_пароль_postgres]. Далее.

Проверяем, что база 1С создается успешно.

Ниже указанные настройки не панацея, их надо корректировать с учетом реальных доступных мощностей. Реального количества пользователей и интенсивности (записываемой) ввода информации. При настройках системы также важно насколько профессионален тот, кто настраивает ее.

Какую ОС установить:

Процессор

autovacuum_max_workers = NCores/4..2 но не меньше 4

Количество процессов автовакуума. Общее правило — чем больше write-запросов, тем больше процессов. На read-only базе данных достаточно одного процесса.

Ssl = off

Выключение шифрования. Для защищенных ЦОД’ов шифрование бессмысленно, но приводит к увеличению загрузки CPU

Память

shared_buffers = RAM/4

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

Temp_buffers = 256MB

Максимальное количество страниц для временных таблиц. Т.е. это верхний лимит размера временных таблиц в каждой сессии.

Work_mem = RAM/32..64 или 32MB..128MB

Лимит памяти для обработки одного запроса. Эта память индивидуальна для каждой сессии. Теоретически, максимально потребная память равна max_connections * work_mem, на практике такого не встречается потому что большая часть сессий почти всегда висит в ожидании. Это рекомендательное значение используется оптимайзером: он пытается предугадать размер необходимой памяти для запроса, и, если это значение больше work_mem, то указывает экзекьютору сразу создать временную таблицу. work_mem не является в полном смысле лимитом: оптимайзер может и промахнуться, и запрос займёт больше памяти, возможно в разы. Это значение можно уменьшать, следя за количеством создаваемых временных файлов:

Maintenance_work_mem = RAM/16..32 или work_mem * 4 или 256MB..4GB

Лимит памяти для обслуживающих задач, например по сбору статистики (ANALYZE), сборке мусора (VACUUM), создания индексов (CREATE INDEX) и добавления внешних ключей. Размер выделяемой под эти операции памяти должен быть сравним с физическим размером самого большого индекса на диске.

Effective_cache_size = RAM - shared_buffers

Оценка размера кеша файловой системы. Увеличение параметра увеличивает склонность системы выбирать IndexScan планы. И это хорошо.

Диски

effective_io_concurrency = 2 (только для Linux систем, не применять для Windows)

Оценочное значение одновременных запросов к дисковой системе, которые она может обслужить единовременно. Для одиночного диска = 1, для RAID — 2 или больше.

Random_page_cost = 1.5-2.0 для RAID, 1.1-1.3 для SSD, 0.1 для NVMe

Стоимость чтения рандомной страницы (по-умолчанию 4). Чем меньше seek time дисковой системы тем меньше (но > 1.0) должен быть этот параметр. Излишне большое значение параметра увеличивает склонность PgSQL к выбору планов с сканированием всей таблицы (PgSQL считает, что дешевле последовательно читать всю таблицу, чем рандомно индекс). И это плохо.

Seq_page_cost = 0.1 для NVMe дисков autovacuum = on

Включение автовакуума.

Autovacuum_naptime = 20s

Время сна процесса автовакуума. Слишком большая величина будет приводить к тому, что таблицы не будут успевать вакуумиться и, как следствие, вырастет bloat и размер таблиц и индексов. Малая величина приведет к бесполезному нагреванию.

Bgwriter_delay = 20ms

Время сна между циклами записи на диск фонового процесса записи. Данный процесс ответственен за синхронизацию страниц, расположенных в shared_buffers с диском. Слишком большое значение этого параметра приведет к возрастанию нагрузки на checkpoint процесс и процессы, обслуживающие сессии (backend). Малое значение приведет к полной загрузке одного из ядер.

Bgwriter_lru_multiplier = 4.0 bgwriter_lru_maxpages = 400

Параметры, управляющие интенсивностью записи фонового процесса записи. За один цикл bgwriter записывает не больше, чем было записано в прошлый цикл, умноженное на bgwriter_lru_multiplier, но не больше чемbgwriter_lru_maxpages.

Synchronous_commit = off

Выключение синхронизации с диском в момент коммита. Создает риск потери последних нескольких транзакций (в течении 0.5-1 секунды), но гарантирует целостность базы данных, в цепочке коммитов гарантированно отсутствуют пропуски. Но значительно увеличивает производительность.

Checkpoint_segments = 32..256 < 9.5

Максимальное количество сегментов WAL между checkpoint. Слишком частые checkpoint приводят к значительной нагрузке на дисковую подсистему по записи. Каждый сегмент имеет размер 16MB

Checkpoint_completion_target = 0.5..0.9

Степень «размазывания» checkpoint’a. Скорость записи во время checkpoint’а регулируется так, что бы время checkpoint’а было равно времени, прошедшему с прошлого, умноженному на checkpoint_completion_ target.

Min_wal_size = 512MB .. 4G > =9.5 max_wal_size = 2 * min_wal_size > =9.5

Минимальное и максимальный объем WAL файлов. Аналогично checkpoint_segments

Fsync = on

Выключение параметра приводит к росту производительности, но появляется значительный риск потери всех данных при внезапном выключении питания. Внимание: если RAID имеет кеш и находиться в режиме write-back, проверьте наличие и функциональность батарейки кеша RAID контроллера! Иначе данные записанные в кеш RAID могут быть потеряны при выключении питания, и, как следствие, PgSQL не гарантирует целостность данных.

Commit_delay = 1000

паузу (в микросекундах) перед собственно выполнением сохранения WAL

Commit_siblings = 5

Минимальное число одновременно открытых транзакций, при котором будет добавляться задержка commit_delay

Групповой коммит нескольких транзакций. Имеет смысл включать, если темп транзакций превосходит 1000 TPS. Иначе эффекта не имеет.

Temp_tablespaces = "NAME_OF_TABLESPACE"

Дисковое пространство для временных таблиц/индексов. Помещение временных таблиц/индексов на отдельные диски может увеличить производительность. Предварительно надо создать tablespace командой CREATE TABLESPACE. Если характеристики дисков отличаются от основных дисков, то следует в команде указать соответствующий random_page_ cost. См. .

row_security = off >= 9.5

Отключение контроля разрешения уровня записи

Max_files_per_process = 1000 (default)

Максимальное количество открытых файлов на один процесс PostreSQL. Один файл это как минимум либо индекс либо таблица, но таблица/может состоять из нескольких файлов. Если PostgreSQL упирается в этот лимит, он начинает открывать/закрывать файлы, что может сказываться на производительности. Диагностировать проблему под Linux можно с помощью команды lsof.

Сеть

max_connections = 500..1000

Количество одновременных коннектов/сессий
Если у Вас больше 100 пользователей, то лучше указать вручную значение для этого параметра по количеству пользователей

Типовая проблема в Windows

Ошибка СУБД: could not send data to server: No buffer space available (0x00002747/10055)

При использовании операционной системы Windows, максимальное стандартное число временных TCP-портов равно 5000. При попытке установить TCP-соединение через порты, номера которых превышают 5000, выдается сообщение об ошибке. Другими словами, надо увеличить количество доступных портов в реестре, где выберите Parameters (HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ Tcpip\Parameters) и добавьте следующий параметр реестра MaxUserPort с типом: DWORD и значением: 65534 (Допустимые значения: 5000-65534)

Блокировки

max_locks_per_transaction = 256

Максимальное число блокировок индексов/таблиц в одной транзакции

Настройки под платформу 1С

standard_conforming_strings = off

Разрешить использовать символ \ для экранирования

Escape_string_warning = off

Не выдавать предупреждение о использовании символа \ для экранирования

Shared_preload_libraries = "online_analyze, plantuner"

несколько разделяемых библиотек, которые будут загружаться при запуске сервера
если указанная в нём библиотека не будет найдена, сервер не запустится
настройка параметра имеет больше значения для linux, хотя и windows её делать тоже стоит

Модуль online_analyze предоставляет набор функций, которые немедленно обновляют статистику после операций INSERT, UPDATE, DELETE или SELECT INTO в целевых таблицах.
Модуль plantuner добавляет поддержку указаний для планировщика, позволяющих отключать или подключать определённые индексы при выполнении запроса.

Online_analyze.enable = on

Включает анализ статистики временных таблиц, часто используемых в 1С

Оптимизатор

default_statistics_target = 1000 -10000

(Улучшение статистики оптимизатора)

Enable_nestloop=off, enable_mergejoin=off

(Изменение параметров оптимизатора)
● Включает или отключает использование планировщиком планов соединения с вложенными циклами
● Включает или отключает использование планов соединения слиянием.
Например ошибки типа out of memory

Join_collapse_limit=1

(отключение при понимании порядка соединений таблиц!)
● При значении, равном 1, предложения JOIN переставляться не будут, так что явно заданный в запросе порядок
соединений определит фактический порядок, в котором будут соединяться отношения.
Прочие настройки влияющие на оптимизатор

From_collapse_limit = 20

● Задаёт максимальное количество элементов в списке FROM, до достижения которого планировщик будет сносить в него явные конструкции JOIN (за исключением FULL JOIN). При меньших значениях сокращается время планирования, но план запроса может стать менее эффективным.
● seq_page_cost = 0.1 random_page_cost = 0.4 cpu_operator_cost = 0.00025

Online_analyze.table_type = "all"

(больше нагрузка)
Типы таблиц, для которых выполняется немедленный анализ: all (все), persistent (постоянные), temporary (временные), none (никакие).

Online_analyze.threshold = 50

● Минимальное число изменений строк, после которого может начаться немедленный анализ (этот параметр подобен autovacuum_analyze_threshold).

Online_analyze.scale_factor = 0.1

Процент от размера таблицы, при котором начинается немедленный анализ (этот параметр подобен autovacuum_analyze_scale_factor).

Online_analyze.min_interval = 10000

● Минимальный интервал времени между вызовами ANALYZE для отдельной таблицы (в миллисекундах).

Online_analyze.local_tracking = off

● Включает в online_analyze отслеживание временных таблиц в рамках обслуживающего процесса. Когда эта переменная отключена (off), online_analyze использует для временных таблиц системную статистику по умолчанию.

Online_analyze.verbose = "off"

● Отключает подробные сообщения расширения online_analyze

Plantuner.fix_empty_table = "on"

● plantuner будет обнулять число страниц/кортежей в таблице, которая не содержит никаких блоков в файле