Установка PostgreSQL - Windows, Mac OS X, Linux. PostgreSQL: установка, настройка, обслуживание

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

Установка

Сама установка особых затруднений не вызывает, обратить внимание нужно на правильную инициализацию базы данных, а именно настройку локали, изменить потом это можно только повторной начальной инициализацией. Например, база 1С с украинскими региональными установками в СУБД с установленной русской локалью не загрузится. Да и проблемы с сортировкой потом не нужны. Поэтому делаем init в соответствии с нужным языком.

Для русского языка

initdb --locale=ru_RU.UTF-8 --lc-collate=ru_RU.UTF-8 --lc-ctype=ru_RU.UTF-8 --encoding=UTF8 -D /db/postgresql

Для украинского языка

initdb --locale=uk_UA.UTF-8 --lc-collate=uk_UA.UTF-8 --lc-ctype=uk_UA.UTF-8 --encoding=UTF8 -D /db/postgresql

где /db/postgresql ваш каталог данных PostgreSQL. Кодировка, конечно же, UTF-8.

Подробный вариант пересоздания кластера

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

Ошибка СУБД: ERROR: new encoding (UTF8) is incompatible with the encoding of the template database (WIN1251).

HINT: Use the same encoding as in the template database, or use template0 as template.

Вы выбрали неправильную локаль при установке СУБД (WIN1251) для сервера и клиента, нужно изменить на UTF-8 в конфигурации или переустановить СУБД со следующими параметрами:

Внимание при установке НЕ выбирайте локаль Настройки ОС, выбирайте из списка Russian, Russia

Настройка PostgreSQL

Следует помнить о рекомендации 1С не использовать в запросах конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ и заменять его, используя, например, комбинацию из нескольких левых соединений. Известна также проблема с потерей производительности в запросах, где применяется соединение с виртуальной таблицей СрезПоследних, к ней рекомендуется делать отдельные запросы и сохранять результаты во временных таблицах.

Настройка конфигурации производится редактированем файла postgresql.conf.

Наиболее важные параметры

effective_cache_size = 0,5 от ёмкости RAM

fsync = off отключаем сброс на диск после каждой транзации (Внимание! Применять только при использовании надежного UPS, есть опасность потери данных при неожиданном отключении)

synchronous_commit = off отключаем синхронную запись в лог (риски теже, что и у fsync)

wal_buffers = 0,25 от ёмкости RAM

После настройки не забываем выполнить перезапуск службы:

service postgresql restart

Настройка сети

Для подключения клиентов 1С к серверу извне и работы сервера баз данных, на файрволе, должны быть открыты следующие порты:

Агент сервера (ragent) & tcp:1540 Главный менеджер кластера (rmngr) & tcp:1541 Диапазон сетевых портов, для динамического распределения рабочих процессов & tcp:1560&1591, tcp:5432 & Postgresql. Создадим правило через стандартный интерфейс, либо с помощью команды:

netsh advfirewall firewall add rule name="1Cv8-Server" dir=in action=allow protocol=TCP localport=1540,1541,5432,1560-1590 enable=yes profile=ANY remoteip=ANY interfacetype=LAN

Теперь с другого компьютера мы спокойно запускаем клиент 1С:Предприятия, добавляем существующую информационную базу newdb. Не забываем про лицензии, программной / аппаратной защиты.

Резервное копирование

Создание дампа базы данных делаем командой

su postgres -c "pg_dump -U postgres -Fc -Z9 -f baza1.sql baza1"

Восстановление из дампа

su postgres -c "pg_restore -U postgres -c -d baza1 -v baza1.sql"

Периодическое обслуживание

su postgres -c "/usr/bin/vacuumdb --dbname=$i --analyze --full --quiet"

Просмотр активности PostgreSQL

Иногда полезно видеть чем сейчас занимается сервер. Поможет такая конструкция:

watch -n 1 "ps auxww | grep ^postgres"

