Как ускорить 1с на ms sql

Обновлено: 21.01.2025

Любые пользователи 1С некоторое время спустя сталкиваются с тем, что программа начинает работать слишком медленно. Общие рекомендации по ускорению «1С» были даны в статье «Как ускорить работу 1С Бухгалтерия 8.3? Бесплатные лайфхаки по оптимизации», теперь поговорим об оптимизации файловой структуры и баз данных. Итак, что делать, чтобы ускорить базу «1С»?

Основные начала и принципа учета требуют практически немедленной реакции на любое событие хозяйственной жизни (см. Закон о бухучете), При между тем пользователи «1С: Бухгалтерия 8.3» отмечают существенное снижение скорости работы, что сказывается на продуктивности и эффективности работы. Попробуйте прежде всего оптимизировать базу в режиме конфигуратора.

Ускорение базы 1С в конфигураторе

Первым делом следует сформировать бэкап, что можно сделать и без запуска конфигуратора (при наличии прав администратора).

Формирование бэкапа

На выходе вы получите зазипованный файл, находящийся там, где вы указали.

Тестирование и исправление

В режиме конфигуратора переходим по пути «Администрирование» - «Тестирование и исправление»:

В открывшемся окне отмечаем следующие пункты:

• «Реиндексация таблиц информационной базы»;
• «Пересчет итогов»;
• «Сжатие таблиц информационной базы».

Устанавливая галочки, мы получаем следующее:

• «Реиндексация таблиц информационной базы» - перестраивает табличные индексы, что позволяет ускорить 1с 8.3 файловый;
• «Пересчет итогов», т.ч. подсчитанных результатов, представленных в виде таблицы, что позволяет «разогнать» получение данных;
• «Сжатие таблиц информационной базы» уменьшает объемы БД на жестком диске.

Проверяем результаты нашей работы. Если ускорить 1С 8.3 файловый не удалось, следует попробовать иные методы

Оптимизация старых ОС

Если в силу каких-либо причин вам приходится работать на «возрастных» ОС – в частности, Windows 7 («семерка»), - то будет нелишним предпринять ряд элементарных шагов, которые помогут ускорить файловую базу 1С, поскольку ПК сможет выделять дополнительные ресурсы для обслуживания системы.

Оптимальное быстродействие

