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

Процессор

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

Ssl = off

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

Память

Количество памяти, выделенной 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 планы. И это хорошо.

Диски

Оценочное значение одновременных запросов к дисковой системе, которые она может обслужить единовременно. Для одиночного диска = 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.

Сеть

Количество одновременных коннектов/сессий
Если у Вас больше 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)

Блокировки

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

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

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

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С

Оптимизатор

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

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 будет обнулять число страниц/кортежей в таблице, которая не содержит никаких блоков в файле

Инструкция по установке 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С создается успешно.

Beta Меню

Настройка Сервера 1С:Предприятие 8.3 и PostgreSQL 9.4.2-1.1C. Полная инструкция

В этой инструкции мы расскажем (и покажем) как настроить связку 1С:Предприятие 8.3 и PostgreSQL 9.4.2 с момента установки обоих сервисов, вплоть до создания информационной базы. Про тюнинг данной связки можно прочитать в .

Этапы, которые нам предстоит пройти:

1. Установка Сервера 1С:Предприятие (64-bit) для Windows
2. Установка PostgreSQL 9.4.2-1.1С
3. Создание Информационной базы данных.

Подробнее под катом!

Этап 0. Вводные данные.

Имя сервера — 1CServer
Имя учётной записи сервера — Администратор
Пароль учётной записи — 123456Ab

Имя учётной записи 1С на сервере — USR1CV8
Пароль учётной записи 1С на сервере — 123456Cd

Имя учётной записи PostgreSQL на сервере — postgres
Пароль учётной записи PostgreSQL на сервере — 123456Ef

Имя суперюзера PostgreSQL — postgres
Пароль суперюзера PostgreSQL — 1234

Имя тестовой базы данных — testdb

Этап 1. Установка Сервера 1С:Предприятие (64-bit) для Windows

Этап 2. Установка PostgreSQL и pgAdmin.

Этап 3. Создание информационной базы 1С.

1. Перед выполнением следующих операций, отключите IPv6 на Вашем сетевом интерфейсе: Центр управления сетями и общим доступом > Подключение по локальной сети > Свойства > Снимите галочку с Протокол Интернета версии 6 (TCP/IPv6) .
2. Запускаем клиентское 1С:Предприятие и добавляем новую базу данных.
3. Создание новой информационной базы > Создание информационной базы без конфигурации (для примера, у Вас может быть любая конфигурация) > На сервере 1С:Предприятие >
4. Заполняем все поля в соответствии с нашим примером (Этап 0):
   Кластер серверов 1С:Предприятие: 1CServer
   Имя информационной базы в кластере: testbd
   Защищённое соединение: Выключено
   Тип СУБД: PostgreSQL
   Сервер баз данных: 1CServer
   Имя базы данных: testbd
   Пользователь базы данных: postgres
   Пароль пользователя: 1234
5. Далее, далее. Запускаем созданную базу в режиме предприятия — всё работает!

Ещё раз напоминаем, что PostgreSQL можно неплохо разогнать. Подробности в .
И не забудьте про 1С!
Если с базой данных возникли какие-то проблемы, возможно, Вам поможет .
Базы данных 1С можно !

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

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

Также Ваши вопросы Вы можете задать в нашей группе ВК или на нашем YouTube канале!

Эти статьи будут Вам интересны

До недавних пор все материнские платы для настольных ПК в настройках контроллера HDD имели два режима работы HDD: IDE и AHCI. Чаще всего, особенно раньше, по-умолчанию был выбран режим IDE, хотя он и устаревший. ОС устанавливалась, зная о том, что для HDD выбран режим IDE, и прописывала этот режим работы в реестр. Если по каким-то причинам (обновление BIOS, смена настроек BIOS, сброс BIOS в режим по-умолчанию или Вы решили использовать RAID) происходило переключение режима с IDE на AHCI, Windows переставала загружаться, выдавая синий экран смерти с кодом 0x0000007B. Форумы пестрят сообщениями о том, что "нужно переустановить ОС". Конечно же, это поможет. Но есть и более простой способ!

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

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

Вступление

