Короткий ответ

Производительность 1С на SRV-1C / SQL01 проверяют замером в окне, не вечным «логировать всё». Снимите: время конкретной операции у конкретного пользователя, технологический журнал 8.3 (logcfg.xml) с фильтром по длительности/событиям EXCP/SDBL/DBMSSQL/CALL, параллельно wait stats и запрос на Accounting. Выключите ТЖ после окна. Не profiler навсегда.

Цель: доказать, SQL это, кластер, блокировка или клиент. Дальше — профильные статьи.

Симптомы и как отличить

Нужен замер, если:

  • «стало хуже после обновления»;
  • спор «это SQL / 1С / сеть»;
  • один отчёт.

Не замер, а авария: диск 0, Suspect, ragent Down.

Возможные причины «замеряли, но каша»

  1. ТЖ без фильтра, гигабайты за час.
  2. Замер в субботу, проблема в понедельник 9:00.
  3. Смешали две разные операции.
  4. ТЖ на клиенте, проблема на сервере (или наоборот).
  5. Часы SRV-1C и SQL01 разъехались.

Диагностика без ТЖ (быстрый срез)

С клиента: RTT до SRV-1C. На кластере: сеансы, «захвачено СУБД». На SQL — как в медленных запросах.

Зафиксируйте: пользователь, документ, длительность секундомером, CPU rphost, wait_type.

SELECT r.session_id, r.wait_type, r.wait_time, r.cpu_time, r.logical_reads
FROM sys.dm_exec_requests r
WHERE r.database_id = DB_ID(N'Accounting');

Решение: как снять замер

1. Сценарий операции

Одна операция (проведение реализации №…), один пользователь, час пик. Повтор 3 раза.

2. Технологический журнал на сервере

Каталог логов на томе с местом, не C: в ноль. Файл logcfg.xml в каталоге конфигурации платформы на SRV-1C (часто C:\Program Files\1cv8\conf\logcfg.xml — уточните для своей установки).

Пример минимального фильтра по долгим событиям (порог подберите, 1–3 сек для старта):

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1C_LOG\tj" history="4">
    <event>
      <ne property="Duration" value="100000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Duration в технологическом журнале 8.3 задаётся в десятках микросекунд (100000 ≈ 1 с). Проверьте актуальное описание вашей сборки и не копируйте порог слепо.

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

3. SQL в то же окно

Снимок waits до/после, Query Store, при необходимости XEvent с фильтром duration и database_id. Не «все statements».

4. Память и диск

max server memory, stall файлов, tempdb.

5. Клиент

Если ТЖ сервера чистый, а у пользователя долго — сеть, тонкий vs толстый, антивирус ПК, RDP.

Контур замера: протокол, который можно повторить через квартал

Заведите карточку: база Accounting, SRV-1C, SQL01, сборка 8.3, сценарий (документ, пользователь, время суток), длительность, wait_type, топ событий ТЖ, место логов ТЖ, включён ли был QS. Без этого следующий замер несравним.

Часы: NTP на обоих хостах. Иначе склейка ТЖ и SQL «по времени» врёт.

Не меняйте в окне замера одновременно max server memory, индексы и порог ТЖ. Один рычаг.

Клиентский замер: если склад на WAN, повторите сценарий с RDP на хосте рядом с SRV-1C. Если в RDP быстро, а с площадки нет — сеть, не SQL. Не оптимизируйте регистры из-за 80 мс RTT.

После релиза конфигурации храните «эталон» длительностей пяти операций. Регресс 2× — повод не катить прод, а не «пользователи привыкнут».

Диск ТЖ: отдельный том с квотой. Забытый logcfg.xml не должен уронить srvinfo и кластер. Алерт по свободному месту D:\1C_LOG.

Не публикуйте полные логи ТЖ с данными документов в открытый тикет внешней фирмы без NDA: там могут быть персональные данные и номенклатура.

Выключение: переименовать logcfg.xml в .off, подождать минуту, убедиться что файлы лога перестали расти. Оставить «на денёк» — типичный способ получить диск 0 к утру.

Как проверить, что проблема устранена

Повтор того же сценария: длительность, события ТЖ с меньшим Duration, wait_type. Цифры в заявке, не «вроде лучше». ТЖ выключен.

Если не помогло

  • ТЖ пустой — журнал не там, нет прав, порог слишком высокий, событие на клиенте.
  • Только блокировки — сеанс.
  • Только PAGEIOLATCH — диск/RAM.
  • Регресс релиза — повтор на копии до/после cfu.

Профилактика

  • Сценарии замера в wiki (5 операций).
  • После каждого обновления конфигурации — прогон.
  • Алерт по диску ТЖ, чтобы забытый logcfg не убил хост.
  • Синхронизация времени SRV-1C/SQL01.

Соберите «лабораторию замера» заранее: том D:\1C_LOG с местом, образец logcfg.xml с порогом Duration, скрипт снимка waits, доступ к Query Store, сценарии пяти операций, пользователь-испытатель не админ. В окне не ставьте патчи и не гоняйте full backup на том же LUN. После окна выключите ТЖ и приложите архив логов к заявке. Сравнивайте релиз к релизу, не «ощущениям склада». Если SQL чистый, а тонкий клиент через WAN медленный — это не индекс. Если RDP рядом с SRV-1C быстрый — не покупайте RAM в первую очередь. Замеры без фиксации сборки 8.3 и номера конфигурации бесполезны через месяц.

Разберите четыре корзины времени: клиент, сеть до SRV-1C, код/блокировки 1С, SQL на SQL01. Каждая корзина — свои инструменты (диспетчер задач ПК, TNC, консоль кластера, waits). Не начинайте с rebuild index, пока корзина не SQL. Для SQL 2019/2022 Query Store удобнее старого profiler; лимит размера обязателен. ТЖ 8.3 с фильтром Duration отвечает на «какой вызов», SQL — на «почему внутри СУБД». Вместе в одном окне, потом оба выключить. Итог замера — число секунд и решение, не папка логов на 20 ГБ без выводов. Сохраните скрин консоли кластера и вывод waits в ту же заявку, чтобы через квартал можно было сравнить тот же контур SRV-1C/SQL01.

FAQ

APDEX в 1С вместо ТЖ?

Полезно как постоянный монитор, если настроен. Не заменяет разбор SQL плана. Можно вместе.

ТЖ на каждом клиенте.

Тяжело. Начните с сервера кластера. Клиентский — если доказали, что сервер не виноват.

Можно ли держать EXCP постоянно?

Узкий журнал исключений иногда оставляют. Всё подряд — нет.

Нужна ли лицензия КИП/ЦУП?

Для глубокого анализа полезно. Этот текст — минимум штатными ТЖ+SQL без покупки. Не срывает диагностику waits.

logcfg не подхватывается.

Путь не тот, XML битый, нет прав у агента на каталог log, рестарт не нужен обычно — подождите, проверьте location. Не кладите XML в каталог пользователя вместо conf сервера.