Пользователи ждут проведения документа по 20 секунд. Сервер загружен. Но поиск ,2, в технологическом журнале не возвращает ни одной строки. Такая выборка не доказывает, что 1С работала без ошибок: до версии 8.3.25 платформа вообще не записывала уровень важности в события.
Тебе нужен не отчёт «ошибок нет», а причина задержки. Новый сервер поможет, только если события журнала совпадут с упором в процессор, память или диски. Журнал показывает долгий запрос, блокировку или исключение, а ресурсы свободны — закупка железа лишь перенесёт проблему на новую машину.
В 8.3.25 изменился формат событий
В платформе 8.3.25 компания 1С добавила каждому событию технологического журнала уровень важности — всего пять уровней. Изменение указано в описании новых возможностей 1С:Предприятия 8.3.25.
Поэтому журналы разных версий содержат разный набор полей:
- ниже 8.3.25 уровня важности в событии нет;
- начиная с 8.3.25 поле есть, но одно число нельзя считать универсальным признаком ошибки.
Доступная документация 1С не подтверждает, что фрагмент ,2, охватывает все события, которые следует считать ошибками. Нет и документа, который закрепляет точную позицию этого значения в строке для каждого выпуска платформы. Значит, приписывать числу 2 смысл «ошибка» нельзя.
Запятые не превращают такой поиск в точный фильтр. Шаблон ищет последовательность символов, а не поле с известным именем и назначением. В итоге он либо пропустит нужное событие, либо совпадёт с другим числовым значением.
Сначала проверь версию платформы
Если сервер работает на 8.3.24 или более раннем выпуске, не ищи уровень важности. Платформа его ещё не записывала. Ищи тип события и поля внутри его блока.
На 8.3.25 и более новых версиях сначала сверь назначение уровней с документацией к установленному выпуску. Без такой сверки ,2, — лишь строка для поиска, не диагностический критерий.
Для решения о закупке эта граница критична. Пустую выдачу нельзя превращать в аргумент «программных ошибок нет, виноват сервер». Сначала найди задержки, исключения и блокировки. Затем сопоставь их с замерами ресурсов.
Каталог журнала задаёт logcfg.xml
Технологический журнал собирает события приложений 1С, которые работают на одном компьютере, и складывает их в текстовые файлы. Это следует из официального описания технологического журнала 1С.
Единого пути к рабочему журналу нет. Файл logcfg.xml определяет, какие события записывать, сколько их хранить и куда складывать файлы. Открой действующий конфигурационный файл и найди значение location. Так ты попадёшь в журнал своей установки, а не в каталог из чужого примера.
Внутри лежат подкаталоги процессов платформы: например, rphost, ragent и rmngr. Часовые файлы называются по шаблону ГГММДДЧЧ.log. Эти детали приводит разбор технологического журнала от OTUS. Перед автоматизацией поиска проверь их на своей версии платформы.
Ищи событие, а не число между запятыми
Читай событие как блок именованных полей. Случайное число в определённой позиции строки ничего не говорит о причине задержки.
Для первичной диагностики нужны четыре группы событий:
DBMSSQLиDBPOSTGRS— обращения к Microsoft SQL Server и PostgreSQL;TLOCK,TTIMEOUTиTDEADLOCK— блокировки, истёкшее ожидание и взаимная блокировка;EXCP— исключения платформы;MEM— потребление памяти рабочими процессамиrphost.
Назначение событий и состав полей приводит технический разбор OTUS. Это не официальная таблица формата от 1С. Используй названия как направление поиска, но не достраивай по ним собственную расшифровку кодов.
У событий СУБД проверяй Dur, Rows, Sql, Context и p:processName. В разборе OTUS поле Dur содержит длительность в микросекундах, Rows — число возвращённых строк. Context указывает модуль и строку вызова, а p:processName помогает отделить одну информационную базу от другой.
Например, Dur=3000000 — это три секунды: 3 000 000 микросекунд делим на миллион микросекунд в секунде. Теперь перед тобой наблюдаемая задержка конкретного вызова, а не пересказ жалобы пользователя.
Одного Dur для вывода мало. Длинный SQL-вызов при свободных CPU, RAM и дисках указывает на запрос, план выполнения или блокировку. Если тот же вызов совпадает с очередью диска либо загрузкой одного ядра, появляется основание проверять железо. Эту развилку мы подробно разобрали в материале о том, когда менять сервер, а когда искать выше железа.
Журнал показывает место задержки, но не загрузку сервера
Технологический журнал показывает, чем занималась платформа: выполняла SQL-запрос, ждала блокировку, выбросила исключение или наращивала память процесса. Показатели операционной системы и СУБД он не заменяет.
Чтобы принять решение по железу, совмести два наблюдения на одном отрезке времени:
| Событие в журнале | Что проверить на сервере | Предварительный вывод |
|---|---|---|
Высокий Dur у DBMSSQL или DBPOSTGRS | загрузку отдельных ядер, задержку и очередь дисков | упор в CPU или хранилище возможен |
TTIMEOUT или TDEADLOCK | свободны ли CPU, RAM и диски во время события | при свободных ресурсах сначала разбирай блокировки |
EXCP | текст ошибки и Context | исключение само по себе не обосновывает замену сервера |
Рост MEM у rphost | занятую RAM и подкачку | нехватка памяти подтверждается только совместным ростом |
| Длинный вызов при свободных ресурсах | SQL-план, блокировки, код 1С | новое железо может не изменить время операции |
Одиночного пика для закупки тоже мало. Несколько раз повтори одну рабочую операцию: проведение документа, закрытие смены или формирование отчёта. Задержка раз за разом совпадает с одним ресурсом — у тебя есть воспроизводимый результат.
Спецификация под задачу
Считать конфигурацию имеет смысл лишь после подтверждённого упора в железо. Возьмём типовой сценарий: 40 активных пользователей, одна рабочая база 1С на SQL Server объёмом 300 ГБ. Техжурнал показывает долгие вызовы СУБД, а замеры — загрузку ядра и задержки хранилища. Это допущение для расчёта, не готовая норма 1С.
Стартовая спецификация под такую нагрузку:
- Процессор: 8 физических ядер с высокой частотой, ориентир — от 3,4 ГГц под длительной нагрузкой. Здесь скорость ядра важнее 24 медленных ядер: журнал уже связал задержку с конкретными вызовами, а не с десятками параллельных задач.
- Память: 128 ГБ ECC RDIMM. Из них 64 ГБ отдаём под буфер СУБД, 24 ГБ — процессам 1С, 8 ГБ — ОС и служебным процессам. Ещё 32 ГБ остаются на пики и рост базы.
- Данные СУБД: четыре NVMe SSD корпоративного класса в RAID10. Половина сырой ёмкости уйдёт на зеркало. Четыре накопителя по 1,92 ТБ дадут около 3,84 ТБ до служебных потерь файловой системы и массива.
- Журналы транзакций: отдельная зеркальная пара SSD, если замеры показывают конкуренцию записи журнала с основными данными. Такого признака нет — отдельный массив поднимет цену, но не обязательно сократит задержку.
- Сеть: два порта 10 Гбит/с. Один порт можно оставить для резервирования либо разделить трафик приложений, СУБД и копирования по принятой схеме.
- Питание: два блока питания с горячей заменой. Они спасают от отказа одного БП, но не заменяют ИБП.
- Корпус: минимум 2U, два свободных отсека под накопители и свободные слоты памяти. Этот запас позволит нарастить объём данных без замены платформы.
Если активных пользователей не 40, а 80, не умножай все характеристики на два. Сначала проверь параллелизм. Несколько ядер стабильно загружены — смотри в сторону 12–16 быстрых ядер. Нагрузка остаётся однопоточной — частота по-прежнему важнее их количества.
Для двух баз по 300 ГБ, которые одновременно выполняют тяжёлые операции, увеличь память до 192–256 ГБ. Дисковую нагрузку разделяй только после замеров.
Такая машина обойдётся дороже сервера с SATA SSD и одним блоком питания. Экономия означает более долгую запись, отсутствие резерва по питанию и раннюю замену корпуса при росте массива. Перед заказом сверь расчёт с требованиями к процессору, памяти и дискам для 1С и проверь типовые ошибки при выборе сервера под 1С.
Критерий для решения о закупке
На версии ниже 8.3.25 не ищи уровень важности: платформа его ещё не записывала. На 8.3.25 и новее не считай ,2, универсальным фильтром, пока не сверишь значение с документацией к своему выпуску.
При задержках ищи DBMSSQL или DBPOSTGRS. Сопоставляй Dur, Rows и Context с загрузкой процессора и дисков. При остановках проверяй EXCP, TTIMEOUT и TDEADLOCK. Если растёт память rphost, сравнивай события MEM с фактически занятой RAM и подкачкой.
Правило для заявки на сервер короткое: событие журнала должно совпасть по времени с измеренным дефицитом ресурса. Совпадения нет — сначала разбирай запрос, блокировку или код 1С. Оно повторяется — подбирай процессор, память или диски под измеренную нагрузку.
