1C в облаке: аудит производительности, ныряем глубже

Анжелика Захарова. K2 Cloud и DigiLabs предлагают совместную услугу — регулярный технический отчет о состоянии системы 1С, реализованный на базе ПО Алькир, программного продукта, предназначенного для комплексного решения проблем производительности конфигураций на платформе 1С.

Мы предлагаем:

• экспресс-аудит производительности системы 1С,
• регулярный аудит технического состояния 1С.

Такая последовательность проведения аудитов производительности является best practice. Первый этап (экспресс-аудит) позволяет

• оценить состояние системы в первом приближении,
• выявить проблемные зоны с точки зрения производительности.

Регулярный технический отчет дает возможность

• иметь актуальные данные о состоянии системы,
• отслеживать динамику изменений,
• оперативно реагировать на возникающие проблемы.

Согласно принципу Парето, такая комбинация аудитов дает 80% результата при 20% затраченных усилий.

Иван Груздов. Два формата проверки в нашей методике аудита разработаны на основе практического опыта. Хотя единой отраслевой классификации не существует, мы выделили эти типы аудитов, исходя из индивидуальных потребностей клиентов.

Экспресс-аудит представляет собой базовую проверку с использованием ПО Алькир. Опыт проведения аудитов и работы с Алькир позволил нам существенно сократить затраты на аудит, сохранив при этом возможность выявления и локализации наиболее частых и критичных проблем производительности.

Экспресс-аудит включает

• аудит сервера 1С, в том числе анализ параметров кластера 1С, стабильности работы серверов и потребления ресурсов серверами 1С;
• анализ параметров сервера СУБД, которые могут стать причиной снижения производительности;
• аудит ключевых операций для выявления наиболее проблемных с точки зрения APDEX;
• анализ происшествий для подготовки сводки – списка ошибок и предупреждений за анализируемый период, сгруппированных по типам и степени критичности, которые
  - необходимо срочно проверить,
  - можно посмотреть,
  - на самом деле ошибками не являются, но фиксируются в системе как ошибки в силу особенностей технического журнала;
• анализ ожиданий на блокировках 1С для вывода областей, пользователей и контекста, которые наиболее часто являются участниками блокировок;
• анализ ресурсоемких операций и операций с аномальной длительностью, которые привели к высокой утилизации ресурсов серверов 1С и СУБД.

Важно отметить, что данный анализ выполняется не только на основе событий технологического журнала, но и с привлечением дополнительных данных из журнала регистрации. Такой расширенный подход, объединяющий информацию из нескольких источников по определенной логике, существенно повышает детализацию и точность проводимого анализа

Регулярный аудит служит инструментом контроля стабильности работы системы. Его ключевая задача — выявление изменений по сравнению с предыдущим периодом. Именно поэтому в требованиях указана необходимость предоставления результатов прошлого аудита.

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

Для хранения данных ПО Алькир использует СУБД ClickHouse, что позволяет сжимать объем логов примерно в 10-11 раз. Благодаря этому мы можем

• хранить полные логи работы системы за продолжительный период;
• иметь точную статистику за весь срок наблюдений;
• при необходимости возвращаться к анализу конкретных событий, произошедших даже несколько недель назад.

Регулярные аудиты выполняются после проведения экспресс-аудита. В рамках регулярного аудита мы даем оценку изменений: какие показатели ухудшились, какие остались на прежнем уровне, а какие показали улучшение.

Анжелика Захарова. Итак, ключевые метрики, которые анализируются в рамках аудита, включают

• корректность настроек 1С,
• корректность настроек СУБД,
• показатели индексов (APDEX),
• ресурсоемкие вызовы 1С,
• ресурсоемкие запросы СУБД,
• ожидания на блокировках 1С,
• ожидания на СУБД,
• использование лицензий,
• сеансы работы,
• ошибки при работе системы,
• изменения размеров базы данных и таблиц,
• анализ достаточности свободного места.

Как показал опрос аудитории митапа, при оценке производительности основное внимание сосредотачивается на ресурсоемких вызовах 1С и запросах к базе данных, которые и являются самой частой причиной проблем.

Условия оказания услуги

Анжелика Захарова. Новая услуга реализуется по сервисной модели из К2 Облака. В рамках услуги мы

• разворачиваем ПО Алькир,
• готовим облачное окружение по инструкциям DigiLabs,
• настраиваем сетевую связанность и интеграцию с системой 1С заказчика.