PostgreSQL - это объектно-реляционная система баз данных, которая обладает признаками традиционной коммерческой базы данных, с расширениями, которые будут доступны следующему поколению СУБД (систем управления базами данных).

Установка

Для установки PostgreSQL выполните следующую команду в терминале:

Sudo apt-get install postgresql

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

Настройка

По умолчанию соединения через TCP/IP заблокированы. PostgreSQL поддерживает множество методов аутентификации. Метод аутентификации IDENT используется для postgres и локальных пользователей пока не настроено что-то еще. Обратитесь к, если вы собираетесь использовать какую-либо альтернативу типа Kerberos.

Дальнейшее обсуждение предполагает, что вы собираетесь разрешить соединения по TCP/IP и используете аутентификацию клиентов на основе метода MD5. Файлы настроек PostgreSQL хранятся в каталоге /etc/postgresql/ /main . Например, если вы установили PostgreSQL 8.4, файлы настроек сохранятся в каталоге /etc/postgresql/8.4/main.

Для настройки аутентификации ident добавьте записи в файл /etc/postgresql/8.4/main/pg_ident.conf. В файле содержатся подробные комментарии чтобы направлять вас.

Чтобы разрешить соединения по TCP/IP, отредактируйте файл /etc/postgresql/8.4/main/postgresql.conf. Найдите строку

#listen_addresses = "localhost"

и замените ее на:

Listen_addresses = "localhost"

Чтобы разрешить другим компьютерам соединяться с вашим PostgreSQL сервером, замените "localhost" на IP адрес вашего сервера или в качестве альтернативы на 0.0.0.0, чтобы подключить все интерфейсы.

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

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

Sudo -u postgres psql template1

Эта команда подключится к PostgreSQL базе данных template1 как пользователь postgres. После подключения к серверу PostgreSQL вы окажетесь в SQL консоли. Вы можете выполнить следующую SQL команду в консоли psql для настройки пароля пользователя postgres:

ALTER USER postgres with encrypted password "your_password";

После настройки пароля, измените файл /etc/postgresql/8.4/main/pg_hba.conf на использование MD5 аутентификации для пользователя postgres:

Local all postgres md5

Под конец вам потребуется перезапустить сервис PostgreSQL для применения новых настроек. Из терминала выполните следующее для перезапуска PostgreSQL:

Sudo /etc/init.d/postgresql-8.4 restart

Настройка выше в любом случае неполная. Пожалуйста обратитесь к руководству PostgreSQL Administrator"s Guide для настройки других параметров.

Немного о конфигурировании PostgreSQL

*Есть ли альтернатива MSSQL?
*PostgreSQL - тормоз или отличная СУБД?
*Как заставить работать PostgreSQL на полной скорости?

Данная статья не претендует на полноту изложения всех возможностей конфигурирования 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с

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