Вызовите свойства ПК (щелчок правой клавиши мыши по иконке «Мой компьютер» - «Свойства»:

Выбрать «Дополнительные параметры системы» (меню слева):

Переходим на вкладку «Дополнительно», открываем «Параметры быстродействия»:

На вкладке «Визуальные эффекты» отметить чекбокс «Обеспечить наилучшее быстродействие» для того чтобы снизить нагрузку на компьютер.

Настройка электропитания

Переходим из «Панели управления» в меню «Электропитание»:

В списке планов электропитания выбирайте «Высокая производительность»:

После этих нехитрых операций ваш ПК даже под «семеркой» сможет выделить достаточные аппаратные ресурсы с тем ускорить файловую «1С».

Тормозит 1С, ускорить SQL?

Первая рекомендация, хотя и несложная по реализации, нередко помогает решить рассматриваемую проблему.

Производим запуск SQL Server Management Studio и ввод данных для подключения, кликнув правой клавишей по серверу, открываем «Свойства»:

Выбираем закладку «Память», настраиваем ограничение потребления оперпамяти. Это делается в окошке «Максимальный размер памяти сервера (МБ)». Чтобы рассчитать этот показатель, необходимо от всего объема оперативной памяти отнять на нужды системы 4096 Мб, а затем вычесть произведение 1536 на число rphost-процессов. Так, при 32 Гб оперпамяти на сервере и двух процессах rphost максимальный размер будет равен 25 600 Мб (32 768 (32 х 1024) – 4096 – (1536 х 2)).

Перейдя на вкладку процессоров, выставляем в окне «Максимальное число рабочих потоков» значение 2048 (при значении «0» число потоков не может превышать 255), и включить чекбокс «Поддерживать приоритет SQL Server».

Вызвав «Базы данных» и рабочую базу (нажатием правой клавиши мыши), переходим на «Свойства» - «Файлы» - «Авторасширение» выставляем расширение файла БД до 250 мегабайт, лога - до 100 мегабайт с ограничением до 4096 Мб.

После нажатия «OK» закрываем программу. Замеры показывают существенное ускорение файловой 1С.

Включаем мгновенную инициализацию

Включение мгновенной инициализации файлов для пользователя, от имени которого запускается Microsoft SQL Server, что позволяет «разогнать» процессы:

• создания БД;
• добавления в имеющуюся БД файлов, журналов и проч.;
• увеличения размера существующих файлов;
• восстановления БД и (или) файловых групп.

Развертываем «Локальные политики», кликаем «Назначение прав пользователей», дважды кликаем на «Выполнение задач по обслуживанию томов», нажимаем «Добавить» - и включаем включения пользователя или группу. Не забываем нажать «Применить».

Тест работы проводится путем создания новой базы (файл в 5 Гб, журнал транзакций - 1 Мб). Если она сформировалась моментально, то все корректно (не забудьте удалить тестовую базу).

Включить блокировку страниц в памяти

Включение разрешения на блокировку страниц в памяти для пользователя или группы производится аналогичным образом.

Тем самым мы определяем, какие именно пользователи вправе сохранять данные в оперпамяти. При этом система не будет отправлять страницы данных в виртуальную память на диске, что повышает производительность. Для проверки следует или перезагрузить сервер, или зайти под логином пользователя, под которым происходит запуск MS SQL Server.

Отключить DFSS для дисков

Механизмы Dynamic Fair Share Scheduling (DFSS) осуществляют распределение аппаратных ресурсов, балансируют их между пользователями, что порой замедляет работу. Чтобы ускорить файловую базу 1С, порой достаточно отключить для дисков, для чего достаточно, вызвав реестр («Win» + «R», в окне «Выполнить» вписать «regedit», нажать «Enter»). В ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk задать «0» в параметре EnableFairShare.

Отключить сжатие данных

Чтобы ускорить базу 1С, можно попробовать отключить сжатие данных для каталогов, где располагаются файлы БД. При включенной опции операционная система производит дополнительную обработку файлов, что замедляет процесс записи (хотя и экономит пространство на диске). Для отключения этой опции открываем свойства каталога (DATA Properties), на вкладке «Общие» (General) нажимаем «Другие» (Advanced Attributes), снимаем (если установлен) флажок «Сжимать содержимое для экономии места на диске» (Compress contents to save disk space).

Задать степень параллелизма

С помощью параметра «Максимальная степень параллелизма» (Max degree of parallelism) задается, во сколько потоков может выполняться один запрос. Так, если в поле стоит «0», то это означает, что сервер автоматически определяет это число. При использовании 1С оптимальным параметром будет «1».

Конечно, это далеко не все методы разогнать 1с, ускорить SQL, существует множество вариантов решения данной проблемы, правда, их реализацию лучше поручить техническим специалистам. Неумелое вмешательство в работу платформы может повлечь за собой потерю ценных данных и аварийную остановку ПО, а с ней – и работы в целом. Предлагаем квалифицированное и всестороннее обслуживание программ семейства «1С» – поручите техническую сторону дела нам, высвободив время для решения по-настоящему важных вопросов.

Определение имен таблиц MSSQL

Структура базы данных 1С весьма запутана и состоит из малозначимых для человека названий. 1С содержит функцию определения структуры хранения по имени объекта. В основу разработки положена эта функция ПолучитьСтруктуруХраненияБазыДанных, которая согласно русскому названию возвращает описание структуры. В этой структуре важны 2 поля Назначение, которое должно быть равно «Основная», и название таблицы ИмяТаблицыХранения.

Определение смещения дат

Таблица _YearOffset содержит число, обозначающее смещение года дат. Оно принимает значение 0 или 2000. Так со смещением 2000 дата 01.01.2014 будет храниться в базе данных как 01.01.4014. Соответственно при отборе по датам (удаление происходит за период времени) нужно учитывать смещение. Смещение можно получить следующим кодом 1С:

Установка пометки на удаление документов

Имея названия таблиц документов и зная, что поля _Date_Time, _Marked и _Posted отвечают за дату, отметку об удалении и отметку о проведении соответственно, можно одним SQL-запросом пометить их все на удаление. Делается это так:

Установка пометки на удаление в журналах документов

Не смотря на установку отметки на удаление у документов, в журналах документов хранятся дубли отметок об удалении на каждый документ. Список журналов, где участвует документ можно получить из метаданных документа так: Метаданные.ЖурналыДокументов
Отметка на удаление через поля _Marked и _Posted происходит аналогично через команду:

Удаление движений регистров

При удалении документов 1С удаляет движения документа по регистрам. В случае прямого доступа эти движения нужно удалить самостоятельно. Список регистров можно получить через метаданные ДокументМетаданные.Движения.
Команда, которой выполняется удаление движений следующая:

Заключение

Как оказалось, добиться убыстрения работы 1С примерно на 2 порядка не так сложно, достаточно выполнить 3 вида команд. В конечной обработке логика расширена за счет выбора документов по видам, добавлением таймаута, добавлением транзакции, пакетным выполнением команд.

PS. Список возникающих проблем и пути устранения:
1. Обработка игнорирует документы, где запрещено проведение, например, корректировка записей регистров. В корректировке записей регистров удаление документа связано со снятием активности записей регистров.
2. Результат удаления не отражается в планах обмена. Решается одновременным запуском обработки в связанных базах.
3. Не затрагивает таблицы итогов. Решается пересчетом итогов через Конфигуратор-Тестирование и Исправление-Пересчет итогов.

Постоянно сталкивался с высказываниями ИТ специалистов «сеть нагружена на 20%… процессоры на 50%… очередей к дискам мало… Значит сеть и сервера справляются… смотрите код в 1С проблемы исключительно там».

На самом деле происходило следующее ( сервер 1С и SQL разнесены на разные компьютеры): сеть практически использовалась по максимуму(эти "20% загрузки сетевого интерфейса" = «20% полезные данные» + «80% потеря на служебной обработке»). И соответственно из-за малой ширины канала обмена «полезными» данными — SQL сервер с «Сервером 1С» постоянно ожидали друг друга, что вело к малой утилизации ресурсов CPU и дисковой системы.

Ведение: Сначала хочу заострить внимание на том что же такое 1С платформа?.

Программист в среде 1С — пишет объектную логику, а за сборку/разборку и запись объектов в «плоский вид» по таблицам базы данных отвечает сама платформа.

Основные "+" и "-" с точки зрения ORM:

"+" Программист в среде ORM получает преимущество в скорости разработки приложения из-за уменьшения количества кода и его простоты по сравнению с исключительно реляционным программным кодом (пример SQL запросы). А также освобождается от написания кода работающего непосредтсвенно с записями в таблицах Реляционной СУБД.* 1

"-" Сложности для создателей «платформ» ORM и проблемы производительности:

Использование реляционной базы данных для хранения объектно-ориентированных данных приводит к «семантическому разрыву», заставляя программистов писать программное обеспечение, которое должно уметь как обрабатывать данные в объектно-ориентированном виде, так и уметь сохранить эти данные в реляционной форме. Эта постоянная необходимость в преобразовании между двумя разными формами данных не только сильно снижает производительность, но и создает трудности для программистов, так как обе формы данных накладывают ограничения друг на друга.

*1«Уточнение». Несмотря на то, что 1С 8.х позволяет работать с реляционно-подобным кодом (только чтение) в объекте 1С «Запрос» — это все-таки не напрямую один-в-один транслируемый в реляционную СУБД запрос к таблицам хранения данных, а прежде всего «Объектный запрос» — также не минующий стадию сборки разборки объектов. Поэтому зачастую вместо много-тысяче строчных «Объектных запросов» — наиболее оптимально по быстродействию кода и скорости разработки — написать объектный не ряляционно-подобный код.

Глава 1: Расмотрим модель клиент-серверной 1С 8.х

Отмечу основные «узкие» места влияющие на производительность:

1) Первое узкое место — это коммуникационная среда передачи данных.
На рисунке стрелками показаны потоки обмена данными, где «красные» — это Реляционная СУБД<->Объектная СУБ, «оранжевые» — синхронизация между Объектными СУБД.
Т.к. при использовании отдельных серверов для СУБД и кластеров 1С – коммуникационная среда это сетевые соединения – то существуют существенные задержки в передаче данных многочисленными мелкими порциями – как из-за латентности самой физической реализации интерфейсов, так и из-за латентности узлов в этой сети.

