Жалоба «система тормозит» приходит к руководителю в момент, когда терпение кончилось у всех сразу. Дальше обычно следует предложение купить сервер помощнее, и это самый дорогой из возможных ответов, потому что в большинстве случаев железо ни при чем.
Разберем шесть причин по порядку встречаемости, и для каждой — как ее измерить, а не угадать.
Правило нулевое: сначала измерить
Прежде чем что-либо чинить, нужны цифры. Не «стало медленно», а «проведение реализации занимает сорок секунд, месяц назад занимало восемь».
Соберите список из пяти-семи операций, которые люди выполняют чаще всего: проведение основных документов, открытие журнала, формирование ходового отчета, запись элемента справочника, закрытие смены. Замерьте каждую секундомером в час пик и в спокойное время.
Эта таблица — единственный способ понять, помогло ли лечение. Без нее любые работы заканчиваются спором о том, стало ли лучше, и субъективные ощущения пользователей побеждают факты.
Второе, что надо снять до работ: когда именно тормозит. Постоянно, в определенные часы, в конце месяца, у всех или у нескольких человек. Ответ на этот вопрос сужает круг причин наполовину еще до того, как кто-то открыл консоль сервера.
Причина 1. Блокировки
Самая частая причина «внезапного» торможения при неизменном объеме данных. Один пользователь выполняет операцию, которая держит данные занятыми, остальные ждут своей очереди.
Классические сценарии: проведение документа задним числом, из-за которого пересчитываются последующие движения; групповая обработка, запущенная в рабочее время; закрытие месяца одновременно с обычной работой склада; отчет, который читает те же данные, что и активно меняющиеся документы.
Диагностика: в момент торможения смотрят активные соединения и ожидания на блокировках. Картина обычно однозначная: видно, кто держит и кто ждет. Если проблема плавающая, включается сбор технологического журнала на период, а потом разбирается по конкретным моментам.
Лечение бывает организационным и техническим. Организационное: тяжелые операции переносятся на нерабочее время. Техническое: переработка кода так, чтобы длинная операция не держала данные целиком, разделение на порции, пересмотр момента проведения документов.
Причина 2. Регламентные задания в рабочее время
Обмены, пересчеты итогов, обновление индексов полнотекстового поиска, выгрузки в смежные системы — все это запускается по расписанию, и расписание редко пересматривают после запуска.
Типичная картина: обмен с сайтом настроен раз в пятнадцать минут, за полгода объем номенклатуры вырос, и теперь каждый запуск работает по двадцать минут. Задания начинают накладываться друг на друга, и система живет в состоянии постоянной фоновой нагрузки.
Диагностика простая: список регламентных заданий с историей запусков, длительностью и результатом. Достаточно посмотреть, какие задания работают дольше интервала своего запуска.
Лечение: пересмотр расписания, перенос тяжелого на ночь, ограничение объема за один проход, отключение того, чем никто не пользуется. Отдельно проверяются обмены: их влияние на базу разобрано в статье про интеграции.
Причина 3. Индексы и статистика
База данных выбирает способ выполнения запроса на основе статистики о данных. Если статистика устарела, выбирается неудачный план, и запрос, который раньше отрабатывал мгновенно, начинает перебирать таблицу целиком.
Проявляется это характерно: система работала нормально, ничего не меняли, и вдруг конкретный отчет стал открываться пять минут. Часто совпадает с ростом объема данных или с массовой загрузкой.
Диагностика: посмотреть план выполнения проблемного запроса и состояние статистики по задействованным таблицам. Регламент обслуживания базы данных проверяется отдельно: обновляется ли статистика, перестраиваются ли индексы, как часто.
Лечение обычно недорогое: настроить регламентное обслуживание базы, если его нет, и добавить индексы там, где они реально нужны. Важно не увлекаться: лишние индексы замедляют запись, и в системе с интенсивным вводом документов это чувствуется.
Причина 4. Неоптимальные запросы в доработках
Каждая доработка добавляет код, и не весь этот код написан с мыслью об объеме. Отчет, который прекрасно работал на тестовой базе с тысячей документов, на трех миллионах ведет себя иначе.
Типовые ошибки: чтение данных в цикле вместо одного запроса, соединение с подзапросом вместо временной таблицы, отбор по неиндексированному полю, получение всех данных с последующей фильтрацией в коде.
Диагностика: технологический журнал показывает самые долгие запросы за период с указанием, откуда они вызваны. Обычно выясняется, что восемьдесят процентов нагрузки дают три-четыре места в коде.
Лечение — переписать эти места. Работа предсказуемая по объему: разбор, переработка, замер до и после. Именно здесь замеры из нулевого правила показывают результат нагляднее всего.
Причина 5. Настройки сервера базы данных
База данных по умолчанию настроена универсально. Учетная система дает специфичную нагрузку, и параметры под нее отличаются от типовых.
Смотрят обычно: объем памяти, выделенный под кеш данных; параметры параллельного выполнения запросов; настройки контрольных точек и журнала транзакций; размещение файлов данных, журналов и временной базы по разным дискам; параметры автоматического роста файлов.
Отдельная классическая история — временные файлы и файлы журнала на одном медленном диске с данными. Разнесение по разным носителям иногда дает эффект больше, чем удвоение памяти.
Диагностика требует специалиста по базам данных, знания учетной системы тут мало, и это как раз тот случай, когда штатный админ общего профиля закономерно упирается. Работа разовая: проанализировали, настроили, замерили.
Причина 6. Распухший журнал регистрации и история версий
Учетная система по умолчанию пишет много служебных данных: журнал регистрации, историю изменения объектов, версии документов. За годы работы это превращается в объем, сопоставимый с полезными данными.
Последствия: медленное открытие форм с историей изменений, тяжелые резервные копии, разрастание базы, замедление обслуживания.
Диагностика: посмотреть размер журнала и таблиц истории версий относительно общего размера базы. Если это заметная доля, вопрос решается настройкой глубины хранения.
Лечение: определить, за какой период данные реально нужны, настроить автоматическую очистку, при необходимости перенести старое в архив. Работа занимает часы, а эффект чувствуется сразу, особенно в резервном копировании: база уменьшается, копия снимается быстрее, восстановление тоже.
Осторожность здесь тоже нужна. Журнал регистрации иногда оказывается единственным способом разобраться, кто и когда изменил документ, а история версий спасает при спорах внутри компании. Прежде чем сокращать глубину хранения, спросите бухгалтерию и службу безопасности, нужны ли им эти данные и за какой период.
Отдельный случай: тормозит у одного человека
Когда жалуется вся компания, причина на сервере. Когда жалуется один сотрудник, а у соседа все работает, искать надо в другом месте, и это экономит дни бессмысленной диагностики базы.
Проверяются четыре вещи. Рабочее место: возраст компьютера, свободное место на диске, антивирус, который проверяет каждый файл обмена. Сеть до сервера: беспроводное подключение вместо провода дает заметную разницу на тонком клиенте. Права и настройки пользователя: избыточные отборы в списках, открытые формы с большим числом записей, персональные настройки отчетов.
Четвертое — сам характер работы. Человек, который держит открытыми пятнадцать форм и работает в журнале за три года без отбора по периоду, будет жаловаться на скорость всегда, и на любом железе.
Практический подход: посадить сотрудника за соседний компьютер и повторить операцию. Если стало быстро — проблема на его рабочем месте, и серверная диагностика не нужна. Этот прием экономит дни: он отсекает целый класс причин за пять минут.
Сводка: с чего начинать
| Симптом | Вероятная причина | Чем меряем |
|---|---|---|
| Тормозит у всех одновременно, эпизодами | Блокировки | Активные соединения и ожидания в момент проблемы |
| Тормозит в определенные часы | Регламентные задания или обмены | История запусков заданий с длительностью |
| Конкретный отчет стал медленным без изменений | Статистика и индексы | План выполнения запроса |
| Медленно только в доработанных местах | Неоптимальный код | Технологический журнал по длительности |
| Медленно вообще все, включая простые операции | Настройки базы или дисковая подсистема | Метрики сервера и базы данных |
| Долго открываются формы с историей, огромные копии | Журнал регистрации и версии | Размеры служебных таблиц |
Когда железо действительно виновато
Такое бывает, и в этом случае покупка оправдана. Но доказывать это надо цифрами до траты денег.
Признаки настоящей нехватки ресурсов: процессор загружен под сотню процентов продолжительное время при отсутствии тяжелых запросов; постоянная нехватка памяти с активным обращением к диску; очередь к дисковой подсистеме, которая не рассасывается; сеть, забитая под завязку между сервером приложений и базой.
Важная деталь: перед покупкой стоит проверить, что текущие ресурсы используются правильно. Регулярная картина — сервер с большим объемом памяти, из которого базе выделена малая часть по умолчанию. Добавление памяти в такой ситуации не даст ничего.
Отдельно про виртуализацию: если сервер живет на общей платформе с другими машинами, проблема может быть у соседей. Это проверяется на уровне гипервизора: смотрят готовность процессора, переподписку по памяти и очередь к общему хранилищу. Разговор с администратором виртуальной среды здесь дает результат быстрее, чем любые настройки внутри машины.
Как понять, что деградация началась
Идеальный вариант — вообще не доводить до жалоб. Для этого нужен минимальный контроль, который занимает несколько минут в неделю.
Что стоит смотреть регулярно: длительность ключевых операций по тем же замерам, что делались на старте; время выполнения регламентных заданий в динамике; размер базы и скорость его роста; свободное место на дисках; число ошибок в журнале за неделю.
Все эти показатели меняются постепенно, и именно поэтому их не замечают. База, которая растет на несколько процентов в месяц, через год удваивается, а операция, которая была на две секунды медленнее в прошлом квартале, к концу года становится вдвое дольше.
Ведение такой истории занимает пятнадцать минут в неделю и дает возможность планировать работы заранее, а не тушить пожар. При подписке на обслуживание это входит в ежемесячный отчет и обсуждается на регулярной встрече.
Сколько стоит разбор
Разовая оптимизация — 150 000 – 400 000 ₽ в зависимости от объема базы, количества доработок и глубины проблемы. Внутри: сбор метрик, анализ технологического журнала, разбор блокировок и запросов, настройка обслуживания базы, переработка самых тяжелых мест, замеры до и после.
Регулярное обслуживание сервера учетной системы — 45 000 ₽ в месяц для небольшого контура и 90 000 ₽ для нагруженного. Сюда входит мониторинг, регламентное обслуживание базы, контроль заданий и копий, реакция на инциденты. Смысл подписки в том, что деградация ловится до жалоб пользователей: длительность операций отслеживается в динамике, и работы планируются заранее.
Как выбирать между своим специалистом и внешней командой, разобрано в отдельной статье, а параметры договора — в разборе SLA.
Файловая база и когда пора уходить на сервер
Отдельная категория жалоб приходит от компаний, которые работают с файловым вариантом базы. Здесь причина торможения часто в самом варианте работы, и никакая настройка ее не снимет.
Файловый режим нормально живет при небольшом числе одновременных пользователей и умеренном объеме. По мере роста начинаются характерные симптомы: операции замедляются при увеличении числа работающих, растет нагрузка на сетевую папку, появляются ошибки целостности после сбоев сети или отключений электричества.
Признаки, что пора переходить на клиент-серверный вариант: одновременно работает больше десятка человек, база выросла до нескольких десятков гигабайт, регулярно требуется тестирование и исправление базы, резервное копирование занимает часы, работа идет через нестабильные каналы связи.
Переход дает не только скорость, но и управляемость: нормальные резервные копии без остановки работы, регламентное обслуживание, разграничение доступа, устойчивость к обрывам связи. Работы по переходу считаются отдельно и обычно занимают несколько дней вместе с тестированием. Отдельная статья расходов — лицензия на серверную часть, ее покупает заказчик напрямую.
Чего делать не стоит
Перезагружать сервер как метод лечения. Помогает на час и маскирует причину. Если перезагрузка стала регулярной процедурой, это диагноз, и лечения в нем нет.
Отключать проверки и контроль ради скорости. Ускорение достигается, а цена выясняется позже, когда всплывают некорректные данные.
Покупать железо до диагностики. Половина случаев не улучшается вообще, потому что узкое место было в другом, и деньги оказываются потрачены на подтверждение диагноза.
Чистить базу непроверенными обработками из интернета. Отдельный жанр катастроф, после которого приходится восстанавливаться из копии и объяснять руководству, куда делся рабочий день предприятия. Если она есть и проверена — см. материал про бэкапы.
Чек-лист первой диагностики
- Замерены пять-семь ключевых операций в час пик и в спокойное время.
- Известно, когда именно тормозит: постоянно, по часам, в конце месяца.
- Просмотрен список регламентных заданий с длительностью запусков.
- Проверено, настроено ли регламентное обслуживание базы данных.
- Известен размер журнала регистрации относительно базы.
- Собран технологический журнал за час пик.
- Проверена загрузка процессора, памяти и дисков на сервере.
- Проверено, сколько ресурсов реально выделено базе данных.
Восемь пунктов занимают день и в большинстве случаев дают ответ без покупки чего-либо. Даже если работы в итоге закажете на стороне, с этими данными разговор с подрядчиком будет предметным, а оценка — точной. Если разбираться некому, с этого начинается техаудит производительности — что в него входит, описано на странице обслуживания сервера 1С.