После добавления третьего ядра PostgreSQL и MSSQL-варианты стали работать в тесте "два клиента" практически с производительностью теста "один клиент", т.е. удачно распараллелились. Что мешало им параллелить работу на двух ядрах для меня осталось загадкой.
MSSQL памяти захватил сразу много, PostgreSQL требовал во всех режимах существенно меньше, и сразу после завершения выполнения запроса почти всю высвобождал.
MSSQL работает единым процессом. PostgreSQL запускает по отдельному процессу на подключение+служебные процессы. Это позволяет даже 32-разрядному варианту эффективно использовать память при обработке запросов от нескольких клиентов.
Увеличение памяти для PostgreSQL в настройках свыше указанных ниже значений не привело к заметному росту производительности.
Первые тесты во всех случаях проходили дольше чем в последующих замерах, специально замеры не производил, но 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 хранит таблицы и индексы БД в отдельных файлах (\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 будет более активно использовать индексы.

Параметры из раздела 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, добавлена ссылка на оригинальную документацию.

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

Tutorial

Мне хотелось создать прекрасный объемлющий мануал Getting Start без всякой воды, но включающий основные плюшки для начинающих по системе PostgreSQL в Linux.

PostgreSQL является объектно-реляционной системой управления базами данных (ОРСУБД) на основе POSTGRES, версия 4.2 , разработанной в Университете Калифорнии в Беркли департаменте компьютерных наук.

PostgreSQL является open source потомком оригинального кода Berkeley. Он поддерживает большую часть стандарта SQL и предлагает множество современных функций:

Cложные запросы
Управление конкурентным доступом с помощью многоверсионности

Кроме того, PostgreSQL может быть расширен пользователем во многих отношениях, например, путем добавления новых

типов данных
функций
операторов
агрегатных функций
индекс методов
процедурных языков

Сборка и установка

Как и все любители мейнстрима PostgreSQL мы будем конечно же собирать, а не скачивать готовые пакеты (в репозитариях Debian, например, нет последней версии). Вот лежит множество версий, скачивать конечно же лучше всего последнюю. На момент написания поста это версия 9.2.2

Wget http://ftp.postgresql.org/pub/source/v9.2.2/postgresql-9.2.2.tar.gz tar xzf postgresql-9.2.2.tar.gz
Теперь у нас есть директория с исходниками сей прекрасной базы данных.
По умолчанию файлы базы будут установлены в директорию /usr/local/pgsql, но эту директорию можно изменить задав

Prefix=/path/to/pgsql
перед командой./configure
Перед сборкой можно указать компилятор С++

Export CC=gcc
PostgeSQL может использовать readline библиотеку, если у вас её нет и нет желания её ставить просто укажите опцию

Without-readline
Надеюсь у всех есть Autotools ? Тогда вперед к сборке:

Cd postgresql-9.2.2 ./configure --without-readline sudo make install clean
Все господа! Поздравляю!

Настройка

Нам необходимо указать хранилище данных наших баз данных (кластер) и запустить её.

Есть один нюанс - владельцем директории данных и пользователь, который может запускать базу должен быть не root. Это сделано в целях безопасности системы. Поэтому создадим специального пользователя
sudo useradd postgres -p postgres -U -m
И далее все понятно

Sudo chown -R postgres:postgres /usr/local/pgsql
Важный процесс. Мы должны инициализировать кластер баз дынных. Сделать мы должны это от имени пользователя postgres

Initdb -D /usr/local/pgsql/data
Теперь нужно добавить запуск PostgreSQL в автостарт. Для этого существует уже готовый скрипт и лежит он в postgresql-9.2.2/contrib/start-scripts/linux
Этот файл можно открыть и обратить внимание на следующие переменные:

prefix - это место куда мы ставили PostgreSQL и задавали в./configure
PGDATA - это то, где хранится кластер баз данных и куда должен иметь доступ наш пользователь postgres
PGUSER - это тот самый пользователь, от лица которого будет все работать

Если все стоит верно, то добвляем наш скрипт в init.d

Sudo cp ./postgresql-9.2.2/contrib/start-scripts/linux /etc/init.d/postgres sudo update-rc.d postgres defaults
Перезапускам систему, чтобы проверить что наш скрипт работает.
Вводим

/usr/local/pgsql/bin/psql -U postgres
И если появится окно работы с базой, то настройка прошла успешно! Поздравляю!
По умолчанию создается база данных с именем postgres

# TYPE DATABASE USER ADDRESS METHOD local all all trust host all all 127.0.0.1/32 trust host all all::1/128 trust
Первая строка отвечает за локальное соединение, вторая - за соединение про протоколу IPv4, а третья по протоколу IPv6.
Самый последний параметр - это как раз таки метод авторизации. Его и рассмотрим (только основные)

trust - доступ к базе может получить кто угодно под любым именем, имеющий с ней соединение.
reject - отклонить безоговорочно! Это подходит для фильтрации определенных IP адресов
password - требует обязательного ввода пароля. Не подходит для локальных пользователей, только пользователи созданные командой CREATE USER
ident - позволяет только пользователем зарегистрированным в файле /usr/local/pgsql/data/pg_ident.conf устанавливать соединение с базой.

Вкратце расскажу об основных утилитах, которые пригодятся в работе.

Утилиты для работы с базой

pg_config

Возвращает информацию о текущей установленной версии PostgreSQL.

initdb

Инициализирует новое хранилище данных (кластер баз данных). Кластер представляет собой совокупность баз данных управляемых одним экземпляром севера. initdb должен быть запущен от имени будущего владельца сервера (как указано выше от имени postgres).

pg_ctl

Управляет процессом работы сервера PostgreSQL. Позволяет запускать, выполнять перезапуск, останавливать работу сервера, указать лог файл и другое.

psql

Клиент для работы с базой дынных. Позволяет выполнять SQL операции.

createdb

Создает новую базу данных. По умолчанию, база данных создается от имени пользователя, который запускает команду. Однако, чтобы задать другого - необходимо использовать опцию -O (если у пользователя есть необходимые привилегии для этого). По сути - это обертка SQL команды CREATE DATABASE.

dropdb

Удаляет базу данных. Является оберткой SQL команды DROP DATABASE.

createuser

Добавляет нового пользователя базы дынных. Является оберткой SQL команды CREATE ROLE.

dropuser

Удаляет пользователя базы данных. Является оберткой SQL команды DROP ROLE.

createlang

Добавляет новый язык программирования в базу PostgreSQL. Является оберткой SQL команды CREATE LANGUAGE.

droplang

Удаляет язык программирования. Является оберткой SQL команды DROP LANGUAGE.

pg_dump

Создает бэкап (дамп) базы данных в файл.

pg_restore

Восстанавливает бэкап (дамп) базы данных из файла.

pg_dumpall

Создает бэкап (дамп) всего кластера в файл.

reindexdb

Производит переиндексацию базы данных. Является оберткой SQL команды REINDEX.

clusterdb

Производит перекластеризацию таблиц в базе данных. Является оберткой SQL команды CLUSTER.

vacuumdb

Сборщик мусора и оптимизатор базы данных. Является оберткой SQL команды VACUUM.

Менеджеры по работе с базой

Что касается менеджера по работа с базой, то есть php менеджер - это

Для Microsoft Windows , Mac OS X и Linux существует один установщик. Его можно скачать здесь . Кликните по иконке нужной версии установки PostgreSQL , соответствующей вашей операционной системе.

В некоторых из инструкций предполагается, что вы устанавливаете PostgreSQL 9.1. Если устанавливаете более новую версию, замените в этих инструкциях 9.1 на номер инсталлируемой вами версии СУБД.

Запустите установку

Когда программа попросит выбрать один из вариантов, сделайте следующее:

Когда вас попросят выбрать локаль, выберите UTF-8 . Если варианта UTF-8 в списке нет, выберите вариант UTF-8 в списке локалей для языка. Например, en_US.UTF-8 для английского языка США;
Если программа попросит установить StackBuilder – он инсталлирует некоторые дополнительные инструменты Web , репликации и ODBC , которые не требуются для CollectionSpace . Но может потребоваться инсталляция некоторых модулей PostgreSQL , таких как PostGIS .

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

Настройка PostgreSQL

Чтобы установленный PostgreSQL работал с CollectionSpace, необходимо настроить пользователей и изменить некоторые параметры.

Найдите конфигурационный файл pg_hba.conf . Он расположен в подкаталоге data каталога, в котором установлена PostgreSQL ;
Откройте этот файл в текстовом редакторе и следуйте приведенным ниже инструкциям;

В Mac OS X по умолчанию это папка /Library/PostgreSQL/9.1.
В Mac OS X нужно иметь права супер пользователя, чтобы редактировать любой из следующих файлов конфигурации.

Убедитесь, что для «local section » указано последнее слово md5 , а не ident :

# "local" is for Unix domain socket connections only local all all md5

Измените раздел «IPv4 local connections » следующим образом:

# IPv4 local connections: host all csadmin samehost md5

Это ограничивает набор пользователей PostgreSQL , которым предоставляется локальный доступ к трем базам данных, используемым CollectionSpace: jbossdb , nuxeo и cspace . Например, только пользователь с именем cspace или супер пользователь PostgreSQL с именем postgres может получить доступ к базе данных cspace с локальной машины.

При установке PostgreSQL 9.x на Windows 7 может не принять термин samehost в столбце CIDR-ADDRESS . Если это произойдет, используйте адресную форму 127.0.0.1/32 :

# IPv4 local connections: host all csadmin 127.0.0.1/32 md5

Убедитесь, что записи в разделе «IPv6 local connections » отключены. В качестве первого символа в строках указывается символ хэш (# ), если только в вашей системе не активен IPv6 :

# IPv6 local connections: #host all all::1/128 md5

Современные системы, работающие под управлением Windows 7 и Windows Vista , могут поставляться с включенным по умолчанию IPv6 . Если в вашей системе включен IPv6 , можно поэкспериментировать со следующей конфигурацией — указать ::1/128 для адреса localhost :

# IPv6 local connections: host all csadmin::1/128 md5

Если нужно разрешить создание отчетов при подключении к БД с удаленных хостов, тогда следует добавить запись, подобную приведенной ниже, но указав свой адрес подсети. Приведенная ниже конфигурация позволит создавать отчеты удаленно с хостов в определенной подсети UC Berkeley . Для получения дополнительной информации о том, как указать адрес подсети, ознакомьтесь с документацией по pg_hba.conf для используемого релиза PostgreSQL .

host all cspace_reader 169.229.0.0/16 md5

Если вы можете контролировать доступ к PostgreSQL через брандмауэр, то проще ввести значение listen_addresses «*» . Для большей безопасности можно ввести список разделенных запятыми IP-адресов , с которых будут связываться авторы отчетов.

Найдите файл postgresql.conf , находящийся в папке data каталога, в котором установлен PostgreSQL ;
Откройте этот файл в текстовом редакторе и внесите следующие изменения:

max_prepared_transactions = 64

Значение переменной max_prepared_transactions , равное 64 , может оказаться большим для вашей системы. Если это так, установите меньшее значение.

Если это значение действительно слишком велико для вашей системы, вы получите сообщение об ошибке при перезапуске PostgreSQL :
Restarting PostgreSQL … database server: main The PostgreSQL server failed to start. Please check the log output … FATAL: could not create shared memory segment: …

Перезапустите службу PostgreSQL

Если при запуске сервера после установки PostgreSQL выводятся сообщения об ошибках, обратитесь к разделу «Сбои при запуске сервера » в документации PostgreSQL по запуску сервера .

Linux:

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

service postgresql restart

Mac:

Убедитесь, что вы являетесь пользователем postgres :

sudo su - postgres pg_ctl restart -D /Library/PostgreSQL/9.1/data

Флаг -D указывает местоположение каталога данных PostgreSQL, который также может быть установлен как переменная среды PGDATA. По умолчанию его можно найти по адресу /Library/PostgreSQL/9.1/data.

Если при попытке запустить pg_ctl вы получаете сообщение об ошибке «not found», попробуйте указать полный путь к этому файлу в подкаталоге bin каталога, в котором установлен PostgreSQL. Например: /Library/PostgreSQL/9.1/bin/pg_ctl restart -D /Library/PostgreSQL/9.1/data

Чтобы добавить PGDATA в качестве глобальной переменной среды в / etc / profile , выполните следующие шаги:

sudo vi /etc/profile

Затем добавьте следующую строку:

export PGDATA=»/Library/PostgreSQL/9.1/data»

После этого можно будет выполнить предыдущую команду для перезапуска сервера PostgreSQL без флага -D .

Windows:

При установке PostgreSQL Windows у вас должны быть права администратора. Кликните правой кнопкой мыши по ярлыку «Мой компьютер » и выберите пункт «Управление ». В пользовательском интерфейсе «Управление » выберите «Службы и приложения » — «Службы ». Найдите службу PostgreSQL («postgresql-9.0 — PostgreSQL Server 9.0» ), выберите ее и нажмите на кнопку «Перезапустить службу ».

Настройка типов данных

Откройте консоль PostgreSQL для базы данных template1 :

Если при попытке запустить psql на экране появится сообщение not found», попробуйте указать полный путь к этому файлу в подкаталоге bin; например на Mac OS X: /Library/PostgreSQL/9.1/bin/psql.

Linux:

Выполните в консоли две следующие команды:

su - postgres psql -d template1 #open the database template1

Mac:

Под пользователем postgres выполните следующие две команды:

Sudo su - postgres Psql -d template1

При первом запуске команды psql на OS X 10.8.X вы можете увидеть сообщение об ошибке:

dyld: Library not loaded: @loader_path/../lib/libssl.dylib Referenced from: /usr/lib/libpq.5.dylib Reason: Incompatible library version: libpq.5.dylib requires version 1.0.0 or later, but libssl.0.9.8.dylib provides version 0.9.8

Это связано с тем, как Homebrew в Mac OS X и Mountain Lion конфликтуют с определенными системными библиотеками. Решение этой проблемы заключается в том, чтобы скопировать и связать версии библиотеки. PostgreSQL упакован в /usr/lib , где библиотеки хранятся в Mountain Lion .

sudo cp /Library/PostgreSQL/9.1/lib/libssl.1.0.0.dylib /usr/lib sudo cp /Library/PostgreSQL/9.1/lib/libcrypto.1.0.0.dylib /usr/lib sudo ln -fs /usr/lib/libssl.1.0.0.dylib /usr/lib/libssl.dylib sudo ln -fs /usr/lib/libcrypto.1.0.0.dylib /usr/lib/libcrypto.dylib

Еще одним решением может стать пересмотр Homebrew и проверка совместимости с Mountain Lion .

При установке PostgreSQL на Mac OS X в один клик создается ярлык для оболочки PostgreSQL в каталоге Applications / PostgreSQL 9.0 / . Нажмите SQL Shell (psql).app , чтобы открыть новое окно терминала с запущенным psql .

Из этого окна терминала можно получить доступ к базе данных template1 , введя:

psql c template1

Windows:

psql запускается из командной строки (cmd ) Windows . Убедитесь, что путь к папке postgres bin хранится в переменной PATH , или просто вызовите ее с полным путем к месту расположения исполняемого файла psql :

psql -d template1 -U postgres

Выполните команды консоли:

CREATE FUNCTION pg_catalog.text(integer) RETURNS text STRICT IMMUTABLE LANGUAGE SQL AS "SELECT textin(int4out($1));"; CREATE CAST (integer AS text) WITH FUNCTION pg_catalog.text(integer) AS IMPLICIT; COMMENT ON FUNCTION pg_catalog.text(integer) IS "convert integer to text"; CREATE FUNCTION pg_catalog.text(bigint) RETURNS text STRICT IMMUTABLE LANGUAGE SQL AS "SELECT textin(int8out($1));"; CREATE CAST (bigint AS text) WITH FUNCTION pg_catalog.text(bigint) AS IMPLICIT; COMMENT ON FUNCTION pg_catalog.text(bigint) IS "convert bigint to text";

Создайте пользователя csadmin

Для PostgreSQL установки и настройки в командной строке psql (заканчивающейся на # ) переключитесь с базы данных template1 на postgres , введя следующее:

c postgres

Введите следующую команду, чтобы создать пользователя csadmin с соответствующими привилегиями. Не забудьте заменить пароль replacemewithyourpassword в приведенном ниже примере на пароль по вашему выбору.

CREATE ROLE csadmin LOGIN PASSWORD ‘replacemewithyourpassword’ SUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

В результате вы должны увидеть сообщение, подобное этому: CREATE ROLE .

Закройте программу psql , введя q (или нажав Ctrl + d ).

Теперь перезапустите сервер PostgreSQL еще раз (как описано выше ).

Дополнительная настройка

Дополнительная настройка базы данных является необязательной! CollectionSpace будет выполняться, даже если ни одно из описанных ниже действий не будет выполнено.

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

PostgreSQL установка и настройка Windows выполняется через postgresql.conf . Откройте этот файл в текстовом редакторе и отредактируйте следующие значения:

shared_buffers = 512MB

Теперь через командную строку задайте значение kernel.shmmax . Оно должно как минимум равняться shared_buffer + 128MB :

sysctl kernel.shmmax=650000000

Установка

Для установки PostgreSQL выполните следующую команду в терминале:

Sudo apt-get install postgresql

Настройка

По умолчанию соединения через TCP/IP заблокированы. PostgreSQL поддерживает множество методов аутентификации. Метод аутентификации IDENT используется для postgres и локальных пользователей пока не настроено что-то еще. Обратитесь к , если вы собираетесь использовать какую-либо альтернативу типа Kerberos.

Чтобы разрешить соединения по TCP/IP, отредактируйте файл /etc/postgresql/8.4/main/postgresql.conf. Найдите строку

#listen_addresses = "localhost"

и замените ее на:

Listen_addresses = "localhost"

Sudo -u postgres psql template1

ALTER USER postgres with encrypted password "your_password";

Local all postgres md5

Sudo /etc/init.d/postgresql-8.4 restart

Ссылки

1. Как упоминалось выше, Administrator"s Guide - великолепный ресурс. Руководство также доступно из пакета postgresql-doc-8.4 . Выполните следующую команду в терминале для установки пакета.

Вступление

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

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

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

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

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

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

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

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

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

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

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

Host all all 127.0.0.1/32 trust

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

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

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

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

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

shared_buffers = 512MB

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

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

work_mem = 128MB

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

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

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

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

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

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

autovacuum = off

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

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

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

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

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

fsync = off
full_page_writes = off

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

synchronous_commit = off

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

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

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

Устанавливать будем сборку от компании Postgres Professional . На странице с версией для 1С:Предприятие найдем информацию об установке на CentOS 7 свежей версии PostgreSQL.

Подключим репозитории и установим PostgreSQL 9.6:

Sudo rpm -ivh http://1c.postgrespro.ru/keys/postgrespro-1c-centos96.noarch.rpm sudo yum makecache sudo yum install postgresql-pro-1c-9.6

Базовая настройка PostgreSQL

Инициализируем служебные базы данных с русской локализацией:

Su postgres /usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data --locale=ru_RU.UTF-8 exit service postgresql-9.6 initdb

Запускаем службу PostgreSQL и добавляем его в автозагрузку:

Systemctl enable postgresql-9.6 systemctl start postgresql-9.6 systemctl status postgresql-9.6

Задаем пароль пользователю postgres, для того чтобы была возможность подключаться к серверу удаленно:

Su - postgres psql ALTER USER postgres WITH ENCRYPTED PASSWORD "yourpassword"; \q exit

Mcedit /var/lib/pgsql/9.6/data/pg_hba.conf

в открывшемся файле раскомментируем и изменим строки:

host all all 127.0.0.1/32 ident на host all all 127.0.0.1/32 md5

host all all 0.0.0.0/0 ident на host all all 0.0.0.0/0 md5

Оптимизация настроек PostgreSQL (postgresql.conf) для 1С:Предприятие

Здесь будут настройки для PostgreSQL, работающей в виртуальной машине ESXi 6.5.

Ресурсы выделенные для ВМ:

процессор — 8 vCPU;

память — 48 GB;

диск для ОС — 50 GB на LUN аппаратном RAID1 из SAS HDD;

диск для БД — 170 GB на программном RAID1 из SSD

диск для логов — 100 GB на программном RAID1 из SSD

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

Mcedit /var/lib/pgsql/9.6/data/postgresql.conf

Закомментированные параметры, которые будем изменять необходимо активировать.

Процессор

autovacuum_max_workers = 4

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

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

ssl = off

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

Память

shared_buffers = 12GB

shared_buffers = RAM/4

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

temp_buffers = 256MB

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

work_mem = 64MB

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

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

maintenance_work_mem = 2GB

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

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

effective_cache_size = 36GB

effective_cache_size = RAM — shared_buffers

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

Диски

effective_io_concurrency = 5

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

random_page_cost = 1.3

random_page_cost = 1.5-2.0 для RAID, 1.1-1.3 для SSD

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

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 секунды), но гарантирует целостность базы данных, в цепочке коммитов гарантированно отсутствуют пропуски. Но значительно увеличивает производительность.

wal_keep_segments = 256

wal_keep_segments = 32..256

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

wal_buffers = 16 MB

Объём разделяемой памяти, который будет использоваться для буферизации данных WAL, ещё не записанных на диск. Значение по умолчанию, равное -1, задаёт размер, равный 1/32 (около 3%) от , но не меньше, чем 64 КБ и не больше, чем размер одного сегмента WAL (обычно 16 МБ). Это значение можно задать вручную, если выбираемое автоматически слишком мало или велико, но при этом любое положительное число меньше 32 КБ будет восприниматься как 32 КБ. Этот параметр можно задать только при запуске сервера.

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

default_statistics_target = 1000

Устанавливает целевое ограничение статистики по умолчанию, распространяющееся на столбцы, для которых командой ALTER TABLE SET STATISTICS не заданы отдельные ограничения. Чем больше установленное значение, тем больше времени требуется для выполнения ANALYZE , но тем выше может быть качество оценок планировщика. Значение этого параметра по умолчанию - 100.

checkpoint_completion_target = 0.9

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

min_wal_size = 4G
max_wal_size = 8G

min_wal_size = 512MB .. 4G
max_wal_size = 2 * min_wal_size

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

fsync = on

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

row_security = off

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

enable_nestloop = off

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

Блокировки

max_locks_per_transaction = 256

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

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

standard_conforming_strings = off

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

escape_string_warning = off

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

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

Сделаем так, чтобы сервер PostgreSQL был виден только для сервера 1С: Предприятие, установленного на этой же машине.

listen_addresses = ‘localhost’

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

Хранение базы данных

PostgreSQL как и почти любая СУБД критична к дисковой подсистеме, поэтому для повышения быстродействия СУБД разместим систему PostgreSQL, логи и сами базы на разные диски.

Останавливаем сервер

Systemctl stop postgresql-9.6

Переносим логи на из 120GB SSD:

Mv /var/lib/pgsql/9.6/data/pg_xlog /raid120 mv /var/lib/pgsql/9.6/data/pg_clog /raid120 mv /var/lib/pgsql/9.6/data/pg_log /raid120

Ln -s /raid120/pg_xlog /var/lib/pgsql/9.6/data/pg_xlog ln -s /raid120/pg_clog /var/lib/pgsql/9.6/data/pg_clog ln -s /raid120/pg_log /var/lib/pgsql/9.6/data/pg_log

Так же перенесем каталог с базами:

Mv /var/lib/pgsql/9.6/data/base /raid200

Ln -s /raid200/base /var/lib/pgsql/9.6/data/base

запустим сервер и проверим его статус

Systemctl start postgresql-9.6 systemctl status postgresql-9.6