Рассмотрим на примере сетевого стандарта Ethernet Gigabit (график зависимости скорости передачи данных… ниже)
на примере работы Сервера 1С с MS SQL (по умолчанию размер коммуникационных пакетов 4 кб):

На графике видно, что при использовании пакетов ДАННЫХ =4 кб пропускная способность рассмотренной сети всего 250 Мегабит/с. (как правильно заметили в комментария к публикаци: это не пакеты протоколов например уровня TCP, а пакеты ДАННЫХ которые генерируют приложения участвующие в обмене)
…
Из практики: такое разнесение на Два отдельных сервера
MS SQL (сервер №1)< — Ethernet Gigabit ---> «Сервер 1С»(сервер №1)
проигрывало по скорости работы платформы
на 50% варианту MS SQL (сервер №1) < — Shared Memory (без сети через участок памяти) ---> «Сервер 1С»(сервер №1)… и это уже «на одном высоконагруженном пользовательском сеансе»

2) Узкое место — это количество отдельных компьютеров «кластеров 1С», чем их больше тем больше затраты на синхронизацию и как следствие уменьшение производительности системы.

3) Узкое место — количество отдельных процессов сервера 1с, чем их больше тем больше затрат на их синхронизацию… Но тут скорей всего необходимо найти «золотую середину» — для обеспечения стабильности. 2*
2* «Уточнение» — для MS Windows существует такое правило:
Процессы дороже чем потоки, что означает применительно к данному случаю на практике следующее: скорость обмена между двумя потоками внутри одного процесса значительно превышает, скорость обмена между потоками находящихся в разных процессах.

