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

Что это за СУБД
PostgreSQL - бесплатная СУБД. Прелесть системы управления базами данных PostgreSQL для 1С:Предприятие 8 в работе как под Windows, так и под Linux.

Причины начать использовать PostgreSQL прямо сейчас:
1. Экономия: никакой платы за лицензию. Вы платите только за внедрение, поддержку PostgreSQL и развитие вашей системы.
2. Производительность: в PostgreSQL используются инновационные решения, позволяющие вашему приложению сравняться решения на основе коммерческих СУБД, а в некоторых операциях даже быстрее.
3. Надежность и Качество: техническая поддержка на русском языке, быстрая реакция на найденные проблемы, отличная производительность, открытый исходный код СУБД

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

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

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

«Классический» «Индивидуальный» «Бизнес» «Круглосуточный»
Цена, руб. * 29 900 ₽ 87 900 ₽ 187 000 ₽ 299 000 ₽
Предоплаченное время, ч 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С под Linux и Windows http://www.postgrespro.ru/products/1c_build

Мы сами используем PostgreSQL

Процессор

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

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