Устанавливаем PostgreSQL. Устанавливаем PostgreSQL Установка postgresql 9.4 для 1с 8.3


Как только размер файловой базы данных 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С можно !

Устанавливать будем сборку от компании 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

В этой статье я попробую рассказать об установке сервера 1С и сервера PostgreSQL на операционной системе Ubuntu 16.04/18.04. В статье используется версия сервера 1С - 8.3.13.1472 и версия PostgreSQL - 10.3-2.1C. Кроме этого в статье приведена информации о некоторых дополнительных настройках.

Установка PostgreSQL

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

sudo dpkg-reconfigure locales

sudo apt-get install libicu55

wget http://security.ubuntu.com/ubuntu/pool/main/i/icu/libicu55_55.1-7ubuntu0.4_amd64.deb

sudo dpkg -i libicu55_55.1-7ubuntu0.4_amd64.deb

Раньше пакет «postgresql-common» входил в состав дистрибутива который размещался на сайте «1С», теперь же (начиная с PostgreSQL 9.6.3-1.1C) этот пакет нужно устанавливать из стандартных репозиториев.

Тут возникает небольшое затруднение, связанное с тем, что мы устанавливаем PostgreSQL 10: на момент написания статьи стандартный репозиторий содержит неподходящую для PostgreSQL 10 версию пакета «postgresql-common».

Чтобы исправить это нужно создать файл /etc/apt/sources.list.d/pgdg.list и записать в него строку, для Ubuntu 16.04:

deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg main

для Ubuntu 18.04:

deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main

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

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

sudo apt-get update

После этого можно установить нужную нам версию пакета «postgresql-common»:

sudo apt-get install postgresql-common

Подготовительные работы закончены, скачиваем дистрибутив PostgreSQL 10 с сайта «1С», распаковываем его (там всего три пакета) и устанавливаем именно в таком порядке:

sudo dpkg -i libpq5_10.3-2.1C_amd64.deb

sudo dpkg -i postgresql-client-10_10.3-2.1C_amd64.deb

sudo dpkg -i postgresql-10_10.3-2.1C_amd64.deb

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


Настройка PostgreSQL

После установки можно сделать некоторые настройки PostgreSQL.

От имени суперпользователя открываем файл /etc/postgresql/10/main/pg_hba.conf и меняем в нем строку:

local all postgres peer

local all postgres trust

Это позволит войти под пользователем postgres без пароля.

Кроме этого можно открыть файл /etc/postgresql/10/main/postgresql.conf (тоже от имени супер пользователя) и поменять в нем строку:

listen_addresses = "*"

listen_addresses = "localhost"

Это ограничит подключения к PostgreSQL локальной машиной. Таким образом, если сервер 1С и PostgreSQL находятся на разных компьютерах, то это либо вообще не нужно делать, либо вместо «*» нужно указать IP-адрес сервера 1С.

После всех этих манипуляций перезапускаем сервер PostgreSQL:

Теперь у нас есть возможность поменять пароль суперпользователя postgres :

psql -U postgres -d template1 -c "ALTER USER postgres PASSWORD "password""

Отключаем безпарольный доступ: вновь от имени суперпользователя открываем файл /etc/postgresql/10/main/pg_hba.conf и меняем в нем строку:

local all postgres trust

local all postgres md5

В заключении еще раз перезапускаем сервер:

sudo service postgresql restart

Установка сервера 1С

Начать, как обычно, нужно с установки дополнительных библиотек:

sudo apt-get install imagemagick

sudo apt-get install unixodbc

sudo apt-get install ttf-mscorefonts-installer

sudo apt-get install libgsf-1-114

Для версии 8.3.13 и выше используется библиотека ImageMagick входящая в состав дистрибутива, так что устанавливать пакет imagemagick не обязательно (хотя вреда от этого не будет).

Пакет ttf-mscorefonts-installer в процессе установки попросит принять лицензионное соглашение:


На момент написания статьи в репозиториях Ubuntu 18.04 не было актуальных версий требуемых пакетов. Если в настоящее время их все еще нет, то можно попробовать добавить репозитории с неактуальными версиями пакетов. Создаем файл /etc/apt/sources.list.d/raring.list и записываем в него следующие строки:

deb http://old-releases.ubuntu.com/ubuntu/ raring main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ raring main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ raring-updates main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ raring-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ raring-backports main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ raring-backports main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ raring-proposed main restricted universe multiverse
deb-src http://old-releases.ubuntu.com/ubuntu/ raring-proposed main restricted universe multiverse

