Наверх

База знаний
Try 2 Fix
beta

Тюнинг PostgreSQL 9.4.2-1.1C для 1С:Предприятия 8.3: рельаный опыт настройки

Переход с файловой БД на PostgreSQL

Как только размер файловой базы данных 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, который идёт в архиве с дистрибутивом. Сами попались на это: не установили, испытали много боли.

Ставим всё на далее, далее, кроме следующих моментов. Устанавливаем, как сервис (галочка) и задаём параметры учётной записи Windows, не PostgreSQL.

1cpg1

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

1cpg2

Дальше ничего интересного. Далее…

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

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

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

2. Тюнинг PostgreSQL 9.4.2.

1cpg3

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

  • pg_hba.conf
  • postgresql.conf
  • pgpass.conf

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

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

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

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

1cpg4

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

  • 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_delay20ms. Время сна между циклами записи на диск фонового процесса записи. Данный процесс ответственен за синхронизацию страниц, расположенных в shared_buffers с диском. Слишком большое значение этого параметра приведет к возрастанию нагрузки на  checkpoint процесс и процессы, обслуживающие сессии (backend). Малое значение приведет к полной загрузке одного из ядер.
  • synchronous_commitoffОПАСНО! Выключение синхронизации с диском в момент коммита. Создает риск потери последних нескольких транзакций (в течении 0.5-1 секунды), но гарантирует целостность базы данных, в цепочке коммитов гарантированно отсутствуют пропуски. Но значительно увеличивает производительность.

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

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


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

Базы данных 1С можно публиковать на веб-серверах!


Остались вопросы?

Если в инструкции допущены ошибки или она Вам не помогла — пишите в нашу группу ВК! Мы обязательно поможем!

Или попробуйте найти интересующие Вас ответы в инструкциях на нашем YouTube канале!

Эти статьи будут Вам интересны

Декларант-Алко: Необрабатываемое исключение в приложении при запуске программы. Индекс за пределами диапазона.

Начиная с ОС Windows 7 после новой (чистой) установки программы Декларант-Алко начали возникать проблемы: при запуске программы появляется окно "Платформа Microsoft .NET Framework" с текстом "Необрабатываемое исключение в приложении..." и так далее (там много технического текста), а далее "System.ArgumentOutOfRangeException: индекс за пределами диапазона..." и ещё много текста (всё, как на картинке). После закрытия этого окна появляется окно выбора базы, но не пытайтесь, всё равно ничего не заработает. Исправляем эту беду.

Компьютер не включается. Простой способ проверки блока питания

Нажимаем на кнопку включения ПК - компьютер "не жужжит/не шумит" - достаточно часто мы слышим эти слова от наших клиентов. И в подавляющем большинстве случаев виноват в этом блок питания. Не удивительно - это, пожалуй, самая уязвимая часть ПК. Из-за постоянного нагрева и притока воздуха, блоки питания быстро забиваются пылью, перегреваются и выходят из строя. Как же убедиться, что проблема "мёртвого" ПК связаны именно с блоком питания?

Запуск программы от имени Администратора в Windows

Начиная с Windows Vista в линейке этой ОС появляется необходимость запускать некоторые  программы от имени Администратора. Лучше поздно, чем никогда: в Unix-подобных ОС работать с повышенными правами вообще не рекомендуется, для этого есть sudo. И да, с незапамятных времён. К слову в Windows XP и ниже это тоже можно было сделать, только вот это не требовалось, если у Вашей учётной записи уже есть права Администратора. Но содержимое файлов манифестов приложений изменилось навсегда и некоторое ПО без повышенных прав просто не заработает. А если Вы вздумали покопаться в системе или изменить реестр - без этого не обойтись. Начинаем.