Я много работал с PostgreSQL и считаю его прекрасной СУБД. У меня многогигабайтная рабочая база (не 1С) обрабатывает моментально огромные массивы данных. PostgreSQL прекрасно использует индексы, хорошо справляется с параллельной нагрузкой, функционал хранимых процедур на высоте, есть хорошие средства администрирования и повышения производительности "из коробки", а сообщество создало полезные утилиты. Но я с удивлением узнал что у многих администраторов 1С мнение о PostgreSQL не на высоте, что он тормоз и едва обгоняет файловый вариант базы, и только MSSQL может спасти положение.

Поизучав вопрос, я нашел множество статей по установке PostgreSQL по шагам для чайников, как по Linux, так и под Windows. Но подавляющее большинство статей описывают установку до "установилось - создадим базу", и совершенно не затрагивают вопрос конфигурирования. В оставшихся конфигурирование упоминается лишь на уровне "прописать такие значения", практически не объясняя зачем.

И если подход "установка в одну кнопку" применим к MSSQL и вообще многим продуктам под Windows, то к PostgreSQL он, к сожалению, не относится. Настройки по умолчанию очень сильно ограничивают его в использовании памяти, чтобы можно было его установить хоть на калькулятор и он там не мешал работе остального ПО. PostgreSQL обязательно нужно конфигурировать под конкретную систему, и только тогда он сможет показать себя на высоте. В особо тяжелых случаях можно тюнинговать настройки PostgreSQL, базы и файловой системы друг под друга, но это касается в большей степени Linux-систем, где больше возможностей по настройке всего и вся.

Следует напомнить, что для 1С не подойдет сборка PostgreSQL от разработчиков СУБД, только собранная из пропатченных 1С исходных текстов. Готовые совместимые сборки предлагает 1С (через диски ИТС и кабинет для имеющих подписку на поддержку) и EterSoft

Тестирование проводилось в среде Windows, но все рекомендации по настройке не являются специфичными для платформы и применимы к любой ОС.

Тестирование и сравнение

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

Для тестирования я использовал следующую конфигурацию:
Host-машина: Win7, Core i5-760 2.8MHz, 4 ядра, 12Гб ОЗУ, VMWare 10
Виртуальная: Win7 x64, 2 ядра, 4Гб ОЗУ, отдельный физический жесткий диск для размещения БД (не SSD)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
1C 8.3.5 1383

Использовалась БД, dt-выгрузка 780Мб.
После восстановления базы:
размер файла 1CD в файловом варианте - 10Гб,
размер базы PostgreSQL - 8Гб,
размер базы MSSQL - 6.7Гб.

Для теста использовал запрос на выборку договоров контрагентов (21к) с выборкой дополнительных реквизитов из различных регистров, для каждого договора фактически делалась отдельная выборка из регистров. Конфигурацию взял что была под рукой - сильно доработанная на базе Бухгалтерии 3.0.

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

Тестирование одним клиентом:

Выборка на хосте из файлового варианта с размещением базы на SSD - 31с
Выборка из файлового варианта в виртуальной машине (с жесткого диска) - 46с
Выборка из MSSQL-базы - первый проход - 25с или 9с (видимо в зависимости от актуальности кэша СУБД) (потребление памяти процессом СУБД составило примерно 1.3Гб)
Выборка из PostgreSQL с настройками по умолчанию - 43с (потребление памяти не превышало 80Мб на подключение)
Выборка из оптимизированного PostgreSQL - 21с (потребление памяти составило 120Мб на подключение)

Тестирование двумя клиентами:

Выборка на хосте из файлового варианта с размещением базы на SSD - по 34с
Выборка из файлового варианта в виртуальной машине (с жесткого диска) - по 56с
Выборка из MSSQL-базы - по 50с или 20с (видимо в зависимости от актуальности кэша СУБД)
Выборка из PostgreSQL с настройками по умолчанию - по 60с
Выборка из оптимизированного PostgreSQL - по 40с

Замечания к тестированию:

1. После добавления третьего ядра PostgreSQL и MSSQL-варианты стали работать в тесте "два клиента" практически с производительностью теста "один клиент", т.е. удачно распараллелились. Что мешало им параллелить работу на двух ядрах для меня осталось загадкой.
2. MSSQL памяти захватил сразу много, PostgreSQL требовал во всех режимах существенно меньше, и сразу после завершения выполнения запроса почти всю высвобождал.
3. MSSQL работает единым процессом. PostgreSQL запускает по отдельному процессу на подключение+служебные процессы. Это позволяет даже 32-разрядному варианту эффективно использовать память при обработке запросов от нескольких клиентов.
4. Увеличение памяти для PostgreSQL в настройках свыше указанных ниже значений не привело к заметному росту производительности.
5. Первые тесты во всех случаях проходили дольше чем в последующих замерах, специально замеры не производил, но MSSQL субъективно стартовал быстрее.

