Хотя интернет уже переполнен статьями о «правильной» настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самая большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно.

Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

Итак, что имеем: игрушку IBM x3650 M4 c двумя процессорами, 32 GB оперативки, массив RAID 10 из 6-и дисков общим объемом ~900GB. Являясь сторонником опенсорсного ПО и немалый опыт работы с системами а-ля Debian и производные, решил выбрать в качестве операционки самую «человечную» из них - Ubuntu Server x64. Как потом оказалось - это была первая моя ошибка.

С СУБД знаком не понаслышке но, имею пока еще малый опыт работы именно на Linux платформу. Поэтому, если где-то ошибся, прошу пинать строго советами. Не один я такой все-таки.

Наконец 1С выпустила свежую сборку PostgreSQL под Debian/Ubuntu которая работает почти «из коробки».

Процес установки упростился до дюжины консольных комманд.

Admin@srv1c:~# sudo su

1. Увеличиваем максимальный размер сегмента памяти до 8Гб. Для менее мощных машин устанавливают от 64Мб до половины объема оперативки.

Root@srv1c:~# echo "kernel.shmmax=8589934592" >>/etc/sysctl.conf root@srv1c:~# sysctl -p

2. Генерируем русскую локаль и задаем переменную среды LANG, именно с ней будет работать скрипт инициализации базы данных.

Root@srv1c:~# locale-gen en_US ru_RU ru_RU.UTF-8 root@srv1c:~# export LANG="ru_RU.UTF-8"

3.Устанавливаем необходимые зависимисти.

Root@srv1c:~# apt-get install libssl0.9.8 ssl-cert postgresql-common libossp-uuid16 libxslt1.1

4. Берем с сайта users.v8.1c.ru архив с PostgreSQL 9.1.2 для 64-битных DEB-систем, распаковываем и устанавливаем нужные компоненты. Нужных и не нужных компонентов в архиве много, для того что бы все заработало достаточно postgresql, postgresql-client и postgresql-contrib.

Root@srv1c:~# tar zxf postgresql_9_1_2_deb_x86_64_tar.gz

5. Установка пакетов:

Root@srv1c:~# cd ./postgres root@srv1c:~# dpkg -i postgresql-9.1_9.1.2-1.1C_amd64.deb libpq5_9.1.2-1.1C_amd64.deb postgresql-client-9.1_9.1.2-1.1C_amd64.deb postgresql-contrib-9.1_9.1.2-1.1C_amd64.deb

6. После установки нужно еще немного подправить конфигурационный файл, как не странно будучи поставленным в пакете 1с он содержит не правильные настройки для обработки экранирующих символов, и при создании базы 1с выдает ошибки “syntax error at or near “SECOND” at character 127″ или “syntax error at or near “SECOND” at character 227″. Исправляем в файле /etc/postgresql/9.1/main/postgresql.conf следующие параметры.

Root@srv1c:~# nano /etc/postgresql/9.1/main/postgresql.conf

Backslash_quote = on escape_string_warning = off standart_conforming_strings = off
И закрываем с сохранением: Ctrl+x, Y

7. Перезапускаем сервис.

Root@srv1c:~# service postgresql restart

8.Меняем пароль для пользователя postgres – это тот пароль который мы будем задавать при создании базы данных.

Root@srv1c:~# su postgres postgres@srv1c:/root$ cd ~ postgres@srv1c:~$ psql -U postgres -c "alter user postgres with password "ваш пароль";" postgres@srv1c:~$ exit

9. Отключаем обновление для пакетов 1с-овского PostgreSQL.

Root@srv1c:~# echo "libpq5" hold | dpkg --set-selections root@srv1c:~# echo "postgresql-9.1" hold | dpkg --set-selections root@srv1c:~# echo "postgresql-client-9.1" hold | dpkg --set-selections root@srv1c:~# echo "postgresql-contrib-9.1" hold | dpkg --set-selections

10. Перезапускаем службу и проверяем, запустился ли PostgreSQL:

Root@srv1c:~# service postgresql restart root@srv1c:~# netstat -atn|grep 5432

Ответ должен быть примерно таким:

Tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN

Tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN

Здесь установка PostgreSQL закончена можно считать законченной.