При итогам экспресс-аудита заказчик получает отчет о текущем техническом состоянии 1С с актуальными данными о здоровье системы. Все данные хранятся в актуальном состоянии на протяжении длительного времени.

В процессе формирования отчета специалист проводит детальный анализ собранных данных, после чего готовит отчет с практическими рекомендациями, которые заказчик может применить самостоятельно.

Ключевыми преимуществами экспресс-аудита являются

• оперативность выполнения работ,
• высокая точность анализа благодаря детализации данных о собираемых событиях.

Это решение позволяет существенно экономить временные и финансовые ресурсы, исключая привлечение сторонних специалистов.

Регулярный аудит проводится ежемесячно или ежеквартально и дает возможность сравнивать показатели производительности с предыдущими периодами. Такой подход позволяет не только выявлять случаи деградации производительности, но и фиксировать периоды стабильной работы и точно определять проблемные временные промежутки.

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

Основная ценность проведения аудита заключается в комплексном решении трех ключевых задач:

• заблаговременного выявления проблем производительности,
• постоянного мониторинга состояния системы и контроля изменений,
• доступа к профессиональной аналитике без значительных капитальных затрат.

Такой подход позволяет не только оперативно реагировать на возникающие проблемы, но и предотвращать их появление за счет превентивного анализа.

Зачем проводить аудит 1С

Иван Груздов. Если вы хотите что-то контролировать — это нужно измерять: нельзя быть уверенным, что худеешь, без весов, нельзя быть уверенным, что не превышаешь скорость, без спидометра. Точно так же невозможно оценить состояние системы без регулярного мониторинга. Аудит — это именно тот инструмент, который позволяет держать руку на пульсе.

Это особенно актуально для компаний, которые используют на платформе 1С системы уровня business critical, неработоспособность которых может привести к реальным бизнес-проблемам. Например, если логистика реализована на 1С, при зависании системы может остановиться весь процесс отгрузки, сотрудники будут простаивать, а компания понесет существенные убытки.

Аудит может быть полезен и при планировании миграции. Анализ производительности системы до миграции позволяет

• объективно оценить потенциальные риски перехода,
• выявить и устранить существующие проблемы,
• получить базовые показатели для сравнения после миграции.

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

Регулярный аудит выполняет несколько критически важных функций.

Во-первых, он позволяет контролировать выполнение рекомендаций, полученных после разового аудита. На практике изменения либо не вносятся вовсе, либо реализуются не в полном объеме, либо выполняются упрощенным способом, отличающимся от рекомендованного. Регулярный мониторинг как раз дает возможность отслеживать эффективность внедренных изменений.

Во-вторых, важно понимать, что ИТ-системы не статичны, они постоянно изменяются, причем эти изменения часто вносятся разными командами без должной координации: инфраструктурные специалисты могут изменять конфигурацию серверов, служба информационной безопасности добавляет свои фильтры и ограничения, разработчики внедряют новые функциональные модули и т.д.

Например, мы регулярно сталкиваемся с ситуациями, когда разработчики используют специализированные консоли запросов сомнительного качества для анализа планов выполнения, и после завершения работы с такими инструментами технологический журнал часто не возвращается в исходное состояние и продолжает собирать планы запросов, что существенно снижает производительность системы.

Регулярный аудит позволяет выявлять подобные изменения до того, как они приведут к критическим последствиям. Наше решение обеспечивает особенно точный анализ благодаря

• хранению данных за 30-дневный период,
• автоматизированной обработке всей накопленной информации.

Анжелика Захарова. Причиной миграции новых заказчиков на новую платформу часто бывает типичный набор проблем, многие из которых связаны с отсутствием регулярного контроля за состоянием системы.

По результатам опроса аудитории митапа, большинство проводят аудит для решения двух основных задач: повышения производительности и выявления узких мест для превентивного реагирования.

Рассмотрим несколько кейсов аудита производительности 1С.

Кейс 1. Обновление статистики в MS SQL

Иван Груздов. Мы осуществляем постоянный мониторинг количества изменений в данных, необработанных статистикой, с визуализацией этих показателей на графике.

• До 24 ноября система работала стабильно: днем накапливались изменения в данных, а ночью специальный скрипт корректно обновлял статистику, хотя и делал это через полное сканирование (full scan), что не всегда является оптимальным решением.
• После 24 ноября статистика перестала обновляться полностью, причем процесс деградации был постепенным. Автообновление статистики в SQL Server маскировало проблему, поэтому резкого падения производительности не наблюдалось.