После этого выполнить команду:

sudo apt-get update

После установки дополнительных библиотек скачиваем с сайта 1С все необходимые файлы (Cервер 1С:Предприятия (64-bit) для DEB-based Linux-систем) и устанавливаем их в таком порядке:

sudo dpkg -i 1c-enterprise83-common_8.3.13-1472_amd64.deb

sudo dpkg -i 1c-enterprise83-common-nls_8.3.13-1472_amd64.deb

sudo dpkg -i 1c-enterprise83-server_8.3.13-1472_amd64.deb

sudo dpkg -i 1c-enterprise83-server-nls_8.3.13-1472_amd64.deb

sudo dpkg -i 1c-enterprise83-ws_8.3.13-1472_amd64.deb

sudo dpkg -i 1c-enterprise83-ws-nls_8.3.13-1472_amd64.deb

Пакеты с приставкой «-nls» нужны для поддержки дополнительных языков и не являются обязательными к установке. Пакеты с приставкой «-ws» нужны для работы веб-клиента и также не являются необходимыми.

Теперь изменим владельца каталога /opt/1C:

sudo chown -R usr1cv8:grp1cv8 /opt/1C

И запустим сервер 1С:

sudo service srv1cv83 start


Если у Вас правильно настроена сеть и компьютеры видят друг друга, то ничего больше делать не нужно. Если же нет, то необходимо сделать так, что бы сервер 1С видел сервер PostgreSQL, а клиентские машины видели сервер 1С. Для этого в файлы /etc/hosts или C:\Windows\System32\drivers\etc\hosts нужно добавить строки:

<результат команды hostname -f> <результат команды hostname>

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

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

Все приведенные ниже действия не являются обязательными.

Установка Apache

Начиная с версии 8.3.8 платформа 1С поддерживает Apache 2.4, поэтому можно просто установить текущую версию:

sudo apt-get install apache2

Если по каким-то причинам Вам требуется Apache 2.2 то для начала нужно добавить репозитории с неактуальными версиями пакетов, как описано выше (если, конечно, Вы уже этого не сделали). Затем выполнить команду:

sudo apt-cache showpkg apache2

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

sudo apt-get install apache2=<номер версии>

Например:

sudo apt-get install apache2=2.2.22-6ubuntu5.1

Проверить версию Apache можно так:

Включение отладки на сервере

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

sudo service srv1cv83 stop

В файле /etc/init.d/srv1cv83 находим строку:

Приводим ее к виду:

Запускаем сервер:

sudo service srv1cv83 start

В конфигураторе на клиентской машине идем в «Параметры» -> «Запуск 1С:Предприятия» -> «Дополнительные» и включаем два пункта:

  • «Устанавливать режим разрешения отладки»
  • «Начинать отладку при запуске»

Настройка UFW

UFW - это простая утилита для конфигурирования файрвола Netfilter.

Хотя интернет уже переполнен статьями о «правильной» настройке связки 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. О результатах тестирования отпишусь в новой статье.

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

Настройка PostgreSQL под 1С

Опыт эксплуатации баз 1С на PostgreSQL показал, что наибольшей производительности и оптимальной работы 1С и PostgreSQL удалось добиться на linux, поэтому желательно использовать именно ее. Но вне зависимости от операционной системы, важно помнить, что настройки, указанные по умолчанию при установке PostgreSQL, предназначены только для запуска сервера СУБД. Ни о какой промышленной эксплуатации речи идти не может! Следующим шагом после запуска станет оптимизация PostgreSQL под 1С:

  • Для начала отключаем Energy Saving (в противном случае могут непредсказуемо вырасти задержки ответов из БД) и запрещаем своппинг разделяемой памяти.
  • Настраиваем основные параметры сервера СУБД (рекомендации по настройке описаны достаточно подробно, как на официальном сайте вендора, так и компанией 1С, поэтому остановимся только на самых важных).
  • В типовых рекомендациях компании 1С предлагается отключать механизмы HyperThreading. Но тестирование Postgres-pro на серверах, с включенной SMT (simultaneous multi threading), показало другие результаты .
