Почему тормозит 1С: с чего начать диагностику
Когда 1С тормозит, причина почти всегда лежит в одном из пяти мест: сеть и канал, сервер и диски, настройки СУБД, блокировки и тяжёлый код (запросы и проведение документов). Начинать нужно не с перезагрузки и не с покупки железа, а с ответа на вопрос, что именно медленно: открытие программы, формирование отчёта, проведение документа или всё сразу. От этого зависит, куда смотреть.
Сначала уточните симптом
Фраза «1С тормозит» ничего не говорит о причине. Задайте пользователям несколько простых вопросов и запишите ответы.
- Медленно у всех или у одного рабочего места?
- Медленно всегда или в определённые часы (начало дня, закрытие месяца)?
- Тормозит запуск, открытие списка, проведение документа, отчёт?
- Это началось после обновления, добавления пользователей, изменения сети?
Если медленно у одного человека, смотрите его компьютер, профиль, антивирус, подключение. Если у всех и в одно и то же время, ищите общую причину: сервер, блокировки, фоновые задания. Так вы сокращаете область поиска с самого начала.
Проверяем сеть и клиентские места
Для файловой базы сеть критична: клиент читает файлы напрямую, и любые потери пакетов или Wi-Fi вместо кабеля дают заметную задержку. Для клиент-серверного режима сеть тоже важна, но нагрузка на неё иная.
Что я обычно смотрю в первую очередь:
- Как подключено проблемное место: кабель, Wi-Fi, VPN. Через VPN с большой задержкой работа с файловой базой почти всегда мучительна.
- Есть ли потери и скачки задержки до сервера.
- Не сканирует ли антивирус каталог базы и временные файлы 1С в реальном времени.
- Достаточно ли на клиентском компьютере памяти и свободного места на системном диске.
Удалённые сотрудники на файловой базе через интернет это отдельная проблема. Обычно её решают переходом на клиент-серверный вариант с терминальным доступом или веб-клиентом, а не настройкой.
Сервер: процессор, память, диски
На сервере проверьте загрузку в проблемные часы. Мониторинг по факту, а не по ощущениям: загрузка процессора, свободная память, очередь на дисках. Диски часто оказываются узким местом, особенно если на одном физическом массиве лежат и база, и файлы, и резервные копии, и ещё что-то.
Типичные находки:
- на сервере выключен или упёрся в лимит параметр, ограничивающий память СУБД;
- журналы транзакций и временные базы лежат на медленном диске;
- виртуальная машина делит ресурсы с соседями, и в часы пик их не хватает;
- нет свободного места, и СУБД работает на пределе.
Если у вас нет постоянного наблюдения за сервером, настройте его. Как это организовать без громоздких систем, описано в статье про мониторинг сервисов и уведомления о сбоях.
СУБД и обслуживание базы
Клиент-серверная 1С работает поверх СУБД, и её состояние напрямую влияет на скорость. Здесь важны регулярное обслуживание индексов, актуальная статистика и корректные настройки. Конкретные параметры зависят от СУБД, версии и нагрузки, поэтому универсальных значений не существует, и я не буду их придумывать. Ориентируйтесь на рекомендации разработчика платформы и документацию вашей СУБД.
Базовая гигиена выглядит так:
- по расписанию обновляется статистика и перестраиваются индексы;
- выполняются регламентные операции обслуживания;
- размер базы и таблиц-лидеров периодически просматривается, чтобы заметить неконтролируемый рост (например, разросшиеся регистры или журнал);
- старые данные архивируются или сворачиваются по принятой в компании политике.
Блокировки и фоновые задания
Если база «замирает» на минуту и снова оживает, а в это время проводятся документы, подозревайте блокировки. Два пользователя пытаются работать с одними и теми же данными, и один ждёт другого. Иногда виновата не нагрузка, а алгоритм проведения: документ блокирует больше, чем нужно, или транзакция слишком длинная.
Что проверить:
- в консоли кластера серверов и в мониторинге блокировок видны ожидающие сеансы;
- в журнале регистрации можно найти ошибки таймаута блокировок;
- регламентные задания (обмены, пересчёты, закрытие периода) не запущены ли в рабочие часы;
- нет ли «зависших» сеансов, держащих блокировки.
Частая картина: в 9 утра пользователи начинают работу, а по расписанию как раз запускается тяжёлый обмен с сайтом. Простой перенос задания на другое время иногда решает проблему, не трогая код. Про устройство обменов с сайтом можно прочитать в статье про обмен 1С с сайтом и типичные ошибки.
Тяжёлые запросы и код
Если инфраструктура в порядке, а медленно только конкретное действие, смотрим код. Для этого есть технологический журнал и замер производительности в самой платформе. Они показывают, какие запросы выполняются дольше всего и сколько раз вызываются.
Типичные программные причины:
- запрос в цикле: по одному обращению к базе на каждую строку документа;
- выборка без нужных отборов и без использования индексов;
- обращение через точку к реквизитам ссылок в запросе, порождающее лишние соединения;
- отчёт без отборов по умолчанию, который за раз читает за все годы;
- избыточные подписки на события, срабатывающие на каждый документ.
Небольшой пример с замером времени фрагмента кода, чтобы понять, где потери:
НачалоЗамера = ТекущаяУниверсальнаяДатаВМиллисекундах();
// проверяемый фрагмент
Результат = ЗапросПоДокументам.Выполнить();
Длительность = ТекущаяУниверсальнаяДатаВМиллисекундах() - НачалоЗамера;
ЗаписьЖурналаРегистрации("Замер.Запрос",
УровеньЖурналаРегистрации.Информация,,,
"Длительность, мс: " + Длительность);Это грубый инструмент, но он быстро показывает, где стоит копать глубже штатными средствами.
Что можно улучшить, не трогая код
Прежде чем заказывать переработку, пройдитесь по списку недорогих мер:
- Перенесите тяжёлые регламентные задания на нерабочее время.
- Уберите антивирусное сканирование каталога базы.
- Проверьте, что платформа и конфигурация обновлены до поддерживаемых версий.
- Ограничьте отчёты разумным периодом по умолчанию.
- Выделите базе нормальные диски, не общие с файловыми хранилищами.
Если после этого узкое место осталось, дальше уже оценивайте стоимость оптимизации. Из чего она складывается, описано в материале о стоимости доработки 1С.
Как не потерять результаты диагностики
Диагностика тормозов часто растягивается на недели, потому что результаты не фиксируются. Ведите простой журнал: дата, симптом, что проверили, что изменили, что получили. Меняйте за один раз только одну вещь, иначе вы не поймёте, что именно помогло. Если вы перенесли задание, обновили статистику и добавили память одновременно, а стало быстрее, вы не узнаете причину и не сможете повторить успех на другой базе.
Хорошо, если у вас есть эталонные замеры: время открытия документа, проведения типового заказа, формирования ключевого отчёта. Снимите их в спокойное время, а затем сравнивайте в моменты жалоб. Тогда разговор с пользователями переходит из режима «стало медленно» в режим «проведение выросло вдвое по сравнению с прошлым месяцем», и поиск причины становится предметным.
Когда нужно привлекать специалиста
Часть проверок выполняется силами системного администратора: сеть, диски, антивирус, ресурсы сервера. Но разбор технологического журнала, анализ планов запросов и оптимизация кода уже требуют опыта программирования в 1С и знания СУБД. Если после базовых шагов проблема не ушла, лучше сразу собрать для исполнителя набор данных: версия платформы и конфигурации, тип СУБД, число пользователей, время, когда видны тормоза, и конкретные действия, которые тормозят.
Частые вопросы
Поможет ли покупка более мощного сервера?
Иногда да, но без диагностики это лотерея. Если проблема в блокировках или запросе в цикле, мощное железо лишь отодвинет момент, когда всё снова замедлится. Сначала выясните, что именно упирается в ресурс.
Почему 1С стала тормозить после обновления?
Возможны разные причины: обновился платформенный клиент, изменились структуры данных и нужна реструктуризация или перестроение индексов, изменилась логика проведения, а ваши доработки не адаптированы. Стоит сравнить поведение на тестовой копии до и после обновления.
Файловая или клиент-серверная база, что быстрее?
Для небольшого числа пользователей в одной локальной сети файловая база работает нормально. С ростом числа пользователей, объёма данных и удалённых подключений клиент-серверный вариант обычно оказывается устойчивее. Границы зависят от конкретной конфигурации и нагрузки.
Нужно ли уменьшать размер базы?
Размер сам по себе не повод для тревоги, важнее характер роста и то, что именно растёт. Сворачивание старых данных стоит обсуждать с бухгалтерией и юристом, так как нужно учитывать требования к хранению документов.
Если диагностика затянулась или нужна оценка доработок для ускорения, загляните на страницу о доработке и интеграциях 1С или напишите мне в Telegram.