Конфигурирование PostgreSQL

Есть прекрасная книга на русском языке о конфигурировании и оптимизировании PostgreSQL: Каждому слоноводу имеет смысл поставить себе в закладки эту ссылку. В книге описывается множество техниг оптимизации СУБД, создание отказоустойчивых и распределенных систем. Но сейчас мы рассмотрим то что пригодится всем - конфигурирование использования памяти. PostgreSQL не будет использовать памяти больше чем разрешено настройками, а с настройками по умолчанию PostgreSQL использует минимум памяти. При этом не стоит указывать памяти больше чем доступно к использованию - система начнет использовать файл подкачки со всеми вытекающими печальными последствиями для производительности сервера. Ряд советов по настройке PostgreSQL приведены на диске ИТС.

В Windows конфигурационные файлы PostgreSQL находятся в каталоге установки в каталоге Data:

• postgresql.conf - основной файл с настройками СУБД
• pg_hba.conf - файл с настройками доступа для клиентов. В частности, тут можно указать каким пользователям с каких IP-адресов можно подключаться к определенным БД, и требуется ли проверять пароль пользователя, и если требуется - каким методом.
• pg_ident.conf - файл с преобразованием имен пользователей из системных во внутренние (вряд ли он потребуется большинству пользователей)

Файлы текстовые, можно править блокнотом. Строки, начинающиеся с # считаются комментариями и игнорируются.

Параметры, относящиеся к объму памяти могут дополняться суффиксами kB, MB, GB - килобайты, мегабайты, гигабайты, например, 128MB. Параметры, описывающие интервалы времени, могут дополняться суффиксами ms,s,min,h,d - миллисекунды, секунды, минуты, часы, дни, например, 5min

Если вы забыли пароль к постгрессу - не беда, можно прописать в pg_hba.conf строку:

Host all all 127.0.0.1/32 trust

И подключаться любым пользователем (например, postgres ) к СУБД на локальной машине по адресу 127.0.0.1 без проверки пароля.

Оптимизация использования памяти

Настройки использования памяти располагаются в postgresql.conf

Оптимальные значения параметров зависят от объема свободной оперативной памяти, размера базы и отдельных элементов базы (таблицы и индексы), сложности запросов (в принципе, стоит полагаться что запросы будут достаточно сложными - множественные соединения в запросах это типовой сценарий) и количества одновременных активных клиентов. Кстати, PostgreSQL хранит таблицы и индексы БД в отдельных файлах (<каталог установки PG>\data\base\<идентификатор БД>\), и размеры объектов можно оценить. Так же можно используя входящую в поставку утилиту pgAdmin подключиться к базе, раскрыть "Схемы"-"public", и сформировать отчет по статистике для элемента "Таблицы".

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

При настройке сервера для тестирования я полагался на следующие расчеты:
Всего 4Гб ОЗУ. Потребители - ОС Windows, сервер 1С, PostgreSQL и дисковый кэш системы. Я исходил из того что для СУБД можно выделить до 2.5Гб ОЗУ

Значения могут указываться с суффиксами kB, MB, GB (значения в килобайта, мегабайтах или гигабайтах). После изменения значений требуется перезапустить службу PostgreSQL.

shared_buffers - Общий буфер сервера

Размер кэша чтения и записи PostgreSQL, общего для всех подключений. Если данные отсутствуют в кэше, производится чтение с диска (возможно, будут кэшированы ОС)

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

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

В тесте использовалось

shared_buffers = 512MB

work_mem - память для сортировки, агрегации данных и т.д.

Выделяется на каждый запрос, возможно по нескольку раз для сложных запросов. Если памяти недостаточно - PostgreSQL будет использовать временные файлы. Если значение слишком большое - может возникнуть перерасход оперативной памяти и ОС начнет использовать файл подкачки с соответствующим падением быстродействия.

