Skip to content

Оптимизация подсистемы бюджетирование в Управлении холдингом ред. 1.3. часть №1: Оборудование

Наш проект по внедрению системы управленческого и регламентированного учета на базе решения «Управление холдингом редакции 1.3» перешел во второй этап. Десяток баз под управлением Бухгалтерии предприятия 2.0 заменила единая информационная система. Осталось дело за малым, перенести бюджетную модель из Excel и в подсистему «Бюджетирование». В Excel заказчик вел очень детальные бюджеты и не намерен отказываться от своей привычки, даже наоборот, рассчитывает увеличить детализацию с помощью автоматизированной системы. Холдинг состоит из трех десятков филиалов, средний размер планового БДР у которых составляет примерно 1000 строк в детализации до (ВНИМАНИЕ!) 12 аналитик планирования. Планирование ведется с точностью до клиентских договоров и учитывая размер клиентской базы, а также обороты холдинга, фактические бюджеты будут измеряться десятками тысяч. Все это означает, что типовую конфигурацию ждет самый настоящий стресс тест и без оптимизации просто не обойтись. Свою серию публикаций о тюннинге Управления холдингом 1.3 (в части бюджетирования) хочу начать с рассказа о подготовительном процессе и работах предшествовавших внедрению.

Учитывая объем работ, который предстояло выполнить и сроки, в которые, было необходимо уложиться, нашей первоочередной задачей являлась организация рабочего процесса. Для того, чтобы квалифицированные специалисты могли выполнять «максимум работы в единицу времени» требовалось задействовать все доступные технические и программные средства.

Конфигурация Управление холдингом занимает около 1 гигабайта, поэтому можно представить себе сколько программного кода и интерфейсов в ней сосредоточено. Если принять во внимание особенности проекта и функциональной модели конфигурации, а именно:

  • Заказчиком была заявлена необходимость оперативного обновления на новые релизы Управления холдингом, для целей поддержки регламентированного учета. Это обстоятельство исключает возможность сокращения объема конфигурации, за счет снятия ее с поддержки.
  • Расчетные бюджеты должны формироваться с использованием типового функционала, который позволяет настраивать правила расчетов в пользовательском режиме. Часть форм ввода данных должна быть реализована при помощи типового инструмента «Сводная таблица». Учитывая тот факт, что заказчиком используются бюджетные классификаторы, состоящие из сотен статей – интерфейс при помощи которого выполняется настройка формул, а также интерфейс «Сводной таблицы» будет работать под высокой нагрузкой.

Становится очевидно, что производительность труда внедренцев напрямую зависит от:

  • Мощностей оборудования: необходимо развернуть ландшафт на базе комплектующих, которые могли бы обеспечить максимальную производительность и обеспечить эффективное использования ресурсов оборудования путем корректной настройки программного обеспечения.
  • Скорости работы типового функционала «Управления холдингом»: архитектору необходимо подготовить типовую конфигурацию таким образом, чтобы часто используемый функционал работал с максимальной производительностью. Очень важно начать внедрение блока «Бюджетирование» именно с этих работ, т.к. большая часть настроек бюджетной модели выполняется в пользовательском режиме. Поэтому в ходе настройки (и тестирования) специалисты постоянно будут работать со «Сводной таблицей» и перенастраивать расчетные формулы. Чем больше времени они будут тратить на ожидание, тем дольше заказчик будет ждать результатов.

Настройка ландшафта

Любую техническую проблему можно решить, имея достаточно времени и денег (закон Лермана)

В выборе серверных комплектующих, основным сдерживающим фактором являлся бюджет. По этой причине было принято решение использовать в качестве сервера «настольный компьютер».

Выбор процессора

Большая часть операций, выполняемых программистами в конфигураторе, задействует одно ядро процессора. Поэтому, чем выше тактовая частота процессора, тем выше производительность труда технического специалиста. Выбор пал на процессор Intel® Core™ i7-6700K с тактовой частотой 4.0GHz.

Процессоры для настольных компьютеров уступают серверным в части масштабируемости, но в связи с тем, что ландшафт предназначался только для проектной команды внедрявшей блок бюджетирования, ресурсов i7-6700K было достаточно. На начальном этапе внедрения подсистемы, размер проектной команды варьировался от 6 – 8 человек, поэтому 4’рех физических процессорных ядер (или восьми логических в режиме hyper-threading) было достаточно для обеспечения комфортной работы.

В процессе тестирования компьютера были приняты решения:

  • О целесообразности «разгона» тактовой частоты процессора и оперативной памяти.
  • Об отключении технологии TPU (материнская плата Socket 1151 ASUS «Z170-A»), приводившей к регулярным зависаниям компьютера (требовавшим отсоединения-присоединения батарейки).

Выбор архитектуры