Поэтому например «Файловая 1С 8.х» всегда превышает по скорости однопользовательской работы платформы в клиент-серверном варианте. Все просто т.к. в случае «Файловой 1С 8.х» поток «Реляционной СУБД» общается с потоком «Объектной СУБД» внутри одного единого процесса.

4)Узкое место – одно-поточность пользовательского сеанса, т.к. каждый отдельно взятый — пользовательский сеанс не распараллеливается платформой на несколько, то его работа ограничивается использованием ресурсов одного ядра CPU => следовательно желательна максимальная скорость каждого ядра, в этом случае быстродействие платформы 1C например на 10-ядерном CPU по 1 ггц — будет значительно уступать быстродействию платформы на 4-ех ядерном CPU по 3 Ггц – естественно до определенного количества потоков.

Глава 2(Итог): Рассмотрим не масштабируемый и масштабируемый варианты — наиболее эффективных схем для платформы 1с 8.х. для OS Windows (пологаю для Linux ситуация аналогична)

1-Вариант(не масштабируемый). В расчете на 100 «высоконагруженных пользовательских сеанса»

1) эффективен обычный 2-ух сокетный сервер с 4-ех ядерными CPU по 3 Ггц.

2) быстрая дисковая система на SSD

3) MS SQL < — Shared memory --> «Сервер 1С»

2-Вариант(масштабируемый). начиная со 100 «высоконагруженных пользовательских сеанса» и далее….
Тут логичней всего пойти по пути немецкой 1с-ки «Sap HANA»))
Собирать модульный «Супер-компьютер» от фирмы SGI – состоящий из «лезвий» на 2-х сокетных материнских платах, каждое лезвие соединяется друг с другом сложной топологией сверх-быстрого интерконнекта на основе NUMA-чипов, и все находится под управлением единой OS. Т.е. программы внутри такого сервера по определению имеют доступ к ресурсам любого «лезвия».

