ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Создайте свой функциональный интерфейс в любой конфигурации 1С с помощью расширения Infostart Dashboard.
Настраивайте панели виджетов с метриками, индикаторами и показателями на начальном экране.
Узнайте возможность внедрения подсистемы у себя в конфигурации с помощью бесплатной обработки "Анализ внедрения подсистемы 1С Infostart Dashboard"!
Обнаружили дубли номенклатуры в документах? Обработка поможет быстро найти все документы, где используется ошибочная номенклатура, выполнить анализ последствий и безопасно заменить ее на основную номенклатуру с контролем результатов и журналом выполненных операций.
Код не меняли год, а операция, которая раньше шла секунду, стала идти минуту. Виноват в таком обычно не код, а то, что данные перешли порог: у квадратичного алгоритма удвоение объёма стоит четырёхкратного роста работы, поэтому поломка не подкрадывается постепенно, а наступает сразу. В разборе - случай коллеги, где сервис деградировал месяц. Три объяснения закрыли замером, а развязку дал профиль на 16 642 снимках: 80,0 % процессорного времени в одной функции, которую при этом нельзя было чинить. Разогнали её 20 копий одного документа по 443 581 байту, наплодил их собственный экспортёр сервиса. Дальше - как отличить квадратичный рост от линейного двумя замерами, где такие места прячутся в коде 1С и что делать, если урезать боевую базу вдвое нельзя.
Платформа 1С давно вышла за рамки учетных систем. Сегодня это полноценная среда для создания сложных, высоконагруженных и распределенных приложений. А значит, и стек технологий современного разработчика кардинально изменился. Систематизируем весь инструментарий, который превращает 1С-программиста в инженера: от EDT и Git до автотестов на YAxUnit, контейнеризации приложений в Docker, мониторинга в Prometheus и организации шины данных на Kafka. Разберемся, зачем каждый инструмент нужен, как он вписывается в жизненный цикл разработки и с чего начать его внедрение.
Почему счётчики кластера не отвечают на вопрос и как спросить по-человечески. Подход вопрос вместо метрики, семь вопросов о нагрузке, и техника, без которой это не работает: зерно снимка агрегат, сетевой каталог для многоузлового кластера, определение своей базы по сеансу, версия RAS под сервер.
Мониторинг нагрузки кластера, который отвечает на человеческие вопросы: кто блокировал базу, кто грузил сервер, что было ночью. Диаграмма с именами людей вместо столбцов счётчиков. Штатный АдминистрированиеСервера, без rac.exe и COM, к СУБД не обращается. С регламентным сбором истории.
Три пакетных файла проверили на то, что они на самом деле возвращают.
Один сообщал об ошибке при успешном завершении, два возвращали ноль после провала. Мониторинг по кодам возврата на этой цепочке горел бы красным там, где всё хорошо, и молчал бы там, где работа не делалась тридцать пять дней.
Началось всё со скучной сверки расписания с журналом, а кончилось матрицей, в которой два шага из пяти стоят с нулём при шести прогонах из шести у соседей. Шаг, отработавший шесть раз, всё это время строил результат по срезу от десятого июня: сорок один день одних и тех же данных. Разбираю три механизма, каждый из которых превращал провал в зелёную строку отчёта, и почему единственная метрика, которая поймала бы всё сразу, - возраст данных внутри результата. Плюс честные границы: что после починки не замерили и какой вывод статьи на площадке так и не внедрили.
Мониторинг блокировок сам оказался старейшей открытой транзакцией в базе: сеанс спит, блокировок по нему ноль, транзакция висит четверо с половиной суток. Порог в его собственном запросе - пять секунд, свою транзакцию он продержал порядка восьмидесяти тысяч таких порогов и себя ни разу не заметил. Ни в один отчёт "кто кого блокирует" такой сеанс не попадает: никто никого не ждёт.
Это четвёртый из четырёх механизмов, разобранных в статье. Остальные три: один текст ошибки на две совершенно разные причины, из-за которого уходят в разбор графов вместо одной правки обработчика; кольцевой буфер диагностики, обнуляемый переключением основного узла; события, записанные под чужим именем базы, из-за чего запрос отдаёт ноль строк там, где данные лежат.
По каждому разобрано, как он выглядит, чем отличается от настоящей пустоты и что с ним делать.