Установка параметра shared_buffers в RAM/4 является рекомендацией по умолчанию, но пример Sql Server говорит о том, что чем больше памяти ему выделяется, тем лучше его производительность (при отключенном сбросе страниц в файл подкачки). То есть, чем больше страниц данных располагаются в оперативной памяти, тем меньше обращений к диску. Возникает вопрос: почему такой маленький кэш? Ответ прост: если shared_buffers большой, то часть неиспользуемых страниц свопируется на диск. Но как отследить момент, когда сброс прекратится, и показатель параметра будет оптимальным? Для достижения и выхода на оптимальный показатель shared_buffers, его значение необходимо поднимать на продуктиве ежедневно (по возможности) с определенным шагом прироста и смотреть, в какой момент начнется сброс страниц на диск (увеличится своп).
  • Помимо этого, на «большой параметр» негативно влияет работа с множеством мелких страниц, которые по умолчанию имеют размер 8Кб. Работа с ними увеличивает накладные расходы. Что можно с этим сделать для оптимизации под 1С? В версии postgreSQL 9.4 появился параметр huge_pages, который можно включить, но только в Linux. По умолчанию включаются огромные страницы с размером по умолчанию 2048 kB. Дополнительно поддержку данных страниц необходимо включить в ОС. Таким образом, оптимизировав структуру хранения, можно выйти на больший показатель shared_buffers.
  • work_mem = RAM/32..64 или 32MB..128MB Задает объем памяти для каждой сессии, который будет использоваться для внутренних операций сортировки, объединения и пр., прежде чем будут задействованы временные файлы. При превышении этого объема, сервер будет использовать временные файлы на диске, что может существенно снизить скорость обработки запросов. Данный параметр используется при выполнении операторов: ORDER BY, DISTINCT, соединения слиянием и пр.
  • Посчитать дополнительно данный параметр можно следующим образом: (Общая память shared_buffers – память на другие программы) / число активных соединений. Это значение можно уменьшать, следя за количеством создаваемых временных файлов. Такую статистику по размеру и количеству временных файлов можно получить из системного представления pg_stat_database.
  • effective_cache_size = RAM - shared_buffers основная задача этого параметра подсказать оптимизатору запроса, какой способ получения данных выбрать: полный просмотр или сканирование по индексу. Чем выше значение параметра, тем больше вероятность использования сканирования по индексу. При этом сервер не учитывает, что данные при выполнении запроса могут оставаться в памяти, и следующему запросу не надо их поднимать с диска.

    • Установка PostgreSQL

    Установка 1С на PostgreSQL под Windows – достаточно простой процесс. При запуске установочного пакета необходимо указать кодировку UTF-8. По сути, это единственный интересный нюанс и еще какая-то настройка PostgreSQL для 1С 8.3 из-под Windows не потребуется. Установка и настройка PostgreSQL для 1С на ОС linux может вызвать ряд затруднений. Для их преодоления в качестве примера рассмотрим запуск работы (используя дистрибутивы ведущего российского вендора PostgreSQL-Pro и компании 1С) PostgreSQL на сервере Ubuntu 16.04 х64

    Установка дистрибутивов 1С для СУБД PostgreSQL

    1.Скачиваем указанную позицию дистрибутива СУБД PostgreSQL:

    2.Выкладываем PostgreSQL на сервер;

    3.Распаковать установщик СУБД PostgreSQL можно командой:

    tar -xvf postgresql-9.4.2-1.1C_amd64_deb.tar.bz2

    4.Перед установкой дистрибутива СУБД PostgreSQL проверим наличие в системе необходимой локали (по умолчанию ru_RU.UTF-8):


    5.Если система, с которой будет работать PostgreSQL, ставилась с языком отличным от русского, необходимо создать новые локали:

    locale-gen ru_RU update-locale LANG=ru_RU.UTF8 dpkg-reconfigure locales

    6.Если необходимая локаль все же имеется, устанавливаем ее по умолчанию:

    locale –a nano /etc/default/locale Заменяем содержимое на LANG=ru_RU.UTF-8

    7.После перезагрузки, установим необходимые пакеты для нашей версии PostgreSQL:

    apt-get install libxslt1.1 ssl-cert

    8.Версия PostgreSQL пакета 9.4.2-1.1C связана с пакетом libicu версии libicu48. В репозитории нужной версии уже нет, ее можно скачать ;

    9.Скачиваем и помещаем в каталог, где хранятся скачанные файлы для PostgreSQL;

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

    cd <Путь к папке с файлами> dpkg -i libicu48_4.8.1.1-3ubuntu0.6_amd64.deb dpkg -i libpq5_9.4.2-1.1C_amd64.deb dpkg -i postgresql-client-common_154.1.1C_all.deb dpkg -i postgresql-common_154.1.1C_all.deb dpkg -i postgresql-client-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-contrib-9.4_9.4.2-1.1C_amd64.deb

    11.Готово. Дистрибутив СУБД PostgreSQL установлен.

    Установка дистрибутивов PostgreSQL-Pro

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

    sudo sh -c "echo "deb http:// 1c.postgrespro.ru/deb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/postgrespro-1c.list" wget --quiet -O - http:// 1c.postgrespro.ru/keys/GPG-KEY-POSTGRESPRO-1C-92 | sudo apt-key add - && sudo apt-get update sudo apt-get install postgresql-pro-1c-9.4

    Для доступа к серверу редактируем параметры в файле pg_hba.conf

    сd <Путь до каталога pg_hba.conf> cp pg_hba.conf pg_hba.conf.old bash -c "echo "local all postgres trust" > pg_hba.conf" bash -c "echo "host all all all md5" >> pg_hba.conf"

    Сам файл имеет следующую структуру:


    Файл хорошо документирован, но на английском языке. Кратко рассмотрим основные параметры:

    • Local локальное подключение только через unix
    • Host подключение по TCP/IP
    • Hostssl шифрованное SSL-подключение по TCP/IP (сервер должен быть собран с поддержкой SSL, также требуется установить параметр ssl)
    • Hostnossl нешифрованное подключение по TCP/IP
    • trust допустить без аутентификации
    • reject отказать без аутентификации
    • password запрос пароля открытым текстом
    • md5 запрос пароля в виде MD5
    • ldap проверка имени и пароля с помощью сервера LDAP
    • radius проверка имени и пароля с помощью сервера RADIUS
    • pam проверка имени и пароля с помощью службы подключаемых модулей

    Более подробную и развернутую информацию можно посмотреть в документации к продукту PostgreSQL.

    root@NODE2:/home/asd# service --status-all |grep postgres [ - ] postgresql root@NODE2:/home/asd# service postgresql start root@NODE2:/home/asd# service --status-all |grep postgres [ + ] postgresql

    После окончания основной установки, необходимо настроить конфигурационный файл сервера postgresql.conf, согласно специфики работы PostgreSQL, сервера 1С и конфигурации сервера Ubuntu.

    Оптимизация 1С под MS SQL Server

    Устанавливаем последние обновления для SQL Sever.

    Операционная система резервирует место и забивает его нулями, что занимает достаточно много времени при следующих событиях:

    • Создание базы данных;
    • Добавление файлов данных, журнал транзакций, к существующей базе данных;
    • Увеличение размера существующего файла (в том числе Autogrow-операций);
    • Восстанавливаем базы данных или группы файлов.

    Решается данная проблема добавлением роли (под которой запущен сервер) к пункту локальной политики безопасности «Выполнение задач по обслуживанию томов».

    При возможности необходимо разнести базу TempDB (особенно интенсивно она используется в режиме управляемых блокировок RCSI) и журнал транзакций на разные диски.

    На сервере, где работает SQL сервер, режим энергосбережения должен быть установлен в «Высокая производительность».

    В папке с файлами БД не должно быть сжатия.

    На вкладке «Память» для сервера устанавливаем минимальную планку в размере 50% от общего объема памяти. Максимальную рассчитываем по одной из формул:

    • Максимальная память = Общий объем – размер по ОС – размер под 1С (Если он есть, предварительно замерив счетчиками используемую память) или
    • Максимальная память = Общий объем – (1024* Общий объем/16384).

    Ограничиваем параметр DOP «Max degree of parallelism» и ставим его в значение «1».

    Актуализируем статистику по расписанию. Начиная с SQL Server 2008, обновление статистики вызывает перекомпиляцию запросов и, соответственно, очищает процедурный кэш, поэтому отдельную процедуру по очистке процедурного кэша выполнять не надо.

    Периодически проводим реиндексацию таблицы и дефрагментацию индексов.

    Устанавливаем правильную политику резервирования. Если вам не надо восстанавливаться на последний момент времени к краху системы, а последние минут 5 или больше для вашего бизнеса не критичны, то установите модель восстановления в «Простая». Этим вы ускорите в разы скорость при записи. Главное, чтобы дифференцированный бекап успевал выполняться за указанное время.

    Добиваемся улучшения при работе с TempDB при вводе/выводе посредством создания дополнительных файлов данных. Если логических процессоров меньше 8, рекомендуется создать файл данных для каждого логического процессора. Если логических процессоров больше 8, рекомендуется создать 8 файлов данных и, увеличивая на один при кратности 4, обязательно оценить нагрузку на TempDB.