Настройка и аудит 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 руб.
 
 

Довольные клиенты
Шаповалов Владимир, Спартамед:

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

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

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

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

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

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

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

Дистрибутив
Сборка PostgreSQL для платформы 1С под Linux и Windows http://www.postgrespro.ru/products/1c_build

Заказать установку, настройку или аудит
Опытные сотрудники нашей компании готовы произвести различные работы, связанные с администрированием СУБД 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 не является в полном смысле лимитом: оптимайзер может и промахнуться, и запрос займёт больше памяти, возможно в разы. Это значение можно уменьшать, следя за количеством создаваемых временных файлов:

<code><code>maintenance_work_mem = RAM/16..32 или work_mem * 4 или 256MB..4GB</code></code>
Лимит памяти для обслуживающих задач, например по сбору статистики (ANALYZE), сборке мусора (VACUUM), создания индексов (CREATE INDEX) и добавления внешних ключей. Размер выделяемой под эти операции памяти должен быть сравним с физическим размером самого большого индекса на диске.

effective_cache_size = RAM - shared_buffers

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

Диски

effective_io_concurrency = 2

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

random_page_cost = 1.5-2.0 для RAID, 1.1-1.3 для <wbr />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 секунды), но гарантирует целостность базы данных, в цепочке коммитов гарантированно отсутствуют пропуски. Но значительно увеличивает производительность.

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         > =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

commit_siblings = 5

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

Сеть

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

Ошибка СУБД: could not send data to server: No buffer space available (0×00002747/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

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

max_connections = 500..1000

Количество одновременных коннектов/сессий

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

standard_conforming_strings = off

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

escape_string_warning = off

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