1) добавляем «лезвия» по необходимой нагрузке… из расчета примерно одно «лезвие» на 100 пользователей.

И к нам они обратились в таком формате: «У нас все было отлично, но вдруг начали возникать проблемы, причем значительные».

Начали разбираться. С чем столкнулись?

• В их оперативной базе использовался регистр накопления, где было более миллиарда записей – это был такой «собирательный образ», с которым работало очень много пользователей. Возвращаясь к докладу Андрея Бурмистрова, хочу сказать, что в этом регистре было включено разделение итогов, и когда мы в нем измеряли количество записей итогов, их было 1.2 миллиарда. Это вообще «жесть». Но проблема была скорее не в количестве записей этого регистра, сколько в том, что большая часть запросов выполнялась именно к нему.
• Работали с этим регистром, по факту, тригруппы пользователей:
  • Первая группа пользователей – это, так скажем, группа пострадавших, их работа заключалась в заведении договоров на эти микрофинансовые займы. Сами они создавали минимальную нагрузку на систему, но когда из базы формировались какие-то сложные выгрузки, они ничего не могли делать, у них работа просто вставала.
  • Вторая группа пользователей – это аналитики, основные зачинщики проблем. Они создавали на базу достаточно большую нагрузку, потому что делали оперативные отчеты, которые формировались по 3-5 минут. В течение этого времени с базой вообще никто не мог работать, а аналитикам эти отчеты были нужны достаточно часто.
  • Третья группа пользователей – это группа коллекторов. Они делали еще более дикие выборки, общее время формирования которых доходило до получаса. Но им оперативные данные были не нужны, и в этом была принципиальная разница между второй и третьей группой, поэтому мы с ними работали очень по-разному.

  
  

  Как поступает сервер 1С в случае, когда регламент MS SQL не успевает сделаться в нужное время? Как вообще работает сервер, когда у вас столько записей в будущем? Например, если вы захотите взять данные на сегодня (сегодня у нас 26 октября), а у вас последние ежемесячные итоги рассчитаны на конец сентября, тогда сервер будет всегда пытаться брать текущие итоги. Но если в обычной деятельности текущие итоги – это конец октября (что-то близкое к текущей дате), то в их случае это было сильно далеко впереди. К тому же текущие итоги, по сути, всегда берутся на конец эпохи, на 3099 год. И в данном случае, если бы даже у нас ежемесячные итоги бы рассчитаны на конец сентября, сервер все равно бы лез максимально вперед в будущее, где находятся самые последние записи. И потом такой вот лавиной цунами выкручивал бы оттуда дикие обороты полностью всего до текущей даты. Это собственно и происходило. Но даже если бы у них не было записей в будущем, то из-за того, что ежемесячные итоги у них были два с половиной года назад, а работали они чаще всего с текущими датами, они бы все равно никакого профита не получили – не смогли бы просто. А тут еще и такая ситуация наложилась.

  Принятые решения по оптимизации

  
  

  Конечно, ситуация печальная, но что с ней делать-то?

  Закономерным решением было:

  • Рассчитать ежемесячные итоги. Конечно, их нужно рассчитать не все сразу, а последовательно, потому что этот процесс занимает много времени, а регламентное окно узкое.
  • И, конечно же, надо было полностью снести текущие итоги – прямо снести и отключить. Почему? Причины две. Помимо того, что они там создают паразитическую нагрузку, они же еще и постоянно плодятся – пока они включены на регистре, эти паразитические записи будут постоянно появляться. А если еще и сервер 1С будет брать всегда именно их, то от них очевидно, надо избавляться.
  • Ну и все-таки надо обновить статистику.

  
  

  Но все это не просто. Я бы даже сказал, что это очень непросто, потому что если использовать стандартный подход, который исповедует 1С, то у нас бы все это заняло около 13 часов. Что бы при этом происходило?

  • При стандартном отключении текущих итогов на регистре из него последовательно начали бы удаляться записи. Построчно. А вы представляете, сколько там записей – там 1.2 миллиарда. Даже на мегамощностях заказчика на это ушло бы 13 часов. Мы предложили заказчику: «давайте отключим это по всем канонам 1С». Они говорят: «нет, нам такой вариант не подходит, давайте что-то думать дальше».
  • И кстати, про интерфейсные настройки MS SQL – в сервереMSSQL нет никакой такой интерфейсной настройки, которая бы позволяла обновлять какие-то таблицы выборочно. А полное обновление статистики происходит целиком по всему и занимает достаточно большое время. Соответственно, просто запуск регламента еще не означает, что он будет успевать проходить.

  
  

  В результате, мы приняли решение просто снести таблицу итогов и напрямую сделали truncate table из MS SQL. Сразу оговорюсь, что трюк был выполнен профессиональными каскадерами, в домашних условиях не повторять. Тем более что 1С не просто так запрещает прямые запросы к базам данных. Почему? Потому что текущие итоги и обычные ежемесячные итоги – это одна и та же таблица. И когда мы ее снесли, снеслись также и ежемесячные итоги. А 1С помнит, что там были итоги, рассчитанные два с половиной года назад. И она пытается к ним обратиться, а база ей отвечает: «какие итоги? тут ничего нет». И все, коллапс. Такие случаи надо предусматривать.

  Естественно, я не рекомендую прямые запросы к базе, но у нас была вынужденная ситуация. Наверное, к этой возможности можно иногда прибегать, если продумать все возможные последствия. Потому что в таких ситуациях целостность данных оказывается под очень большим вопросом.

  
  

  И следующим шагом мы обновили статистику. Для этого мы использовали скрипт, текст которого приведен на слайде. Конечно, это не наше открытие, в интернете есть различные варианты этой настройки. Мы, по сути, просто взяли в основу то, что нашли, и доработали под свои нужды, чтобы обновлять статистику только по тем объектам, которые были изменены. В результате регламент стал проходить достаточно быстро – за считанные минуты. Кому надо – пользуйтесь. В интернете есть разного рода альтернативы.

  После этого нагрузка на базу в целом резко уменьшилась, и если изначально запросы выполнялись по 3.5-5 минут, они стали отрабатывать гораздо быстрее, чаще всего секунд за 15.

  «Подводные камни»

  
  

  Но все равно остались и аномальные случаи, когда база на небольших запросах «подвисала» очень долго.

  Начали разбираться, и выяснилось, что нагрузка увеличивалась за счет того, что в системе неконтролируемо использовались внешние обработки и отчеты, у которых были разные версии, потому что заказчик их постоянно допиливал, менял. А когда у тебя онлайн в базе работает почти тысяча пользователей, контролировать запуск различных версий внешних обработок очень сложно. И если этот вопрос не решить сразу жестко, будут продолжать использовать «кто в лес, кто по дрова». В результате мы решили использовать те же самые отчеты и обработки, но прикрепленные к системе. И если они дорабатываются, то просто выпускается новая версия и сразу прикрепляется. Потому что использовать внешние обработки, свободно распространяемые по почте или как-то еще – это плохой вариант, он может приводить к большим печалям на больших нагрузках.

  
  

  Казалось бы, наконец, все заработало: запросы начали выполняться быстро, оперативная работа пошла, и заказчик вздохнул с облегчением.

  
  

  Но не тут-то было. Приходит начало месяца и у заказчика опять все «ложится». Там была печаль печальная.

  
  

  Обычно при обращении к оперативным объектам в базе – открываешь, одна секунда, и ты уже все получил. А тут они начали открываться по 16, по 25, а некоторые еще и больше секунд. Откуда такая аномалия – непонятно. Заказчик говорит: «Вы нам сказали рассчитывать итоги и обновлять статистику – мы все делаем. Вот вам план запроса, только решите проблему, потому что у нас начался сезон, и мы однозначно не можем тратить на это время. У вас есть полчаса, час, давайте, что-то решайте».

  Мы посмотрели план запроса – он вообще какой-то дикий, аномалия налицо. Вроде бы и статистика обновлена по регламенту, и итоги рассчитаны – все должно быть нормально. В результате обсуждения решили посмотреть, когда, в каком часу была обновлена статистика – и увидели, что она была обновлена ночью, а итоги рассчитаны уже утром, что и порождало такую аномалию. После этого мы уже известным вам скриптом вновь обновили статистику, и все начало «летать».

  Но возник закономерный и интересный вопрос – а как так получилось? Откуда в базу закралась такая барабашка? Почему так себя ведет планировщик? Что такое вообще обновление статистики для планировщика?

  
  

  Вообще планировщик – это конечно огромный черный ящик и сервер 1С с ним никак не взаимодействует. Планировщику вообще не интересно все внешнее воздействие – его не волнует, как вы написали запрос или какие вы отборы там поставили. На то, как он формирует план запроса, вы вообще никак повлиять не сможете. По факту, обновление статистики и создание индексов на таблицах – это единственное, или почти единственное, что может повлиять на поведение планировщика.

  Как планировщик работает?

  • Пока вы статистику не обновили, он видит, что есть итоги на конец сентября, и у него указано, какой там индекс, он знает, что раз таблица огромная, искать надо в индексе. Он находит какую-то запись, выбирает из нее все связанные подзапросы, получает данные, и никаких проблем нет.
  • А тут происходит расчет итогов, который добавляет в таблицу сколько-то записей, о которых планировщик и понятия не имеет. И он начинает просто как слепой шариться по этой таблице, и искать, а где там нужные ему записи?
  • А когда ты статистику обновляешь, планировщик прозрел, увидел, что все понятно, вот он, индекс, можно делать поиск по индексу и сканировать всю таблицу ему уже не надо. Он нашел нужную запись и ее отдал.

  Когда таблица 10 тысяч записей – это может быть не критично. А когда в таблице сотни миллионов записей и итогов за один месяц там очень много, тогда это становится колоссально критично. Поэтому очень важно понять эту логику, как планировщик все это подтягивает. Ну и собственно, сервер 1С так же работает, потому что он тоже не особо напрягается, думая, как MS SQL сервер будет формировать эти выборки.

  Инструменты для изучения проблем производительности

  
  

  Теперь важно обратиться к тем инструментам, которыми мы пользовались для этого случая, и вообще для всех случаев пользуемся.

  Вроде все знают, что существует корпоративный инструментальный пакет, но в реальной жизни, чтобы ты пришел к заказчику и сказал – вот он, КИТ, все настроено, все классно, открывай, анализируй, все тебе дано – так в реальности не бывает вообще. И даже настроенный профайлер – это уже чудо. Поэтому анализ начинается, конечно же, совсем по-другому.

  Например, консоль сервера. Этим инструментом очень часто пренебрегают, а ведь по факту он дает ответ на многие вопросы. В нем можно посмотреть какой сеанс, какую нагрузку создает, где какие аномалии. Где у тебя длительный запрос к базе данных, а где у тебя уже длительный ответ от сервера 1С, где математика, а где диски – и дальше уже в эту сторону анализировать. Более того, в консоли сервера можно «отрубить» сеанс, который создает аномальную нагрузку, сохранив тем самым работоспособность базы. Убили сеанс, сохранили работоспособность, а потом занимаемся анализом, потому что бывает, что базу нельзя просто так рестартовать.

  И здесь важно еще вот о чем сказать. Убивать сеансы – это замечательная возможность, но если вы этим сеансом проводили какой-то длительный регламент типа расчета себестоимости выпуска, восстановления последовательности партионного учета или что-то еще в этом духе, то вам придется все начинать заново, потому что никакой результат не сохранится – это очень важно иметь в виду. Потому что вся операция расчета себестоимости может длиться 8.5 часов, а если она длилась 8 ч, и вы решили ее прервать, чтобы дать работать пользователям, то вам придется все начинать заново. А надо было всего-то подождать полчаса и все.

  
  

  Следующий очень важный инструмент – технологический журнал 1С. Он вроде бы тривиальный, но, тем не менее, помогает решать огромное количество вопросов. Здесь на экране показана настройка – тут максимум 15 строчек кода. С помощью этой настройки вы можете вывести все события выполнения запроса, которые длились более 10 секунд, тем самым, сразу отсечь все то, что неинтересно, и проанализировать только длительные запросы. И дальше уже, если будет нужно, погрузиться в их какой-то более детальный анализ.

  И еще один инструмент – это SQL Management Studio, тоже очень интересная вещь, особенно в контрасте того, что профайлер MS SQL надо настраивать, на это требуется время, а его иногда нет. А Management Studio – это достаточно простой инструмент, и более того, он включен в любую версию MS SQL (и в SQL Express в том числе – он там в комплекте не идет, но его можно установить, лицензия это позволяет делать). Пользоваться им достаточно удобно и легко.

  Ну и конечно, если время позволяет, настраиваем профайлер MS SQL, чтобы он нам выдавал то, что мы хотим видеть, потому что многие ответы находятся только там. Тем более что в отличие от технологического журнала 1С, он позволяет увидеть все запросы – это, наверное, чуть ли не главное преимущество MS SQL. У технологического журнала 1С есть ограничение, что он позволяет увидеть только те запросы, которые были успешно выполнены – это одно из серьезных ограничений при анализе подобных аномалий для СУБД PostgreSQL. А профайлер MS SQL позволяет увидеть все запросы. Можно запустить запрос, тут же его отключить, получить полный план запроса и анализировать его дальше, что там вообще происходит. Это очень большое преимущество и важно правильно этим пользоваться.

  Заключение

  Весь наш опыт подсказывает, что все гениальное – просто, и что чудеса очень часто решаются достаточно простыми и тривиальными способами.

  Еще раз подытожим наши выводы

  • Важно то, что не все итоги одинаково полезны. В данном случае, очевидно, что текущие итоги – это явный паразит в базе, с которым жить и мириться никак нельзя, его надо беспощадно сносить, отключать и т.д.
  • А ежемесячные итоги как раз наоборот – крайне полезная вещь, без которой жить бывает очень сложно. Если у вас в регистрах накопления очень много записей без итогов – это печаль и боль.
  • Что еще очень важно – это последовательность расчета итогов и обновления статистики. Потому что у заказчика даже мысли не промелькнуло по поводу того, что в последовательности его действий что-то может быть не так. Потому что, казалось бы – база в 2 терабайта, ну записали мы итогов на месяц, ну и что, почему это так должно сказаться на производительности? А вот может так сказываться. Последовательность действий здесь имеет крайне большое значение. И если вы используете какое-то решение «из коробки», где все по порядку настроено, то все будет работать хорошо. А если вы просто будете кусочно использовать разного рода инструменты в хаотичном порядке, то можете не достигнуть позитивного эффекта.

  Лично от себя хочу добавить, что, несмотря на то, что мы достаточно давно уже занимаемся оптимизацией (в сумме, наверное, больше двух лет), меня искренне удивляет тот факт, что при решении большинства проблем помогает просто расчет итогов и обновление статистики. Прямо серьезно. Мало кто этим озадачивается – либо просто забывают, либо что-то еще. Поэтому не забывайте, обращайте внимание, это крайне важно.

  Пользуйтесь инструментами, будьте молодцами!

  Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER. Больше статей можно прочитать здесь.

  В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

  Читайте также:

    
  • Как найти гиперссылку в excel
    
  • Voice recorder что это за программа на андроид
    
  • Как посмотреть серийный номер adobe acrobat pro dc
    
  • Самый молодой браузер ответ на вопрос теста
    
  • Интегрированная система программирования включает компонент для перевода исходного текста программы