Настройка и аудит 1С на базе PostgreSQL

Помогаем мигрировать на PostgreSQL и снижать стоимость владения 1С
В результате опыта работ нашей компании с продуктами 1С на базе PostgreSQL мы представляем нашу услугу — экспертную помощь в организации работы 1С на СУБД PostgreSQL. Сотрудники нашей компании готовы произвести работы, связанные с администрированием СУБД PostgreSQL, а также анализ эффективности и производительности кода 1C:Предприятие под PostgreSQLМы поможем вам научиться эффективно использовать PostgreSQL и снизить расходы на покупке лицензий СУБД.

Крупному бизнесу
Если вы крупный бизнес и на первом месте для вас стоят вопросы надежности и возможность со своими проблемами обратиться к вендору, то для вас есть коммерческая редакция Postgres Pro Enterprise.
Покупая Postgres Pro Enterprise вы получаете решение, ничем не уступающее по возможностям аналогичным системам, таким как Oracle Database.

Поддержка 1С

Необходимые для работы платформы 1С патчи входят в состав Postgres Pro Enterprise. Кроме того, для ускорения работы 1С нами разработаны улучшения, прежде всего связанные с оптимизацией работы с временными таблицами. Эти улучшения также включены в Postgres Pro Enterprise, и благодаря им производительность при работе с 1С заметно повышается и на наших тестах превышает производительность 1С на других СУБД.

Компания 1С подтвердила совместимость платформы «1С:Предприятие 8» с российской СУБД Postgres Pro

Цены
Стоимость пакета услуг на 3 месяца

«Классический» «Индивидуальный» «Бизнес» «Круглосуточный»
Цена, руб. * 29 900 ₽
/ 3 месяца
87 900 ₽
/ 3 месяца
187 000 ₽
/ 3 месяца
299 000 ₽
/ 3 месяца
Предоплаченное время, ч 10 30 55 130
Web-, email-поддержка Да Да Да Да
Поддержка по телефону и skype Нет Да Да Да
Доступность 10:00 — 18:00 MSK, раб. дни 10:00 — 18:00 MSK, раб. дни 10:00 — 18:00 MSK, раб. дни 24×7
Резервная копия у тех. поддержки Нет Нет Нет Да
Постоянный аудит системы Нет Нет Нет Да
Шаблон договора Шаблон договора Шаблон договора

В рамках пакета мы поможем Вам смигрировать Вашу информационную систему из MS SQL Server на PostgreSQL. Стоимость каждого дополнительного часа работ, не вошедшего в пакет — 2000 руб.

Довольные клиенты

Ахметзянов Р.Р., RuSoft Projects:

Выражаем благодарность за помощь в восстановлении работоспособности СУБД Postgresql (9/6) на ОС CentoS, после внезапной остановки сервера.
Работа крупной торговой сети была остановлена из-за сбоя служб сервера с СУБД. Занания и опыт вашего сотрудника, который смог оперативно среагировать на наше сообщение, помогли обнаружить и устранить ошибки в работе…»

См. полный отзыв.

Кочетов Владимир Антольевич, ООО «Магазин 157»:

В рамках самих работ по аудиту удалось подобрать оптимальные настройки PostgreSQL, что позволило ускорить все проблемные операции до приемлемого времени выполнения. Например, время выполнения операции «формирование счет-фактуры в документе «Корректировка реализация» сократилось до 4х секунд (ускорение более чем 1200 раз), а время операции «регистрация счет-фактуры» сократилось до 2х секунд (ускорение более чем в 300 раз) за счет выбора более оптимальных планов запросов субд.»
См. полный отзыв.

Шаповалов Владимир, Спартамед:

При миграции учетной системы компании на СУБД PostgreSQL были выявлены проблемы производительности: ряд важных операций в базе 1С выполнялся неприемлемо долго…
Все поставленные задачи были успешно решены в короткие сроки:
— открытие интерфейса «Ежедневник врача» ускорено с 10-11 секунд до 1 секунды, то есть более чем в 10 раз.
— открытие интерфейса «Расписание клиники» ускорено с 5 секунд до 1 секунды, то есть в 5 раз;
— запись нового эталона на прием ускорена с 13 секунд до 1 секунды, то есть в 13 раз.»

См. полный отзыв.

Мельников Кирилл, Имкосервис:

Наша компания обратилась к команде профессионалов Gilev.ru за помощью в решении проблем с производительностью и стабильностью работы 1С при использовании СУБД PostgreSQL (сборка с сайта 1С) и ОС Linux (Ubuntu 14.04).
Специалисты компании провели миграцию на СУБД Postgres Pro для 1С и подобрали оптимальные настройки СУБД. Это помогло избавиться от проблем со стабильностью.»

См. полный отзыв.

Власов Игорь, ПТК ЮФ:

После сбоя в дисковой подсистеме стал недоступен кластер СУБД PostgreSQL, на котором находились все продуктивные базы 1С, и работа всей организации оказалась парализована.
От всей души хочу выразить огромную благодарность лично Вам и Вашим сотрудникам за оперативное решение нашей проблемы.»

См. полный отзыв.

Вячеслав Василенко, Вся Япония:

Несколько месяцев назад обратились за помощью с настройкой СУБД Psotgres в связке с сервером 1С на Windows Server 2012. Получили техническую поддержку на высоком уровне … получили сокращение основных операция в 3-5 раз. В некоторых случаях выполнение операция сократилось с 40 секунд до 3 секунд. Получили теперь уже много довольных пользователей.»
См. полный отзыв.

 

Как заказать и оплатить
Для того чтобы заказать услугу напишите на адрес Andrey@gilev.ru письмо и приложите реквизиты для оформления счета и договора.

 

Мы сами используем PostgreSQL
Наши собственные сервисы замеров загруженности оборудования, подбора оборудования, анализа неоптимиальных запросов работают под PosgresPro.
Суммарный объем баз составляет: 20 терабайт.
Количество пользователей сервисов: более 15 000.



Дистрибутив
Сборка PostgreSQL для платформы 1С под Linux и Windows http://www.postgrespro.ru/products/1c_build
выбирать версии дистрибутивов надо парно:
Postgres 9.4.х — 1С:Предприятие 8.3.6 или старше
Postgres 9.6.х — 1С:Предприятие 8.3.10 или старше
Postgres 10х — 1С:Предприятие 8.3.13 или старше
Мы предпочитаем дистрибутивы postgrespro а не с сайта 1С: потому что в дистрибутивы postgres pro входят все патчи фирмы 1С, т.е. данный дистрибутив уже не хуже дистрибутива с сайта 1С, но при этом туда входят исправления ошибок и улучшения, которые отсутствуют в дистрибутивах фирмы 1С. Надо понимать, что фирма 1С де факто берет устаревшие дистрибутивы как раз изначально у фирмы postgrespro.ru.

Кроме этого, мы не однократно на проектах наблюдали ситуацию, когда просто переход с дистрибутива 1С на дистрибутив фирмы Постгрес Профессионал давал значительный положительный эффект. Понятно что от версии к версии разница может колебаться, и тем не менее.
Мы вам предлагаем самостоятельно или с нашей помощью сначала перейти на такой дистрибутив. Если ситуация по производительности со сменой дистрибутива не изменится в лучшую сторону, то мы готовы помочь выполнить аудит системы. Вопросы можно присылать slava@gilev.ru

Заказать установку, настройку или аудит
Опытные сотрудники нашей компании готовы произвести различные работы, связанные с администрированием СУБД PostgreSQL и систем, построенных на её основе:
• установка, конфигурация, тонкая настройка PostgreSQL
• удалённое администрирование
• выбор оборудования решений любой сложности (архитектура системы, параметры «железа»)
• система мониторинга
• комплексное решение для предприятия (1C:Предприятие + PostgreSQL)
• гибкая система управления пользователями, группами пользователей и их правамиЕсли вы испытываете какие-либо трудности с эксплуатацией уже существующего решения, мы можем провести технический аудит с целью выявления проблем в таких вопросах как производительность системы, её надёжность, безопасность, качество данных, стоимость решения и пр. На основе проведённого анализа мы выработаем пакет рекомендаций, которые позволят вам улучшить ваш бизнес.
Аудит эффективности кода 1C:Предприятие под PostgreSQL
• Аудит загруженности серверов и всех ключевых метрик
• Аудит настроек СУБД

 

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

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

  Linux   Windows
если у вас есть свой опытный администратор у вас нет опыта с линуксом

Процессор

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 для <wbr />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   &lt; 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         &gt; =9.5
max_wal_size = 2 * min_wal_size    &gt; =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 будет обнулять число страниц/кортежей в таблице, которая не содержит никаких блоков в файле