При сравнении скорости работы связки 1C 8.2.16 + PostgeSQL 9.1.2 были обнаружены жуткие тормоза под Ubuntu Server 12.04. Тест от Гилёва «TPC_1С_GILV» в Ubuntu в среднем показал 10-14 баллов, что обусловлено тестовой базой, которая не задействует управляемые блокировки. Для сравнения, на менее мощную систему с четырехядерным процессором i5, 8GB оперативки, под Win 2k8 и IBM DB2 тот же тест показал 52 попугая. Проведение документов за месяц занимало в трое меньше времени на младшую машину. Аналогичные результаты получены и с PostgreSQL. Некоторые коллеги отзываются о результатах на CentOS при аналогичных параметрах. Так на CentOS получают по тому же тесту 56-62 балла а на чистую Debian - от 54 балла. Во всех тестах использовались идентичные настройки PG с отключенным fsync. В Ubuntu проверялись ext4, в CentOS LVM+ext3.

На всех платоформах ничего не ставилось кроме PG и 1C. На Ubuntu проверялись несколько версий PG, от Etersoft, собранная вручную с патчами от 1С и сборка от 1С, под CentOS использовалась версия Etersoft.

Есть какие-то варианты улучшения производительности в Ubuntu?

Я уже готовлю систему под CentOS. О результатах тестирования отпишусь в новой статье.

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Тюнинг PostgreSQL 9.4.2.

pg_hba.conf
postgresql.conf
pgpass.conf

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

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

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

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

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

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

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

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

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

Базы данных 1С можно !

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

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

Процессор

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

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

Ssl = off

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

Память

shared_buffers = RAM/4

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

Temp_buffers = 256MB

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

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

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

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

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

Effective_cache_size = RAM - shared_buffers

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

Диски

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

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

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

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

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

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

Autovacuum_naptime = 20s

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

Bgwriter_delay = 20ms

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

Bgwriter_lru_multiplier = 4.0 bgwriter_lru_maxpages = 400

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

Synchronous_commit = off

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

Checkpoint_segments = 32..256 < 9.5

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

Checkpoint_completion_target = 0.5..0.9

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

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

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

Fsync = on

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

Commit_delay = 1000

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

Commit_siblings = 5

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

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

Temp_tablespaces = "NAME_OF_TABLESPACE"

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

row_security = off >= 9.5

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

Max_files_per_process = 1000 (default)

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

Сеть

max_connections = 500..1000

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

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

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

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

Блокировки

max_locks_per_transaction = 256

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

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

standard_conforming_strings = off

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

Escape_string_warning = off

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

Shared_preload_libraries = "online_analyze, plantuner"

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

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

Online_analyze.enable = on

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

Оптимизатор

default_statistics_target = 1000 -10000

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

Enable_nestloop=off, enable_mergejoin=off

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

Join_collapse_limit=1

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

From_collapse_limit = 20

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

Online_analyze.table_type = "all"

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

Online_analyze.threshold = 50

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

Online_analyze.scale_factor = 0.1

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

Online_analyze.min_interval = 10000

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

Online_analyze.local_tracking = off

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

Online_analyze.verbose = "off"

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

Plantuner.fix_empty_table = "on"

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

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

Для чего это надо

Использование позволяет:

Снизить системные требования к компьютерам пользователей, за счет перераспределения нагрузки;
Работать с базами данных больших объемов;
Использовать тонкий клиент для работы с информацией;
Оптимизировать время выполнения запросов и обращений к базе данных;
Автоматизировать выполнение фоновых и регламентных заданий;
Настроить резервное копирование и ускорить время восстановления базы данных из сохраненной копии.

Условия для решения задачи

На старте мы имеем:

Персональный компьютер с установленной 64 разрядной операционной системой Windows 7;
Инсталлятор 1С, платформа 8.3.10.2505;
Файловую базу данных «Зарплата и управление персоналом», версия 3.1.3.223;
Оптимизированный для 1С postgreSQL установщик PostgreSQL 64-bit 9.4.11;
Дополнительную утилиту для администрирования сервера pgAdmin 4.

Приступим к установке.

Установка сервера и его настройка

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

Дойдя до окна (Рис.1) мы должны будем ввести пароль супер пользователя.

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

Галочка «Поддерживать подключение…» установлена по умолчанию, в случае, если сервер базы данных и сервер 1С находятся на одном компьютере, ее можно снять.

Так как на подопытном компьютере установлена только одна 4GB плитка оперативной памяти, программа автоматически может увеличить её объем, о чем и сообщает окно (Рис.2).