При детальном анализе выяснилось, что обновление выполнялось скриптом open source с поддержкой остановки по тайм-ауту. Администратор правильно настроил прерывание процесса обновления в начале рабочего дня. Однако при утреннем завершении по тайм-ауту в логах СУБД операция отмечалась как успешно выполненная. Администраторы видели статус «успешно» и не фиксировали проблему, хотя она была – по части таблиц статистика не обновлялась.

Благодаря регулярному аудиту через ПО Алькир мы

• заметили аномалию на графике накопления необработанных данных;
• предложили необходимые корректировки параметров выполнения задания.

Команда DBA заказчика доработала скрипт с учетом наших рекомендаций, что помогло предотвратить массовую генерацию неоптимальных планов запросов и восстановить стабильную работу системы.

Этот случай наглядно показывает, как регулярный аудит помогает выявлять скрытые проблемы, которые не проявляются сразу в виде явных ошибок, могут быть замаскированы другими механизмами системы, накапливаются и потенциально приводят к серьезным последствиям.

Кейс 2. Неравномерное распределение сеансов

Иван Груздов. При мониторинге кластера из двух аппаратно-идентичных серверов 1С мы обнаружили существенный дисбаланс в распределении нагрузки. Статистика показывала, что сервер 2 принимал в среднем в два раза больше соединений (70-150), чем сервер 1 (0-90), несмотря на одинаковую конфигурацию оборудования.

Для диагностики проблемы мы выполнили комплексный анализ, начав с проверки параметров кластера. В кластере использовался режим распределения нагрузки по доступной производительности. Этот механизм регулярно определяет доступную производительность процессов кластера, выполняя стандартные операции и измеряя их скорость. Анализ этих тестовых замеров показал, что сервер 1 демонстрировал значительно более низкую доступную производительность (138 условных единиц по сравнению с 210-220 у сервера 2).

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

Мы разработали специальные тестовые сценарии, которые позволили воспроизвести проблему, и передали данные специалистам по инфраструктуре. Таким образом, удалось локализовать проблему и выровнять нагрузку между серверами.

Кейс 3. Анализ ключевых операций

Иван Груздов. При исследовании проблем производительности мы применяем методологию анализа ключевых операций, двигаясь от общего к частному. Такой подход позволяет избежать ошибочных выводов, которые могут возникнуть при изучении единичных замеров, поскольку одна и та же операция может выполняться с разной скоростью по различным причинам.

На первом этапе строится график распределения длительности операций (отношения длительности замеров к их количеству), и, судя по первому графику, основная масса операций выполняется за 5 секунд и наблюдаются отдельные пики на 10 и 14 секундах. Второй график представляет собой развернутый анализ временных затрат для различных типов нагрузки при разных длительностях выполнения операции. Для наиболее распространенного диапазона (4-6 секунд) распределение временных затрат выглядит следующим образом:

• около 30% общего времени занимает непосредственно обработка процессором сервера 1С;
• 30% приходится на операции сервера, не связанные с процессорной нагрузкой (преимущественно работа с памятью и дисковыми операциями);
• 30% времени операции уходят на ожидание управляемых блокировок в 1С.

Такой анализ позволяет сделать несколько важных выводов.

• Влияние SQL-запросов на общую производительность минимально – их оптимизация не даст существенного эффекта.
• Для длительных операций (свыше 13 секунд) проблема ожидания блокировок отсутствует. Это означает, что если бы мы анализировали только самые длительные операции (20 секунд), то пропустили бы проблемы с ожиданиями на блокировках, которые надо устранять в первую очередь, так как они оказывают существенное влияние на большую часть замеров.

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

На этом этапе анализа мы:

1. Построили дерево блокировок для конкретного замера времени, которое в данном случае включало две транзакции. Важно отметить, что система поддерживает построение дерева, включающего все транзакции, которые влияют на ожидание.

2. Для каждой транзакции в отчете отобразили

   • длительность серверного вызова (первая строка),
   • общую длительность транзакции (вторая строка),
   • длительность удержания блокировки (третья строка).

3. Использовали цветовую маркировку статусов:

   • зеленый (успешные транзакции),
   • красный (транзакции, завершившиеся ошибкой, включая отмененные транзакции),
   • желтый (интервалы ожидания блокировок).

В исследуемом случае мы наблюдали следующую ситуацию.

• Ожидание блокировки продолжительностью около 5 секунд (желтый участок).
• Последующее получение блокировки (короткий зеленый участок, едва заметный на графике).
• Итоговый откат транзакции после выполнения проверки.