Есть рекомендация при расчетах взять объем доступной памяти за вычетом shared_buffers , и поделить на количество одновременно исполняемых запросов. В случае сложных запросов делитель стоит увеличить, т.е. уменьшить результат. Для рассматриваемого случая из расчета 5 активных пользователей (2.5Гб-0.5Гб (shared_buffers))/5=400Мб. В случае если СУБД сочтет запросы достаточно сложными, или появятся дополнительные пользователи, потребуется значение уменьшить.

Для простых запросов достаточно небольших значений - до пары мегабайт, но для сложных запросов (а это типовой сценарий для 1С) потребуется больше. Рекомендация - для памяти 1-4Гб можно использовать значения 32-128Мб. В тесте использовал

work_mem = 128MB

maintenance_work_mem - память для команд сбора мусора, статистики, создания индексов.

Рекомендуется устанавливать значение 50-75% от размера самой большой таблицы или индекса, но чтобы памяти хватило для работы системы и приложений. Рекомендуется устанавливать значения больше чем work_mem. В тесте использовал
maintenance_work_mem = 192MB

temp_buffers - буфер под временные объекты, в основном для временных таблиц.

Можно установить порядка 16 МБ. В тесте использовал
temp_buffers = 32MB

effective_cache_size - примерный объем дискового кэша файловой системы.

Оптимизатор использует это значение при построении плана запроса, для оценки вероятности нахождения данных в кэше (с быстрым случайным доступом) или на медленном диске. В Windows текущий объем памяти, выделенной под кэш, можно посмотреть в диспетчере задач.

Autovacuum - "сборка мусора"

PostgreSQL как типичный представитель "версионных" СУБД (в противоположность блокирующим) самостоятельно не блокирует при изменении данных таблицы и записи от читающих транзакций (в случае 1С этим занимается сам сервер 1С). Вместо этого создаётся копия изменяемой записи, которая становится видна последующим транзакциям, действующие же продолжают видеть данные, актуальные на начало своей транзакции. Как следствие, в таблицах накапливаются устаревшие данные - предыдущие версии измененных записей. Для того чтобы СУБД могла высвободившееся место использовать, необходимо произвести "сборку мусора" - определить какие из записей больше не используются. Это можно сделать явно SQL-командой VACUUM , либо дождаться когда таблицу обработает автоматический сборщик мусора - AUTOVACUUM . Так же до определенной версии сборка мусора была связана со сбором статистики (планировщик использует данные о количестве записей в таблицах и распределении значений индексированных полей для построения оптимального плана запроса). С одной стороны, сбор мусора делать необходимо, чтобы таблицы не разрастались и эффективно использовали дисковое пространство. С другой внезапно начавшаяся уборка мусора дает дополнительную нагрузку на диск и таблицы, что приводит к увеличению времени выполнения запросов. Аналогичный эффект создает автоматический сбор статистики (явно его можно запустить командой ANALYZE или совместно со сборкой мусора VACUUM ANALYZE ). И хотя от версии к версии PostgreSQL совершенствует эти механизмы, чтобы минимизировать негативное влияние на производительность (например, в ранних версиях сборка мусора полностью блокировала доступ к таблице, с версии 9.0 работа VACUUM ускорена), тут есть что настроить.

Полностью отключить autovacuum можно параметром:

autovacuum = off

Так же для работы Autovacuum требуется параметр track_counts = on, в противном случае он работать не будет.

По умолчанию оба параметра включены. На самом деле autovacuum полностью отключить нельзя - даже при autovacuum = off иногда (после большого количества транзакций) autovacuum будет запускаться.

Замечание: VACUUM обычно не уменьшает размер файла таблицы, только помечает свободные, доступные для повторного использования области. Если же требуется физически высвободить лишнее место и максимально уменьшить занимаемое пространство на диске, потребуется команда VACUUM FULL . Этот вариант блокирует доступ к таблице на время работы, и обычно не требуется его использовать. Подробнее об использовании команды VACUUM можно прочитать в документации (на английском).

Если Autovacuum полностью не отключать, настроить его влияние на выполнение запросов можно следующими параметрами:

autovacuum_max_workers - максимальное количество параллельно запущенных процессов уборки.

autovacuum_naptime - минимальный интервал, реже которого autovacuum не будет запускаться. По умолчанию 1 минута. Можно увеличить, тогда при частых изменениях данных анализ будет выполняться реже.

