APDEX для проведения документов упал до 0,57 при целевом времени пять секунд. Такой пример приводит методическая поддержка 1С. Число подтверждает жалобу пользователей, но не называет виновника.
Причина может скрываться в прикладном коде, блокировке, запросе к СУБД, диске или клиентской части. Чтобы не менять сервер наугад, разделите диагностику на три слоя: APDEX, технологический журнал и метрики инфраструктуры.
APDEX показывает, какая операция не укладывается в ожидания
APDEX сравнивает время пользовательской операции с целевым временем T. Порог задаёт бизнес: сервер не знает, сколько бухгалтер готов ждать проведения реализации.
Методика делит замеры на три группы. Операция до T получает полный вес, от T до 4T — половину, свыше 4T — ноль.
| Время операции | Класс APDEX | Вес в расчёте | Что видит администратор |
|---|---|---|---|
До T включительно | Удовлетворяет | 1 | Пользователь получил результат в согласованный срок |
От T до 4T | Терпимо | 0,5 | Операция заметно задержалась, но завершилась |
Более 4T | Раздражает | 0 | Пользователь ждал дольше допустимого |
| Нет замера | Не входит в расчёт | — | По операции нельзя судить без дополнительного измерения |
Из таблицы следует главное: оценка зависит не только от сервера, но и от выбранного T.
Посчитаем APDEX для 100 проведений. Пусть 70 документов провелись до T, ещё 20 заняли от T до 4T, а оставшиеся 10 превысили 4T.
Формула из методической поддержки 1С выглядит так:
APDEX = (NS + NT / 2) / NПодставляем исходные данные:
APDEX = (70 + 20 / 2) / 100 = 0,80Если число операций изменится, пересчитайте три группы. Сама формула останется прежней.
Порог T нельзя брать из характеристик процессора или диска. Сначала выберите пользовательскую операцию, затем согласуйте допустимое время с теми, кто её выполняет.
Для первого запуска можно взять опубликованные ориентиры стороннего проекта Fast1C: три секунды на открытие формы, пять — на проведение документа, десять — на отчёт, две — на запись элемента справочника. Это стартовые значения, а не норматив 1С. После недели наблюдений сопоставьте их с рабочими сценариями компании.
Не смешивайте разные операции в один показатель. Быстрое открытие формы способно скрыть медленное проведение, если первое происходит чаще.
Рабочее время и ночь тоже лучше считать отдельно. Иначе тяжёлые регламентные задания изменят общий график, хотя пользователи в этот момент не работают. Фоновые задания не относятся к пользовательскому опыту и не должны попадать в его APDEX.
Один APDEX не покажет, куда ушло время
Замер APDEX ставят внутри прикладной операции. Он знает начало и конец действия, например проведения реализации. ОС, СУБД и кластер 1С этих границ не видят.
Внешний замер серверного вызова тоже не заменяет APDEX. Он не охватывает клиентскую часть и может начинаться позже самой пользовательской операции.
| Вопрос администратора | Отвечает ли APDEX | Чем дополнить |
|---|---|---|
| Какая операция замедлилась | Да, если для неё настроен отдельный замер | Названием сценария и согласованным T |
| Когда началось отклонение | Да, по временному графику | Точным интервалом и жалобой пользователя |
| Задержал ли работу SQL-запрос | Нет | Техжурналом и анализом плана запроса |
| Ждала ли операция блокировку | Нет | Событиями платформы и данными СУБД |
| Тормозила ли клиентская часть | Не всегда | Замером внутри всей операции и наблюдением на клиенте |
| Хватало ли процессора, памяти и диска | Нет | Метриками ОС и хоста |
Замедлился ли конкретный rphost | Нет | Метриками кластера и рабочего процесса |
APDEX годится для поиска пострадавшей операции и интервала. Причину задержки он не локализует.
Не сравнивайте одно значение с чужой системой без контекста. Даже одинаковый T не гарантирует одинаковые границы замера, состав пользователей и набор операций.
Смотрите прежде всего на собственный тренд. Если проведение держалось около одного уровня, а после обновления график просел, у вас появился интервал для дальнейшего поиска.
Техжурнал восстанавливает события вокруг задержки
Официальная документация платформы 1С описывает технологический журнал как набор текстовых файлов. В него попадают сведения от клиентских и серверных приложений на конкретном компьютере.
Техжурнал нужен после того, как APDEX указал операцию и время отклонения. Вы берёте узкий интервал, находите события рядом с задержкой и восстанавливаете их последовательность.
События с длительностью помогают увидеть, на каком участке ушло время. Но одна длинная запись ещё не доказывает причину. Её нужно сопоставить с соседними событиями, жалобой пользователя, журналом регистрации и состоянием ОС.
| Ситуация | Что сопоставить по времени | Чего это ещё не доказывает |
|---|---|---|
Документ проводится дольше T | Начало замера, длительные события платформы, обращения к СУБД | Что серверу не хватает процессора |
| Сеанс периодически зависает | Повторяющиеся задержки, события клиента и сервера, состояние сети | Что проблема одинакова у всех пользователей |
| Рабочий процесс завершился | Последние события процесса, дамп, журнал ОС | Что сбой вызвала информационная база |
| Задержка появилась после изменения | Время изменения, первый провал APDEX, события до и после него | Что найденное совпадение означает причинную связь |
| Ночью выросло время заданий | Интервал задания, загрузку СУБД и хоста | Что пользователи испытывали ту же задержку днём |
Техжурнал даёт цепочку событий, но вывод появляется только после сверки нескольких наблюдений.
Журнал регистрации отвечает на другой вопрос. Он фиксирует действия пользователей и события информационной базы. Техжурнал описывает работу платформы и её компонентов. Для одного инцидента часто нужны оба.
Справочник кодов событий здесь не нужен. Без официального документа для вашей версии платформы чужая расшифровка создаст больше уверенности, чем оснований. Берите значения из документации к установленной версии 1С.
Подробный техжурнал включают на ограниченный срок
Файл logcfg.xml задаёт состав событий, каталог записи и срок хранения. Официальная документация 1С показывает конфигурацию с записью в отдельный каталог и хранением файлов в течение часа.
Полная запись всех событий без фильтров расходует место и добавляет нагрузку. Если журнал заполнит раздел, рабочие процессы могут остановиться. Поэтому системный диск — плохое место для подробного сбора.
Перед включением ответьте на три вопроса: какую операцию исследуете, какой временной интервал нужен и какие события проверяют вашу гипотезу. Формулировка «запишем всё, потом найдём» перекладывает отбор на момент, когда каталог уже заполнен тысячами записей.
Имя конфигурационного файла должно быть logcfg.xml. Корневой элемент — config, а параметры записи размещают в разделах log. Атрибут location задаёт каталог, history ограничивает срок хранения.
Проверьте синтаксис XML до переноса файла на рабочий сервер. В PowerShell это делает команда:
[xml](Get-Content "C:\1C\conf\logcfg.xml") | Out-NullКоманда без ошибки подтверждает только корректный XML. Она не проверяет имена событий, права на каталог, объём диска и соответствие конфигурации вашей версии платформы.
После применения убедитесь, что файлы появились в ожидаемом каталоге. Затем вызовите исследуемую операцию на контролируемом сеансе и проверьте, попал ли нужный интервал в журнал.
Срок хранения задавайте под длительность наблюдения. Час из примера документации 1С подходит для короткой диагностики, но не для сбоя раз в сутки. Для редкого события нужен другой срок либо внешняя система, которая забирает файлы до удаления.
Не оставляйте подробный сбор после диагностики. Сохраните найденный интервал отдельно, верните узкую постоянную конфигурацию и проверьте свободное место.
Метрики ОС, кластера и СУБД проверяют гипотезу
После чтения техжурнала у вас должна появиться проверяемая версия. Например: задержка совпала с ожиданием СУБД, рабочий процесс потерял доступную производительность или хост ждал диск.
Дальше смотрите на тот слой, который способен подтвердить эту версию. Метрики процессора не объяснят блокировку в СУБД, а график диска не покажет границы проведения документа.
Рабочие процессы rphost исполняют прикладной код и сами подключаются к базе. Отдельного процесса кластера для доступа к СУБД нет. Поэтому состояние rphost, хоста и СУБД нужно сверять на одной временной шкале.
Метрика available_performance отражает доступную производительность рабочего процесса и среднее время вызовов. Кластер рассчитывает её по периодическому эталонному вызову и усредняет результат за последние 5–10 минут.
Из-за усреднения короткий пик может сгладиться. Кроме того, показатель относительный: по нему нельзя сравнивать разные серверы или клиентов. Используйте его для наблюдения за одним рабочим процессом во времени.
| Наблюдение | Где проверять | Какой вывод допустим |
|---|---|---|
| APDEX просел у одной операции | Замеры внутри прикладного кода | Пострадал конкретный пользовательский сценарий |
| В техжурнале рядом есть длительное ожидание | Техжурнал и журнал регистрации | Найден участок для проверки, но не окончательная причина |
Изменился available_performance одного rphost | Метрики кластера | Состояние рабочего процесса отклонилось от его обычного уровня |
| В тот же интервал изменились метрики хоста | ОС и система мониторинга | Гипотеза о ресурсе получила подтверждение |
| СУБД показывает ожидание или блокировку | Средства мониторинга СУБД | Причину нужно искать в запросе, транзакции или конкуренции сеансов |
| Метрики всех слоёв спокойны | Границы замера и клиентская часть | Возможно, наблюдение не охватывает участок с задержкой |
Совпадение по времени сужает поиск. Причиной его делают повторяемость и проверка на подходящем слое.
Для Linux, серверных процессов 1С и PostgreSQL этот маршрут показан в материале о связке инфраструктурных метрик. Если 1С уже тормозит, используйте порядок проверки от сеанса до дисков, чтобы не перескакивать сразу к замене оборудования.
Не переносите пороги времени отклика диска из обсуждений сообщества как универсальную норму. Без документации производителя и условий замера такое число не учитывает тип накопителя, очередь, контроллер и характер нагрузки.
Схема мониторинга на ближайший день
Начните с двух-трёх операций, по которым пользователи чаще замечают задержки. Для каждой задайте собственный T и отдельный APDEX. Опубликованные ориентиры используйте только до согласования с пользователями.
Дальше настройте одинаковую временную шкалу для APDEX, техжурнала и метрик инфраструктуры. Часы на серверах и рабочих станциях должны показывать сопоставимое время, иначе события одного инцидента разъедутся по разным минутам.
Рабочая последовательность выглядит так:
- Зафиксируйте пользовательскую операцию и её границы.
- Согласуйте
Tи разделите рабочее время с ночным. - При снижении APDEX запишите операцию и точный интервал.
- Включите отфильтрованный техжурнал на срок наблюдения.
- Сопоставьте события с журналом регистрации и жалобой пользователя.
- Проверьте гипотезу метриками кластера, ОС или СУБД.
- После диагностики отключите подробный сбор и проверьте место на диске.
После настройки проведите контрольную операцию. На графике должен появиться её замер, в техжурнале — нужный интервал, а инфраструктурные метрики должны открываться на той же временной шкале.
Правило для дежурного администратора короткое. APDEX отвечает, когда и кому стало медленно. Техжурнал показывает, что происходило в этот момент. Метрики ОС, кластера и СУБД подтверждают компонент или ресурс. Ни один слой не заменяет два остальных.