В качестве серверов 1С предприятия, СУБД и терминального использовался один компьютер:

  • Средства виртуализации не использовались.
  • Было установлено 32 гигабайта оперативной памяти.

Выбор дисковой системы

Для хранения файлов операционной системы, файлов сервера 1С, баз данных использовался твердотельный дисковый накопитель SSD Intel 750 Series (PCI-Ex4). Учитывая небольшой объем и достаточно высокую стоимость диска, было принято решение:

  • Использовать модель резервного копирования (баз данных) «Simple». Журнал транзакций разместить на менее производительном диске и использовать технологию DELAYED DURABILITY (https://sqlperformance.com/2014/04/io-subsystem/delayed-durability-in-sql-server-2014), появившуюся в Microsoft SQL Server 2014.
  • Для баз, с которыми участники проектной команды не ведут активной работы (например, актуальные копии рабочей базы, использовавшиеся для анализа поступающих от пользователей заявок), применялась технология сжатия на уровне страниц (доступная в Enterprise и Developer версиях Microsoft SQL Server’а 2014). Сжатие позволяло уменьшить размер баз на 35-40%

Настройка программного обеспечения

Microsoft SQL Server был настроен в соответствии с рекомендациями компании «1С»: https://its.1c.ru/db/metod8dev#content:5904:hdoc:_top

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

00:00.410000-0,CLSTR,0,process=rmngr,p:processName=ServerJobExecutorContext,Event=process unavailable,Host=a-serv,Port=1560,Reason=ConnLimit,ConnLimit=128
00:00.410001-0,CLSTR,0,process=rmngr,p:processName=ServerJobExecutorContext,Event=process unavailable,Host=a-serv,Port=1561,Reason=IBLimit,IBLimit=1

После установки параметров перезапуска рабочих процессов:

Проблема разрешилась. Значение допустимого объема памяти было подобрано опытным путем.

Модернизация ландшафта

После согласования ЧТЗ (и начала разработки) интенсивность проектных работ начала стремительно расти. Необходимость проведения модернизации возникла, когда:

  • Объем проектной команды увеличился до 10 — 12 специалистов;
  • Размер базы данных превысил 20 гигабайт.

В рамках модернизации было принято решение закупить компьютер со следующими характеристиками:

  • ЦП: Intel® Core™ i7-7700K 4.2 GHz
  • ОЗУ: 64 GB
  • СХД: Samsung SSD 960 PRO 1TB
  • Материнская плата: Socket 1151 ASUS Z270-P

Для использования в качестве терминального сервера.

Роль изначально приобретенного компьютера была пересмотрена. Мы решили применять его в качестве сервера приложения 1С и СУБД. С течением времени была выполнена замена следующих комплектующих:

  • ЦП обновлен на Intel® Core™ i7-7700K 4.2 GHz
  • Объем ОЗУ расширен до 48 GB
  • Добавлены диски:
    1. Samsung SSD 960 PRO 512GB
    2. Intel® Optane™ SSD DC P4800X 375GB

В связи с расширением объема дискового пространства было принято решение:

• Операционную систему, файлы сервера 1С и служебные базы SQL Server разместить на диске Intel® Optane™ SSD DC P4800X.
• Для хранения пользовательских баз данных и журналов транзакций использовать диски Samsung SSD 960 PRO и SSD Intel 750 Series.
• Отказаться от сжатия баз данных средствами СУБД для целей ускорения операций ввода вывода и максимального повышения производительности труда участников проектной команды.

Удовлетворенность оборудованием

Мы тратили на модернизацию все имеющиеся в нашем распоряжении финансы, тем не менее постоянно сталкивались с нехваткой ресурсов. Невозможность выполнить апгрейд приходилось компенсировать тюннингом системы. Например, для снижения утилизации процессора мы отказались от использования функции сжатия баз данных на уровне страниц. После чего были вынуждены уже бороться уже с нехваткой свободного места. Переход на диски со «шпинделями» приводил к заметному снижению производительности абсолютно всех операций, по этому был недопустим. Только переработка архитектуры таблиц конфигурации позволяла нам разместить базы на твердотельных дисках. Желание работать с комфортом в рамках ограниченных ресурсов (оборудования), вынуждало нас совершенствовать систему постоянно, уделяя этому свободное от работы время.

Подводя итоги, хочу сказать, что описанная выше конфигурация оборудования повысила производительность труда нашей проектной команды процентов на 15-20% (моя субъективная оценка) внеся важнейший вклад в итоговый результат. Тем не менее мы регулярно сталкивались с нехваткой мощностей, решать которую частенько приходилось тюннингом алгоритмов и архитектуры конфигурации. Подробнее об оптимизации подсистемы «Бюджетирование» в Управлении Холдингом я расскажу в следующих публикациях.

Разделы «Модернизация ландшафта» и «Удовлетворенность оборудованием» в последний раз обновлялись 20.04.2018

Be First to Comment

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *