Картина, знакомая каждому специалисту: пользователи жалуются, что тормозит 1С, менеджеры требуют ответов, а в переговорной разгорается битва. Системные администраторы тычут пальцем в графики загрузки CPU — «Смотрите, сервер загружен всего на 20!». Разработчики парируют — «У нас типовая конфигурация! Это вы не умеете настраивать железо!».
Цифры летают по воздуху, как снаряды, но проблема остается. Большинство таких инцидентов затягиваются на дни именно из-за взаимных обвинений. Вместо решения проблемы сотрудники пытаются спихнуть проблему друг на друга.

Админский бункер: «Виноват код!»
Администраторы живут в мире жестких цифр: CPU, RAM, дисковые операции, сетевые задержки. Их аргументы железобетонны:

• Вариант 1 (самый частый). Сервер недогружен, ресурсы свободны, а значит, проблема в коде.
• Вариант 2 (редко, но встречается). Сервер перегружен из-за «кривых» запросов, а значит, проблема в коде.

Но есть нюанс: они видят только симптомы, не понимая конкретную причину.

Бункер программистов: «Виновато железо!»
Программисты пытаются воспроизвести проблемы на стендах или на своих машинах, делать замеры производительности. Их козырь:

• На тестовом стенде (на моем компьютере) всё работает идеально, а значит, проблема в железе.

Но они не учитывают, что код на стенде работает в другом окружении (настройки ОС, сеть, регламенты и прочее).

Итог конфликта: два набора метрик, два языка, ноль прогресса. Пока одни смотрят на температуру процессора, другие смотрят в конфигу и видят …, но слон в комнате — отсутствие общей картины.

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

Кейс №1:
Пользователи периодически жаловались на "вылеты" фоновых заданий, долгое выполнение операций и т.п. Ошибка плавающая, без выраженной периодичности. Используется база ERP в кластере с четырьмя серверами 1С.

Для анализа ситуации решили посмотреть загрузку оборудования на всех серверах, а также включить сбор показателей в Мониторе, которые могут указывать на повышенную нагрузку процессора на сервере 1С. В первую очередь это показатель Серверный вызов.
Монитор позволяет видеть данные сразу с нескольких серверов, поэтому довольно быстро мы выяснили, что в случайные промежутки времени увеличивалась нагрузка процессора на одном из серверов 1С до 90-100% и держалась в диапазоне 30 - 60 сек. При этом каждый раз это мог быть любой из четырёх серверов.

Вот как эта ситуация выглядит на графике.

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

Кейс №2
После обновления сразу несколько операций стали выполняться медленнее чем обычно, причем эти операции с обновлением никак не связаны.

База находится в кластере из двух серверов 1С, сервер СУБД является выделенным. Воспроизведение ситуации на тестовом контуре не дало результатов, операции выполнялись быстро.
Первое что пришло в голову — то, что обновление как-то повлияло на работу системы, решили откатить обновление и вернуть систему в исходное состояние, но это не помогло.
Решили собрать счетчики производительности Performance Monitor со всех компьютеров, а также показатели Долгий запрос, Ожидания на блокировках и Серверный вызов.
В результате анализа не было выявлено корреляций между операциями, которые выполнялись долго, и нагрузкой на оборудование, но было замечено, что значение счетчика Avg. Disk Queue Length (Средняя длина очереди диска) значительно увеличилась и немного подросла загруженность процессора.
Решили расследовать почему такое могло произойти, начали смотреть в сторону дисков.
После недолгой проверки выяснилось, что база данных размещалась в массиве RAID 5, и один из дисков в массиве отказал. Отказ одного диска в RAID 5 не критичен и не приводит к потере данных, но переводит весь массив в режим Degraded (Деградирован). Это означает, что для чтения данных с поврежденного диска система вынуждена восстанавливать данные с оставшихся дисков с использованием четности, при этом запись на диск замедляется еще сильнее. На все это уходит время, ресурсы диска и процессора, отсюда и общее замедление.
На простых операциях или в периоды низкой нагрузки замедление было не заметно, но при увеличении нагрузки сразу начинались проблемы.
Обновление оказалось просто совпадением, которое пустило расследование по ложном пути, а настоящая причина была совсем в другом месте.

Кейс №3
У пользователей очень долго проводятся документы, процент загрузки процессора на сервере не выше 10%.

Для анализа проблемы в Мониторе были включены показатели Долгий запрос, Ожидания на блокировках, Взаимоблокировки и Ошибки ТЖ.
В результате обнаружилось большое число ожиданий на блокировках, оборудование было недогружено из-за неоптимального кода. База работала в режиме совместимости с 8.2, что приводило к большому числу ожиданий при чтении в транзакции.
Данный кейс - это пример очевидной ситуации, когда сразу понятно, что проблема именно в коде, а не в «железе». Никакой апгрейд не смог бы решить данную ситуацию.

Кейс №4
Пользователи жалуются на производительность, загрузка процессора на сервере постоянно около 75-80%, среднее время чтения с диска на сервере СУБД около 0.1 сек.

Для анализа проблемы в Мониторе были включены показатели Долгий запрос, Ожидания на блокировках, Взаимоблокировки и Ошибки ТЖ.
В результате анализа выяснилось, что ожиданий на блокировках практически нет. При этом есть большое число долгих запросов, и среди них попадаются даже системные запросы платформы к таблицам Config, Params и т.д. Большая часть других запросов оптимизирована, у них есть индексы и они возвращают не так много данных.
Запросы к служебным таблицам очень простые, они не могу ждать на блокировках и быть неоптимальными, единственная причина их медленного выполнения это медленная работа оборудования.
Среднее время чтения с диска на сервере СУБД не должно превышать 5 мс, в данном случае оно равнялось 100 мс.
Такой кейс явный признак того, что «железо» перегружено и уже не справляется с текущими объемами, ведь явных проблем в коде нет. В таком случае можно сделать однозначный вывод, что пора делать апгрейд, либо выносить часть нагрузки с этого сервера.

«Данные-миротворцы»
Во всех описанных случаях ключ к расследованию – это объединение метрик из двух миров на одном графике и поиске корреляций между ними.
При таком подходе диагностика проблем проходит гораздо быстрее, конфликтов меньше, а разговор предметнее.

Когда данные говорят на одном языке, даже заклятые враги становятся союзниками. А приложение, наконец, перестает «тормозить просто так».

Если вы хотите поделиться своим кейсом, напишите нам на support@1smonitor.ru