Почему производительность системы критична для бизнеса
Я занимаюсь программированием порядка 30 лет, из них 20 лет – именно в 1С. Все это время я работал в достаточно крупных компаниях: от сотен пользователей до нескольких тысяч сотрудников. Поэтому производительность – один из самых важных аспектов, которыми мне приходилось заниматься.
Скорость работы системы достаточно критична для бизнеса. Даже, казалось бы, мелкие операции, которые занимают несколько секунд, при тысяче документов, тысяче пользователей и тысяче сотрудников превращаются в часы. Причем, как правило, это нелинейная зависимость. Бывает, что при увеличении количества пользователей или сотрудников в два раза нагрузка на сервер вырастает намного сильнее и может его даже завалить.
Как только появляется проблема, ее надо быстро решить, потому что это всегда срочно: стоят платежки, надо рассчитать и выплатить зарплату, сдать бюджет. Все приходится решать прямо здесь и сейчас.
При этом обычно есть ограничения по ресурсам и времени: специалист один, дополнительных мощностей нет, и закрыть проблему только ресурсами не получается. Такие проблемы возникают не один раз и навсегда, а периодически. Делают доработки, увеличиваются объемы, выходит новая платформа или конфигурация, поэтому состояние системы нужно постоянно мониторить.
Почему добавление ресурсов не всегда помогает
Один из очевидных способов увеличить скорость – добавить новый сервер, память, процессоры или диски и больше ничего не делать. Но чаще всего это не помогает. Нужно искать узкие места, иначе компания тратит много денег и времени, а эффекта в итоге нет.
Система 1С состоит из трех элементов: клиент 1С, сервер 1С и SQL Server. Поиск проблем и ускорение со стороны клиента и сервера 1С более-менее понятны. Но SQL Server – отдельный объект. С одной стороны, это вотчина администраторов, и 1С-ник часто даже не знает, что там происходит. С другой стороны, администраторы говорят: «Это ваше 1С, разбирайтесь сами». Поэтому нужен комплексный анализ всей системы.
Есть и организационные сложности. В разных компаниях все устроено по-разному, но часто администрированием СУБД занимаются те же специалисты, которые администрируют все остальное. Они поставили сервер по инструкции – «Next, Next, Next» – и он более-менее работает.
Разработчики 1С тоже не всегда представляют, чем занят SQL Server. Они просто видят по профайлеру, что тормозит выполнение запроса, получение следующего результата или запись, но не знают, что в этот момент происходит на сервере. Кроме того, 1С-ники и администраторы часто находятся в разных подразделениях, и взаимодействие между ними налажено не всегда. Поэтому нужен подход, который будет удобен и понятен обеим сторонам.
Что нужно проверить на SQL Server
Чтобы понять, какая проблема возникла на SQL Server, нужно пройти несколько шагов.
Первое – проверить настройки самого SQL Server. Настройки по умолчанию не являются оптимальными по определению, потому что для разных систем нужны разные параметры. В каждой СУБД их несколько тысяч, они меняются между версиями и подверсиями, а у MS SQL Server и PostgreSQL наборы настроек различаются. Это не значит, что разработчики чего-то не продумали. Просто под разные условия нужны свои настройки.
Второе – проверить саму базу данных: ее настройки и отдельные тонкости, которые могут очень сильно ускорить работу системы.
Третье – понимать, чем сервер занят в данный момент. Иногда кажется, что он работает только на вашу задачу, но параллельно могут идти перестройка индексов, обновление статистики, блокировки или резервное копирование. Вы думаете, что все должно работать нормально, а именно в этот момент все плохо.
Четвертое – учет рекомендаций сервера. Современные SQL Server собирают внутреннюю статистику и формируют рекомендации, чтобы работать лучше. Эти рекомендации зависят от конкретной СУБД – PostgreSQL или MS SQL Server – и от ее версии. Их тоже нужно учитывать, чтобы получить максимальный эффект.
Графическая оболочка или запросы
Проверить, что происходит на SQL Server, можно двумя основными способами.
Первый вариант – графическая оболочка. Вы ее открываете, там все удобно и наглядно: нажали на кнопки, увидели красивое представление и даже не особенно погружались в детали.
Казалось бы, это удобно, красиво и понятно. Но есть минус: графическая оболочка показывает мало. Часть данных можно получить только запросом, и невозможно сделать интерфейс, который устроит всех.
Кроме того, я столкнулся с проблемой: когда сервер сильно тормозит, графическая оболочка тоже ничего не показывает – просто висит. В итоге вы даже не можете увидеть, что происходит.
Второй вариант – запросы. С их помощью можно получить практически все: текущие действия, параметры и внутренние данные сервера. В SQL Server есть специальная возможность, которая позволяет администраторам приоритетно подключиться к серверу, увидеть проблему или, например, завершить лишний процесс.
Данные, полученные запросами, можно сгруппировать как нужно, выполнить расчеты и вывести результат в более удобном виде. Это помогает и для собственного анализа, и для передачи информации другому специалисту.
Если в случае с графической оболочкой вас спрашивают: «Какие у вас настройки?», нужно знать, куда зайти и на что нажать. В случае с запросами вам могут просто дать текст запроса. Вы выполняете его, выкладываете результат, например, на форум, и все сразу видно.
То же относится к работе с ИИ. Если передать модели полный набор данных сервера, она сможет дать более полезные рекомендации, чем при анализе набора скриншотов из графической оболочки.
У запросов есть и минусы. Во-первых, нужно знать язык SQL. Он несложный, но основная проблема – понимать, что именно искать. Это не графический интерфейс, где можно нажать кнопку и получить результат. Нужно знать, какие объекты есть в конкретной версии SQL Server и что они могут показывать.
Набор диагностических запросов
Я собрал и прикрепил к статье те запросы, которыми пользуюсь сам. Самих текстов не будет: их много, они различаются для PostgreSQL и MS SQL Server и зависят от версии. В разных версиях одной и той же СУБД поля появляются и удаляются. Поэтому в наборе есть отдельные признаки, по которым можно отобрать запросы по типу и версии SQL Server и выбрать именно те, которые подходят для конкретного случая.
Чем этот набор отличается от запросов, которые можно просто найти в интернете? Источников очень много. По некоторым интересным запросам есть большие статьи: выполните это, потом это, потом еще несколько действий, подставьте значения. Здесь все собрано в одном месте и может стать точкой отправления для дальнейшего анализа.
Кроме того, из нескольких относительно простых запросов сделан один сложный, чтобы сразу видеть общую картину.
В запросы добавлен анализатор. Он не просто показывает, что есть определенная проблема или параметр, но и проводит анализ. Например, запрос по состоянию статистики и индексов не просто говорит, хорошо все или плохо, а указывает, что нужно сделать: реструктуризацию, перестроение индекса или полное обновление статистики.
Если возможно, запрос сразу возвращает готовый скрипт. Например, если рекомендуется обновить статистику, формируется готовый текст, который можно скопировать и выполнить.
Запросы анализа сервера
Запросы разделены на несколько частей. Первая часть – настройки сервера и информация о доступных ресурсах. Я включил только то, что считал важным для поиска узких мест в производительности – как общих, так и относящихся именно к 1С.
Настроек сервера очень много, и от их правильности производительность зависит очень сильно. У нас были случаи, когда изменение флагов увеличивало производительность в несколько раз.
Один из важных блоков – параметры временной базы. По умолчанию они могут быть настроены неоптимально. Например, если задан слишком маленький размер файлов, сервер тратит много времени на их постоянное приращивание.
Отдельный запрос показывает свободное место на дисках. Для этого не нужно обращаться к администраторам и отдельно выяснять, что происходит. Можно увидеть, есть ли ограничения и когда сервер упрется в доступное пространство.
Еще один тип запросов показывает, где можно освободить место (сжать). Бывает, что диск заполнен после обновления базы данных, но внутри файлов осталось много свободного пространства. В этом случае не обязательно первым делом увеличивать диск. Иногда можно сжать базу, освободить место, уменьшить размер резервных копий и сократить время резервного копирования и восстановления.
Проверка параметров сервера сама по себе сложна: их тысячи, они по-разному влияют на систему и зависят от версии и подверсии SQL Server.
Есть флаги, которые у всех на слуху и описаны, в том числе, на ресурсах 1С. Но встречаются и менее очевидные параметры. Например, у нас тормозила форма списка с конструкцией «выбрать первые». У одного пользователя она открывалась нормально, а у другого – несколько минут.
Оказалось, что в определенной версии MS SQL Server появилась оптимизация для такой конструкции. В документации Microsoft было указано, что в отдельных случаях она может ухудшать работу и соответствующий флаг нужно отключить. Нам это очень помогло: иначе пользователь несколько минут сидел перед формой списка, которая должна была получить первые 30 записей.
В PostgreSQL тоже много настроек и параметров. Это большие списки, причем некоторые значения зависят от других параметров. Например, от типа диска, количества ядер или уже установленных значений. Для одного параметра может быть указано «одна четверть от предыдущего», для другого значение зависит от типа диска и дополнительно умножается на коэффициенты, потому что задается в страницах.
Запросы анализа базы данных
Следующий блок запросов предназначен для анализа баз данных. Один из самых больших, над которым я долго работал, – анализ индексов и статистики.
Есть много материалов о том, насколько сильно индексы и статистика влияют на производительность и как их обслуживать. Здесь задача состояла в том, чтобы не просто показать все объекты, а вывести наверх максимально значимые: наиболее используемые, наиболее фрагментированные или те, у которых неактуальна статистика.
Для каждого такого объекта указывается, что нужно сделать, и по возможности формируется готовый скрипт.
При анализе проблем с производительностью неожиданной причиной могут оказаться зарегистрированные изменения. Например, существует план обмена, о котором забыли, и в нем продолжают копиться изменения. Обновление базы идет очень долго, потому что система пытается обработать и эти записи. Запрос позволяет обратить внимание на то, что накопилось несколько миллионов зарегистрированных изменений, которые мешают работе.
Отдельный блок связан с резервными копиями. Сам факт наличия бэкапа еще не говорит о том, что с ним все нормально.
Запрос позволяет увидеть, когда была сделана резервная копия, сколько времени занял процесс и кто его запускал. По замечанию одного из пользователей была добавлена проверка целостности цепочки.
У него был случай: резервная копия существовала, но при попытке восстановления выяснилось, что использовалась цепочка инкрементных копий, а специалист по информационной безопасности в какой-то момент сделал отдельный бэкап и разорвал ее. Поэтому важно проверять, что цепочка резервных копий не нарушена.
Есть и запрос по крупным таблицам. Он помогает понять, какие таблицы действительно нужны и что можно уменьшить. Особенно это важно при подготовке базы для разработчиков.
Можно сразу увидеть, какая таблица занимает много места. Например, в базе объемом около 2 600 ГБ значительный объем могли занимать документы Диадока и версии, которые для копии разработчиков можно удалить и тем самым существенно уменьшить базу.
SQL Server собирает данные о собственной работе, поэтому можно проверить, что именно тормозит на конкретном сервере. Например, запрос по ожиданиям показывает, какие типы ожиданий есть и насколько сильно они влияют. После этого можно перейти к описанию конкретного ожидания и разобраться, что оно означает.
Текущая нагрузка
Одна из самых важных групп запросов показывает, чем сервер занят прямо сейчас. То, что вы думаете, будто он занят только вашей задачей, еще ничего не доказывает.
Часто проблема формулируется так: «У нас сейчас все висит. Кто это сделал?» Запрос показывает все текущие операции и позволяет увидеть, чем конкретно занят сервер.
В том числе видно, сколько времени существует запрос и сколько времени он действительно выполняется. Это не одно и то же. Запрос может ждать ресурс, иметь низкий приоритет, ожидать окончания обновления статистики или резервного копирования.
Отдельно анализируются установленные блокировки. Это несколько раз нас спасало. Однажды из-за сбоя плана обмена процесс начал изменять контактную информацию у всех физических лиц и фактически заблокировал работу с этими данными.
Полного отказа не было, но у всех все тормозило. Запросы позволили сгруппировать блокировки по объектам и увидеть, сколько операций затронуто.
Есть также запросы для анализа TempDB. Они полезны, когда выполняются операции с временными таблицами и временная база переполняется: можно понять, кто и чем ее занимает.
Ограничения рекомендуемого анализа
Все эти возможности полезны, но возникает вопрос: что с ними делать дальше? Есть несколько тысяч параметров SQL Server и множество рекомендаций. Чтобы собрать данные и разобраться в них, нужны квалификация и время. Чтобы все сгруппировать и обработать, тоже требуются большие затраты.
Поскольку мы программисты, логичный вариант – автоматизировать эту работу. По принципу Парето можно предположить, что около 80% возникающих проблем более-менее типовые и поддаются автоматизации. Поэтому то, что можно выполнять автоматически, лучше выполнять автоматически.
Для этого была сделана обработка на 1С, которая помогает 1С-нику понять, что происходит с сервером, причем в терминах 1С. Она показывает не просто то, что тормозит таблица _Document485, смысл которой непонятен без расшифровки.
Один из основных элементов системы – анализ текущей операции. Обработка показывает, сколько времени работает операция, кто ее блокирует, какой текст запроса выполняется и какие соединения участвуют. Текст запроса сразу приводится к более понятному для 1С-ника виду.
Запрос разбирается в терминах 1С, а дополнительные данные берутся из плана выполнения и вспомогательных запросов.
В современной версии MS SQL Server можно открыть текущий запрос и увидеть план в виде графа: где выполняется сортировка, где используется Index Seek, а где Index Scan. В обработке эти данные сгруппированы, и по ним сразу проводится анализ.
Например, система может показать, что запрос затрагивает семь регистров сведений, содержит десять подзапросов и двадцать соединений, поэтому в целом не оптимален. Сразу видно, кто выполняет запрос, сколько времени он работает и что с ним можно сделать. Это позволяет принять оперативное решение.
Для такого анализа потребовалась серьезная доработка, в том числе перевод запроса с языка SQL Server в представление, понятное 1С-нику. Выполняются обработка метаданных, упрощение запроса и удаление неинтересных или паразитных частей.
После этого проводится анализ узких мест, анализ плана запроса, если он доступен, и формируются рекомендации, что нужно сделать. В результате пользователь получает обработанный запрос и советник с вариантами дальнейших действий.
Пример выглядит так:
Здесь он обработан:
И советник, который показывает, что с этим можно сделать:
Скачать можно здесь: //infostart.ru/1c/tools/2039548/
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
Вступайте в нашу телеграмм-группу Инфостарт