Полученный отчет содержит

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

Эта информация позволяет разработчикам

1. оценить корректность использования блокировок,
2. выявить избыточные блокировки,
3. определить оптимальные пути оптимизации.

Анжелика Захарова. Эти кейсы позволяют выделить два принципиально важных аспекта работы ПО Алькир.

1. ПО Алькир — единственный инструмент, осуществляющий комплексный мониторинг всех компонентов системы 1С. Это уникальная возможность, позволяющая получить полную картину работы системы.
2. Особую ценность представляет способность ПО Алькир читать и анализировать операции с минимальной длительностью выполнения (от 0,1 сек).

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

Высокая производительность системы позволяет анализировать на порядок больше событий по сравнению с инструментами, работающими только с длительными операциями. Например, при установке фильтра на события от 0.1 секунды количество фиксируемых операций увеличивается в 5–10 раз по сравнению с фильтром от 1 секунды. Это существенно повышает точность анализа, так как система учитывает большее количество факторов, влияющих на производительность.

Эффективность хранения и обработки данных в ПО Алькир обеспечивает высокую детализацию отчетов. Например, графики распределения длительности операций становятся значительно информативнее при работе с полным спектром событий, включая кратковременные.

Обнаружит ли ПО Алькир проблемный участок кода или запрос, если он будет в цикле?

При проверке такие участки кода и запросы отслеживает аудитор, а в ПО Алькир отдельный функционал для этого отсутствует. Однако инструмент фиксирует все запросы, включая кратковременные (от 0,1 секунды), и анализирует паттерны их выполнения, поэтому в большинстве случает позволяет отследить проблемы.

Связь работает в автоматическом режиме: мы получаем события о больших задержках, проверяем запросы к СУБД и затем анализируем технологический журнал?

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

ПО Алькир (не аудит) поддерживает сбор любых событий и свойств технологического журнала за счёт того, что внутренняя структура хранения динамически адаптируется под данные, считанные из технологического журнала.

Кроме того, можно перейти к событиям технологического журнала от замеров времени по такой же логике. При этом автоматически устанавливается отбор по

• имени пользователя,
• номеру сеанса,
• дате начала и завершения операции.

Может ли система давать рекомендации, например, о том, что дисковая система работает медленно?

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

Существуют ли ограничения по целевой анализируемой инфраструктуре в зависимости от СУБД? Например, можно ли с помощью ПО Алькир провести аудит для решений 1С, развернутых на РЕД ОС плюс Postgres Pro Enterprise?

ПО Алькир разворачивается независимо от операционной системы. Поскольку серверы Алькир располагаются отдельно от продуктивных серверов и получают доступ к необходимым данным по сети, то требований к ОС, на которой развернуты компоненты исследуемой системы, нет. Если говорить не об ограничениях, а об особенностях, то стоит учитывать, что MS SQL и PostgreSQL идеологически сильно отличаются и используют разные подходы. Поэтому некоторые методы анализа, доступные для одной СУБД, могут быть недоступны для другой. Например, определенные виды статистики, такие как графики производительности для MS SQL, нельзя построить для PostgreSQL. Однако вместо них можно использовать другие метрики и способы визуализации.

Таким образом, результаты и методы аудита различаются в зависимости от типа СУБД.

Каким образом удалось установить связь между замерами ключевых операций и данными из технологического журнала?

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

1. имя пользователя,
2. номер сеанса,
3. дата выполнения ключевой операции замера (с точностью до миллисекунд).

Для корректной работы механизма необходимо, чтобы время на клиентской машине и сервере было синхронизировано. Если замеры выполняются «правильно» (т. е. начинаются и завершаются на клиенте), но системное время клиента и сервера расходится, процесс связывания данных может работать некорректно.

Выявляются ли слабые места в работе с PostgreSQL?

Да, система выявляет проблемные места при работе с PostgreSQL: анализирует и фиксирует проблемные запросы и собирает профили этих запросов.

При этом мы проверяем настройки сервера PostgreSQL и сверяем их с показателями выделенных ресурсов.

Как проводится анализ в других облаках?

Мы проводим анализ технического состояния систем 1С и работы в облачных средах. Услуга предоставляется из К2 Облака, при этом предварительно настраивается сетевая связанность с местом расположения системы 1С заказчика.

Место физического размещения анализируемой системы 1С (облако или локальная инфраструктура заказчика) не имеет принципиального значения для проведения анализа.