autovacuum_vacuum_threshold, - количество измененных или удаленных записей в таблице, необходимых для запуска процесса сборки мусора VACUUM или сбора статистики ANALYZE . По умолчанию по 50.

autovacuum_vacuum_scale_factor , autovacuum_analyze_scale_factor - коэфициент от размера таблицы в записях, добавляемый к autovacuum_vacuum_threshold и autovacuum_analyze_threshold соответственно. Значения по умолчанию 0.2 (т.е. 20% от количества записей) и 0.1 (10%) соответственно.

Рассмотрим пример с таблицей на 10000 записей. Тогда при настройках по умолчанию после 50+10000*0.1=1050 измененных или удаленных записей будет запущен сбор статистики ANALYZE , а после 2050 изменений - сборка мусора VACUUM .

Если увеличить threshold и scale_factor, обслуживающие процессы будут выполняться реже, но небольшие таблицы могут существенно разрастаться. Если БД состоит преимущественно из небольших таблиц, общее увеличение занимаемого дискового пространства может быть существенным, таким образом увеличивать эти значения можно, но с умом.

Таким образом может иметь смысл увеличить интервал autovacuum_naptime, и несколько увеличить threshold и scale_factor. В нагруженных базах может быть альтернативой существенно поднять scale_factor (значение 1 позволит "разбухать" таблицам вдвое) и поставить в планировщик ежесуточное выполнение VACUUM ANALYZE в период минимальной загруженности БД.

default_statistics_target - назначает объем статистики, собираемый командой ANALYZE . Значение по умолчанию 100. Большие значения увеличивают время выполнения команды ANALYZE, но позволяют планировщику строить более эффективные планы выполнения запросов. Встречаются рекомендации по увеличению до 300.

Можно управлять производительностью AUTOVACUUM , делая его более длительным но менее нагружающим систему.

vacuum_cost_page_hit - размер "штрафа" за обработку блока, находящегося в shared_buffers. Связан с необходимостью блокировать доступ к буферу. Значение по умолчанию 1

vacuum_cost_page_miss - размер "штрафа" за обработку блока на диске. Связан с блокировкой буфера, поиском данных в буфере, чтении данных с диска. Значение по умолчанию 10

vacuum_cost_page_dirty - размер "штрафа" за модификацию блока. Связан с необходимостью сбросить модифицированные данные на диск. Значение по умолчанию 20

vacuum_cost_limit - максимальный размер "штрафов", после которых процесс сборки может быть "заморожен" на время vacuum_cost_delay. По умолчанию 200

vacuum_cost_delay - время "заморозки" процесса сборки мусора по достижению vacuum_cost_limit. Значение по умолчанию 0ms

autovacuum_vacuum_cost_delay - время "заморозки" процесса сборки мусора для autovacuum. По умолчанию 20ms. Если установить -1, будет использоваться значение vacuum_cost_delay

autovacuum_vacuum_cost_limit - максимальный размер "штрафа" для autovacuum. Значение по умолчанию -1 - используется значение vacuum_cost_limit

По сообщениям использование vacuum_cost_page_hit = 6 , vacuum_cost_limit = 100 , autovacuum_vacuum_cost_delay = 200ms уменьшает влияние AUTOVACUUM до 80%, но увеличивает время его выполнения втрое.

Настройка записи на диск

При завершении транзакции PostgreSQL начала пишет данные в специальный журнал транзакций WAL (Write-ahead log), а затем уже в базу после того, как данные журнала гарантированно записаны на диск. По умолчанию используется механизм fsync , когда PostgreSQL принудительно сбрасывает данные (журнала) из дискового кэша ОС на диск, и только после успешной записи (журнала) клиенту сообщается об успешном завершении транзакции. Использование журнала транзакций позволяет завершить транзакцию или восстановить базу если во время записи данных произойдет сбой.

В нагруженных системах с большими объемами записи может иметь смысл вынести журнал транзакций на отдельный физический диск (но не на другой раздел этого же диска!). Для этого нужно остановить СУБД, перенести каталог pg_xlog в другое место, а на старом месте создать символическую ссылку, например, утилитой junction. Так же ссылки умеет создавать Far Manager (Alt-F6). При этом надо убедиться что новое место имеет права доступа для пользователя, от которого запускается PostgreSQL (обычно postgres).

