Жалобы на медленную работу 1с, куда смотреть и что делать ? Сидишь себе спокойно, работаешь, пилишь очередную фичу для бизнеса — и тут к тебе забегает разъярённый бухгалтер со словами: «Ваша 1С не работает, всё висит и ничего не проводится». 😡 Что обычно делаем в такой ситуации? В лучшем случае идём на сервер приложений 1С, открываем диспетчер задач, видим там rphost, который съел всю память на сервере, и 🪓 срубаем процесс. Всем сразу становится легче, и система снова «летает». 🚀 У этого способа есть один существенный минус: без расследования ситуация повторится у вас со 100% вероятностью. А если вы будете в отпуске или проблема возникнет при закрытии месяца? 😬 ✅ Правильный алгоритм: 1️⃣ Открываем консоль кластера 1С и сортируем по колонке «Время вызова (текущее)» — это время в секундах, в течение которого сеанс находится в клиент-серверном вызове. Сверху будут сеансы, находящиеся в самом длинном клиент-серверном вызове. Берём на карандаш номер соединения. ✍️ 2️⃣ Далее смотрим, находится ли сеанс в СУБД: это можно понять по колонке «Время вызова СУБД (текущее)». ➡️ Если сеанс находится в вызове СУБД — идём на СУБД и решаем проблему там. 3️⃣ Для начала идём в журнал регистрации и пытаемся понять, что делал пользователь, прежде чем попасть в такой длинный вызов. 🕵️‍♂️ 4️⃣ Далее идём в технологический журнал (ТЖ) и по номеру соединения находим начало клиент-серверного вызова по событию VRSREQUEST. В рамках одного вызова номер соединения переназначен быть не может. 🔎 Затем смотрим события ниже и пытаемся понять, какие из них привели к проблеме. Это могут быть длительные запросы, блокировки. 🧰 Если оперативно найти проблему не удалось, рекомендуется снять дамп процесса утилитой ProcDump и вместе с полным тех. журналом и счётчиками загрузки оборудования отправить в 1С 📩. Целиком рубить rphost бывает излишне, можно пожертвовать сеансом пользователя, который утилизировал все ресурсы. Тут кстати писал про медленное открытие форм, и как это расследовать. А у вас часто возникают такие ситуации❓