Добрый день, друзья! Сегодня я хочу рассказать вам про общий подход к решению проблем производительности. Эта статья будет небольшим практическим пособием «С какой стороны подойти к этому зверю», если у вас возникла проблема производительности работы 1С.
1. Текущее состояние
Итак, к нам поступил пациент и мы начали его осматривать. Первым делом нам надо определить: пациент при смерти, или пациент болен. В зависимости от этого будут различаться методики лечения.
- Пациент при смерти. Ключевые операции не выполняются, выполняются нестерпимо долго, всё в ошибках, блокировках, ничего не работает, клиент в панике. Нужна реанимация. Данная ситуация характерна тем, что все проблемы отчётливо видны, не нужны никакие APDEXы, нудные замеры и прочие действия, которым нас учат на курсах по производительности. Единственное, что нам надо сделать – обеспечить работоспособность базы.
- Пациент болен. В данной ситуации система работает, но производительность её неудовлетворительная. И вот в этой ситуации как раз не надо сразу начинать исправлять проблемы. Дело в том, что ключевым в успехе нашей работы будет достижение хорошей производительности системы. Но что есть хорошая производительность? Нам обязательно надо определить это конечное состояние. Тут мы используем методику APDEX, пока ничего лучше не придумали. С помощью этой методики мы определим текущее состояние системы и состояние, которое нам необходимо достичь. Прочитать о данной методике можно здесь. Но главное, что нам необходимо сделать на начальном этапе лечения – расставить счётчики на ключевых операциях и начать собирать информацию о времени их выполнения.
2. Уточняющие вопросы
Отлично, мы разобрались с первичным признаками болезни. Дальше мы посмотрим на проблемы более детально, зададим правильные вопросы, и сможем определить, какого характера эти проблемы и как нам двигаться дальше.
Итак, вопросы, которые надо задать клиенту:
- Что именно тормозит? Отдельные виды документов, справочников, отчётов, или всё сразу? Если тормозят отдельные объекты, то очевидно, что проблемы именно в этих объектах, или взаимодействующих с ними. Скорее всего, неоптимально написанный код, либо конфликты блокировок. Если же тормозит всё, начиная от проведения РТиУ, заканчивая открытием справочника Номенклатура, то проблема общего характера, и в код можно особо не смотреть, а проверять общую работоспособность системы и оборудование.
- Тормозят на открытие, или запись/проведение? Или всё сразу? Данная информация подскажет нам, есть ли проблемы «на чтение», или «на запись», или присутствуют обе проблемы.
- Начались ли проблемы плавно, незаметно, или резко? Если резко, были ли какие-нибудь изменения в инфраструктуре? Например, новый релиз платформы, или оборудование поменяли. Если проблемы появились плавно, то, скорее всего, они связаны с ростом базы/ ростом числа пользователей/ ростом документооборота. Если же проблемы появились резко, то нужно искать проблемы в оборудовании, системе 1С (ошибки платформы, кластер серверов и т.д.)
- Проблемы проявляются с одинаковой интенсивностью в течение дня, или разной? Зависит ли интенсивность проблем от количества одновременно работающих пользователей? Если интенсивность возникновения проблем одинаковая, то это нам ничего не даст, а вот если клиент говорит, что утром всё хорошо, а к обеду работать невозможно, то вероятны проблемы, связанные с увеличением количества работающих пользователей к середине дня и увеличением документооборота. Тут надо смотреть в сторону загруженности оборудования и проблем параллельной работы пользователей.
- Какие ещё есть проблемы? Ошибки превышения времени ожидания блокировки, ошибки взаимоблокировок? Если есть ошибки, связанные с транзакционными блокировками и пользователи жалуются на них, то однозначно есть проблемы параллельной работы.
3. 3 основных вида проблем
Резюмируя, можно выделить 3 основных вида проблем:
- Проблемы неоптимального кода, долго выполняются операции
- Проблемы загруженности оборудования
- Проблемы параллельной работы пользователей
Нам необходимо установить, какой вид проблемы у нас. В зависимости от вида проблем мы идём разными путями решения.
3.1 Проблемы неоптимального кода, долго выполняются операции:
Симптомы: проблемы проявляются как в однопользовательском режиме, так и в многопользовательском – одинаково. Оборудование при этом не загружено, а документ проводится очень долго, или отчёт формируется очень долго.
Чтобы найти причины таких проблем, нам достаточно стандартного замера производительности. Делаем замер проведения, находим самую тяжёлую операцию, смотрим/оптимизируем, радуемся. Это самый простой случай.
3.2 Проблемы загруженности оборудования
Симптомы: всё тормозит, счётчики оборудования «зашкаливают». Эта проблема уже немного посложнее. Т.к. причин может быть несколько. Необходимо определить, почему оборудование так загружено. Посмотреть монитор активности SQL на предмет самых тяжёлых запросов, а так же включить сбор технологического журнала с показателями самых тяжелых запросов. Если есть ЦУП, то собрать замеры с помощью него и проанализировать. Чаще всего причина одна из двух: либо есть очень тяжёлые неоптимальные операции, которые занимают почти все ресурсы оборудования (в одной из статьей недавно я приводил пример), либо, если таких операций не найдено, всё работает штатно, то проблема в недостаточной производительности оборудования. Но всегда помните! Прежде чем сказать клиенту, что у него недостаточно производительное оборудование, убедитесь, что это действительно так и все остальные причины исключены. Потому что, когда клиент купит новый сервер за $$$ и у него всё будет работать так же не спеша, он «крайне удивится и огорчится».
3.3 Проблемы параллельной работы пользователей
Симптомы: тут симптомов будет много. Ошибки, как, например, на данных скриншотах, т.е. конфликты блокировок.
Ну это очевидно 🙂 . А теперь другие симптомы:
Всё тормозит нестабильно. Например, утром всё хорошо, к обеду – плохо. В однопользовательском режиме всё «летает», а в многопользовательском тормозит. Одни и те же действия занимают «то 5 секунд, то 40». Становится понятно, что пользователи конфликтуют между собой.
Тут мы уже не отделаемся простым замером производительности, т.к. он ничего не покажет. В идеальном случае, необходим 1С:ЦУП. С помощью него можно замерить и проанализировать проблемные процессы. Но ЦУП есть у очень небольшого количества клиентов и приходится осуществлять поиск таких проблем стандартными средствами с использованием MSSQL и технологического журнала 1С.
4. Заключение
В заключение хотел сказать о том, что обязательно надо проверять при любых проблемах производительности:
- Настройки СУБД. Например, в недавнем примере в настройках СУБД было указано использование небольшого количества памяти. По этой причине большие таблицы не могли кэшироваться и данные считывались напрямую с дисков, сильно загружая дисковую подсистему.
- Релиз платформы. Да, релизы не все стабильны. Иногда проблема кроется в ошибках релиза, об этом можно почитать в баг-репортах и на партнёрском форуме.
- Регламентные операции с БД, актуальность статистики, фрагментация индексов. Актуальность статистики и фрагментация индексов напрямую влияют на производительность, нужно проконтролировать выполнение регламентных операций.