При большом количестве операций изменения данных может потребоваться увеличить значение checkpoint_segments, регулирующее объем данных, который может ожидать переноса из журнала в саму базу. По умолчанию используется значение 3. При этом следует учитывать что под журнал выделяется место, расчитываемое по формуле (checkpoint_segments * 2 + 1) * 16 МБ, что при значении 32 уже потребует более 1Гб места на диске.

PostgreSQL после каждого завершения пишущей транзакции сбрасывает данные из файлового кэша ОС на диск. С одной стороны, это гарантирует что данные на диске всегда в актуальном состоянии, с другой при большом количестве транзакций падает производительность. Полностью отключить fsync можно, указав

fsync = off
full_page_writes = off

Делать это можно только в случае если вы на 100% доверяете оборудованию и ИБП (источнику бесперебойного питания). Иначе в случае аварийного завершения системы есть риск получить разрушенную БД. И в любом варианте не помешает так же RAID-контроллер с батарейкой для питания памяти недозаписанных данных.

Определенной альтернативой может быть использование параметра

synchronous_commit = off

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

Если не отключать fsync совсем, можно указать метод синхронизации в параметре. Статья с диска ИТС ссылается на утилиту pg_test_fsync, но в моей сборке PostgreSQL её не оказалось. По утверждению 1С, в их случае в Windows оптимально себя показал метод open_datasync (судя по всему, именно этот метод и используется по умолчанию).

В случае если используется множество мелких пишущих транзакций (в случае 1С этом может быть массовое обновление справочника вне транзакции), может помочь сочетание параметров commit_delay (время задержки завершения транзакции в микросекундах, по умолчанию 0) и commit_siblings (по умолчанию 5). При включении опций завершение транзакции может быть отложено на время commit_delay, если в данный момент исполняется не менее commit_siblings транзакций. В этом случае результат всех завершившихся транзакций будет записан совместно для оптимизации записи на диск.

Прочие параметры, влияющие на производительность

wal_buffers - объем памяти в shared_buffers для ведения транзакционных логов. Рекомендация - при 1-4Гб доступной памяти использовать значения 256КБ-1МБ. Документация утверждает что использование значения "-1" автоматически подбирает значение в зависимости от значения shared_buffers.

random_page_cost - "стоимость" случайного чтения, используется при поиске данных по индексам. По умолчанию 4.0. За единицу берется время последовательного доступа к данным. Для быстрых дисковых массивов, особенно SSD, имеет смысл понижать значение, в этом случае PostgreSQL будет более активно использовать индексы.

В книге по ссылке есть некоторые другие параметры, которые можно настраивать. Так же настоятельно рекомендуется ознакомиться с документацией на PostgreSQL по назначению конкретных параметров.

Параметры из раздела QUERY TUNING, особенно касающиеся запрета планировщику использовать конкретные методы поиска, рекомендуется изменять только в том случае если есть полное понимание что делаете. Очень легко оптимизировать один вид запросов и обрушить производительность всех остальных. Эффективность изменения большинства параметров в этом разделе зависит от данных в БД, запросов к этим данным (т.е. от используемой версии 1С в т.ч.) и версии СУБД.

Заключение

PostgreSQL - мощная СУБД в умелых руках, но требующая тщательной настройки. Его вполне можно использовать совместно с 1С и получить приличное быстродействие, а бесплатность его будет очень приятным бонусом.

Критика и дополнения к этой статье приветствуются.

Полезные ссылки

http://postgresql.leopard.in.ua/ - сайт книги "Работа с PostgreSQL настройка и масштабирование ", наиболее полное и понятное руководство на мой взгляд по конфигурированию и администрированию PostgreSQL

http://etersoft.ru/products/postgre - здесь можно скачать 1С-совместимую сборку PostgreSQL под Windows и различные дистрибутивы и версии Linux. Для тех у кого нет подписки на ИТС или требуется версия под версию Linux, которая не представлена на v8.1c.ru.

http://www.postgresql.org/docs/9.2/static/ - официальная документация на PostgreSQL (на английском)

Статьи с диска ИТС по настройке PostgreSQL

История правок статьи

• 29.01.2015 - опубликована первоначальная версия
• 31.01.2015 - статья дополнена разделом по AUTOVACUUM, добавлена ссылка на оригинальную документацию.

В дальнейшем я намерен провести тестирование работы СУБД в режиме добавления и изменения данные.