Рис. 2

В принципе, больше здесь настраивать нечего. После установки в главном меню появится соответствующая папка (Рис.3).

Рис. 3

Отсюда можно останавливать, перезагружать и стартовать сервер.

Ее установка также не представляет никаких проблем.

Выполняем её запуск и видим окно (Рис.4)

Рис.4

Дальнейшая последовательность действий:

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

Для этого необходимо вызвать контекстное меню ветки «Tablespaces» и создать новый элемент. Для каждой базы данных можно прописать:

Имя места хранения;
Месторасположение рабочей директории;
Создать комментарий, содержащий подробную информацию о месторасположении таблиц.

Теперь приступим к настройке 1С.

Установка и настройка 1С

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

Сервер 1С Предприятия;
Утилиту администрирования сервера;
Модули расширения сервера;
Саму платформу.

Это обязательный набор, остальные компоненты устанавливаются по желанию (Рис.9).

Рис.9

На втором шаге нам предложат выбрать пользователя или создать нового (Рис.10).

Рис.10

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

Вход в систему как сервис;
Вход в систему как пакетное задание.

Запустив утилиту администрирования, убеждаемся, что наш сервер активен.

Добавляем новую информационную базу в дерево администрирования (Рис.11)

Рис.11

Здесь важно отметить, что создание базы данных 1С на PostgreSQL сервере можно выполнить и из окна запуска приложения. В этом случае:

Чуть подробнее про эту форму:

Кластер серверов – если база находится на том же компьютере, что и сервер, в качестве значения здесь будет использована строка «localhost»;
Имя базы в кластере – именно под этим именем администратор сервера будет видеть информационную базу в дереве кластера;
Тип СУБД – так как мы поднимаем PostgreSQL cервер, именно его и надо указать в окне;
Имя базы данных – это для идентификации базы в утилите администрирования PostgreSQL сервера;
Пользователь – суперюзер указанный при создании сервера;
Пароль – соответственно пароль суперюзера.

Таким образом, мы создали пустую информационную базу 1С на сервере PostgreSQL. Чтобы начать с ней работать, достаточно в режиме «Конфигуратор» загрузить выгруженную из файлового варианта копию базы (в формате dt).

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

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

Если у вас проблема с медленной работой 1С, то на 99% это проблема не с самой 1С, а это проблема в не правильной настройке СУБД, вот собственно о б этом и пойдет речь, как правильно настроить СУБД PostgreSQL для быстрой работы 1С.

И так начнем для настройки PostgreSQL мы будем использовать pgAdmin на мой взгляд он очень удобен в настройке. Для начала сделаем копии конфигурационных файлов Postgresql.conf и pg_hba.conf они находиться:

C:\Program Files\PostgreSQL\9.2.х-1.1C\data

Это поможет вам быстро вернуть все в рабочее состояние если в друг что-то пойдёт не так.

postgresql.conf – это файл конфигурации СУБД PostgreSQL который мы в основном и будим править.

pg_hba.conf – это файл настройки доступа к СУБД, данный файл если вы в нем не чего не меняли по умолчанию правильный, но в нем можно допивать дополнительные настройки доступности.

Отрываем настройки конфигурации (Postgresql.conf) и там нам интересны следующие параметры:

shared_buffers – этот параметр определяет количество совместного кэша страниц СУБД. Рассчитывается примерно, делим всю доступную память на 4.

effective_cache_size – это параметр отвечает за оценку размера кэша файловой системы. Рассчитывается 32гб – shared_buffers = effective_cache_size.

temp_buffers – Этот параметр размера буфера для временных страниц, я оставляю по умолчанию равное 256 мб.

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

synchronous_commit = off - данный параметр ВЫКлючает синхронизацию с диском. Данный параметр дает значительный прирост в производительности.

autovacuum = on – это сбор мусора, также обязательно рекомендую включать настройки автовакума они тоже значительно помогут ускроить работу вашей 1С.

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

autovacuum_naptime = 20s – минимальный интервал, реже которого autovacuum не будет запускаться.

После чего применяем настройки и перезагружаем конфигурацию сервера СУБД.

Но вот думаю эти настройки уже позволят вам значительно ускорить работу 1С. Для более тонкой настройки работы связки PostgreSQL и 1С нужен более полный анализ и возможно модернизация сервера.