Как ускорить реструктуризацию 1с
(0) Как вариант - не добавлять реквизит в документ, добавить только поле на форму, писать его в отдельный регистр и при открытии формы восстанавливать это значение. База конечно распухнет, но дисковое место - вещь не слишком дорогая, а от реструктуризации и простоя базы уйдешь.
Да наверное действительно проще регистры сведений и потом бежать)) от воплей регистратуры. Поддерживать работу неподчиненых регистров ещё та забава ))
(11) А вы что каждый день добавляете реквизиты?. Раз в месяц запланируйте на час тех работы. Если такой возможности нет, то извращайтесь:) и потом отбивайтесь от регистратуры..
Понаделайте загодя реквизитов типа строка, при необходимости добавления нового реквизита используйте их, в строку пишите УИД, и со значениями через УИД работайте:)
(11) полчаса? Раз в месяц остаться после окончания рабочего дня и выполнить все, что требуется с базой - такой вариант не рассматривается?
(0) Когда процесс будет занимать многие часы, тогда можно задуматься. А так - ночью точно можно час выделить. Вряд ли у вас работа 24/7.
(15) - сразу в рабочую что ли. лично у нас с начало в тесте доработки делаем пользователи тестируют, а в запланированиое окно - переносим доработки в рабочую базу.
ну и стараться "доп.реквизиты" не изменять!
(11) У нас в центральной базе Астора в крупной продуктовой сети реструктуризация иногда за ночь не выполнялась или по памяти вылетала - приходилось делать средствами скуля для ускорения, а у вас пока совсем незначительные временные затраты.
В текущем варианте просто переносите обновления, требующие реструктуризации на нерабочее время. А вот когда времени перестанет хватать, будете искать уже другие решения (регистры сведений вместо реквизитов, реструктуризация средствами скуля и т.д.).
Как уже сказали, человеческий выход только в КОРП реализовали.
В ПРОФ создается копия таблицы.
Пол-часа и пару миллионов записей - это еще цветочки. Плюс есть некоторый запас на апгрейд/оптимизацию железа.
Когда действительно прижмет - остаются суровые варианты с подменой конфы и ручным добавлением колонки в БД.
(0) Создать копию таблицы, перенести в нее данные из исходной (insert into . select). Исходную очистить (truncate table). Выполнить реструктуризацию. Перенести данные обратно. Заполнить новую колонку данными по-умолчанию (если надо). Готово.
Ускорено выполнение реструктуризации информационной базы при использовании СУБД Microsoft SQL Server и IBM DB2.
На скорость работы 1С влияют разные факторы: от «кривых» запросов до оборудования. Это означает, что оптимизацию лучше проводить комплексно. А еще – чтобы разобраться с нуля во всех возможных причинах замедления, потребуется некоторое время.
Но есть несколько способов, которые заставят 1С работать быстрее минимальными усилиями: нужно просто поменять некоторые настройки, отключить кое-какие процессы… : )
В этой статье разберем 7 таких приемов. Минут 15 на чтение – и можно смело идти применять их на практике!
Даже если Вы пока не замечаете проблем с 1С, прочитайте статью. Убедитесь, что в настройках Вашей системы нет ошибок и все возможности платформы используются по максимуму – чтобы и в будущем проблем с производительностью не было : )
1. Настроить параллелизм в MS SQL Server
Если запрос читает большой объем данных, чаще всего это говорит о том, что он не очень оптимальный.
По правилам следовало бы такой запрос найти и оптимизировать, чтобы все жили долго и счастливо. К сожалению, наш мир не идеален, и далеко не всегда есть возможность переписать медленный запрос. Иногда с ним приходится мириться.
Для «тяжелых» запросов в MS SQL предусмотрен механизм распараллеливания. Он автоматически делит запрос, который читает большой объем данных, на несколько потоков и выполняет их параллельно.
Проблемы из-за распараллеливания
По идее распараллеливание должно ускорять выполнение запроса. Так и есть. Однако оно повышает нагрузку на процессор, поэтому, если использовать механизм необдуманно, это может приводить к негативным последствиям.
Например, бывает, что «тяжелый» запрос, разделившись на потоки, начинает загружать несколько ядер процессора, что сказывается на общей производительности системы.
Распараллеливание может стать причиной ожиданий на СУБД с типом CXPACKET: при параллельном выполнении запроса одни потоки будут ждать исполнения других, что также снизит скорость работы.
К тому же иногда из-за ошибки распараллеливания по вине СУБД происходит дедлок. Дедлок подразумевает, что разные потоки одного запроса блокируют друг друга.
Что предлагают в документации
В официальной документации говорится о том, что лучше вообще отключить механизм распараллеливания, установив для базы данных настройку Max degree of parallelism = 1. В этом случае один запрос будет выполняться в один поток, что позволит избежать проблем, описанных выше.
Рисунок 1. Настройка параллелизма в MS SQL Server для выполнения запроса на одном ядре (в один поток)
Ситуации, при которых не стоит отключать распараллеливание
Официальная рекомендация действительно справедлива, но лишь отчасти. Ее можно применить, если, например, постоянная нагрузка на процессор выше 30%. В этом случае включение параллелизма может еще больше нагрузить процессор и совсем «положить» его.
Но такие ситуации — редкость. Зачастую на современных серверах СУБД процессоры не загружены более чем на 20–30%. У них остается еще достаточный запас по мощности, поэтому внезапная нагрузка на сервер из-за «тяжелого» запроса несильно повлияет на остальных пользователей.
Приведем несколько ситуаций, при которых не стоит отключать распараллеливание:
- Описанный в документации случай, когда один запрос при распараллеливании замедляет всех — не самый распространенный паттерн. Чаще неоптимальный запрос выполняется медленно в один поток, хотя мог бы выполняться гораздо быстрее в несколько потоков, при этом несильно загружая процессор.
- Если отключить распараллеливание на уровне сервера, тогда и регламентные операции по умолчанию тоже будут выполняться в один поток. Чтобы этого избежать, нужно указывать настройку распараллеливания (MAXDOP = 0) для регламентного задания дефрагментации/реиндексации, чего многие, к сожалению, не делают.
- Новый механизм реструктуризации работает гораздо быстрее, если включено распараллеливание. Об этом сказано и в документации. Там же предлагается каждый раз перед реструктуризацией включать параллельность, а после обновления — отключать. Но все мы люди, и часто разработчики просто забывают установить параметр в нужное значение. В итоге реструктуризация больших таблиц даже с новым механизмом идет медленно.
- Ожидания CXPACKET зачастую интерпретируются неправильно. Их наличие далеко не всегда говорит о проблемах с распараллеливанием. Если хочется больше узнать об этом, подробности Вы найдете в статье Troubleshooting the CXPACKET wait type in SQL Server.
Так что же делать?
Мы разобрались, почему просто отключить механизм распараллеливания и забыть о нем — не лучшая идея. Что же тогда делать?
В качестве решения можно рассмотреть следующий подход: оставить настройку Max degree of parallelism = 0, но установить настройку Cost threshold for parallelism = 30.
Рисунок 2. Настройка параллелизма в MS SQL Server для выполнения запроса на нескольких ядрах (в несколько потоков)
Такая настройка означает, что MS SQL будет самостоятельно решать, сколько потоков использовать для выполнения одного запроса, но распараллеливание будет включаться, только если стоимость плана запроса будет выше 30.
Стоимость плана измеряется в неких условных единицах и отражает, насколько «тяжелым» является запрос для исполнения. Чем выше стоимость, тем сильнее запрос нагружает систему. При настройках по умолчанию параллельность включается, если стоимость плана выше 5. Значение 30 — не какая-то сакральная величина: просто, с точки зрения автора, оно подходит для большинства систем.
Благодаря такой настройке параллельность будет использоваться только для действительно сложных запросов. Запросы полегче продолжат выполняться в один поток — им распараллеливание все равно не дает заметного ускорения.
Следует отметить, что это решение не освобождает от необходимости оптимизировать «тяжелые» запросы, но оно хотя бы не мешает другим операциям выполняться быстро.
2. Проверить, сколько ядер используют MS SQL Server и 1С
Если у Вас мощный сервер — это еще не значит, что Вы используете его на полную мощность.
Причины у этого могут быть разные. Например, такое происходит, если при настройке окружения не учли ограничения MS SQL или приобрели не ту версию 1С.
Давайте разберем подробнее оба случая.
Проверить, сколько ядер используют MS SQL Server
Разные версии MS SQL имеют разные ограничения. Их важно учитывать при настройке окружения. Например, версия MS SQL Standard 2016 может использовать либо 4 сокета, либо 24 ядра, исходя из того, чего меньше (данные из таблицы на сайте Microsoft Ignite).
Рисунок 3. Ограничения разных версий MS SQL Server
Допустим, у Вас есть многопроцессорный сервер, т. е. сервер с несколькими сокетами. На нем размещена виртуальная машина, на которую установлен сервер MS SQL. При этом в виртуальной машине настроено 12 процессоров по 2 ядра. Сколько ядер будет использовать MS SQL?
MS SQL будет использовать 4 процессора, следовательно, всего 8 ядер из 24. Остальные ядра будут не загружены. Правильным решением будет настроить на виртуальной машине 4 процессора по 6 ядер на каждом, либо 2 по 12 ядер. В этом случае MS SQL сможет использовать все 24 ядра.
Рисунок 4. Неправильная и правильная настройки процессоров. В схеме № 1 MS SQL использует только 4 процессора из 12, а в схеме № 2 — все 12
Вот пример неверной настройки, когда вместо 12 ядер в виртуальной машине было настроено 12 сокетов — по одному ядру на каждый сокет. Видно, что загружены только 4 ядра из 12.
Рисунок 5. Неравномерная загрузка ядер при неправильной настройке виртуальной машины
Чтобы узнать, сколько логических процессоров (ядра, в том числе и гиперпоточные) задействует Ваш экземпляр MS SQL, следует выполнить следующий запрос
Рисунок 6. Отображение реального количества логических процессоров, используемых MS SQL Server
SQL Server detected 1 sockets with 4 cores per socket and 8 logical processors per socket, 8 total logical processors; using 8 logical processors based on SQL Server licensing. This is an informational message; no user action is required.
Из этого текста следует, что все хорошо — число найденных ядер равно числу используемых.
SQL Server detected 4 sockets with 12 cores per socket and 12 logical processors per socket, 48 total logical processors; using 24 logical processors based on SQL Server licensing. This is an informational message; no user action is required.
В этом случае половина процессорных мощностей простаивает.
Проверить, сколько ядер используют 1С
Важно помнить, что у 1С тоже есть ограничения по количеству используемых ядер. Например, версия ПРОФ может использовать только 12 ядер и, если поставить ее на 24-ядерный сервер, то половина процессорных мощностей будет простаивать.
Если на сервере больше 12 ядер и Вы хотите, чтобы 1С использовала их все, необходимо приобрести версию КОРП.
3. Проверить настройку Turbo Boost
Для сервера 1С критически важна частота процессора — чем она выше, тем лучше.
В большинстве процессоров есть возможность динамически менять частоту в зависимости от нагрузки — это позволяет процессору работать на частоте выше номинальной. У Intel такая технология называется Turbo Boost, у AMD — Turbo Core.
Рисунок 7. Схема работы технологии Turbo Boost
Turbo Boost включается в BIOS, но чтобы он полноценно работал, необходимо в настройках электропитания операционной системы установить режим электропитания Высокая производительность. Если этого не сделать, ОС будет занижать частоту процессора для экономии электричества.
Рисунок 8. Установка режима электропитания
4. Включить механизм версионирования в MS SQL для 8.2
Все еще много конфигураций работает в режиме совместимости с 8.2 или на самой платформе 8.2.
В управляемом режиме блокировок в 8.2 читающие запросы в транзакции устанавливают блокировки. Из-за этого при параллельной работе нескольких пользователей пишущие транзакции блокируют читающие, что приводит к излишним ожиданиям на блокировках.
Если у Вас такая конфигурация и в ней используется режим управляемых блокировок, необходимо обязательно в MS SQL включить режим версионирования READ_COMMITTED_SNAPSHOT.
Это можно сделать с помощью следующей команды:
При этом в базе не должно быть пользователей, иначе команда не будет выполнена.
После выполнения команды поведение системы будет аналогично 8.3: читающие запросы в транзакции не будут блокировать данные, следовательно, количество ожиданий на блокировках сократится.
Проблема в том, что периодически, например при обновлении, платформа будет возвращать прежний режим. Необходимо постоянно следить за тем, чтобы данный режим был включен. Например, можно сделать регламентное задание на MS SQL, которое будет регулярно выполнять вышеприведенных запрос.
5. Проверить выполнение регламентных операций СУБД и 1С
Как на СУБД, так и на 1С обязательно должны выполняться регламентные операции. Настройки регламентных операций — тема обширная и выходит за рамки этой статьи. Просто важно помнить, что без регламентных операций производительность системы будет падать.
Зачастую о регламентах забывают при апгрейде сервера, обновлениях, смене СУБД или смене паролей для запуска служб MS SQL, поэтому даже если все было настроено, лучше проверить еще раз, что регламентные операции по-прежнему выполняются.
Регламентные операции для СУБД
Для СУБД обязательными являются обновление статистики и дефрагментация/реиндексация индексов.
Обновление статистики — важнейшая регламентная операция. Если статистика не актуальна, то запросы на больших таблицах будут выполняться медленно.
Фрагментация индексов негативно влияет на скорость работы дисковой подсистемы и на объем оперативной памяти. Чем выше фрагментация на диске, тем больший объем оперативной памяти будут занимать данные.
Регламентные операции для 1С
В 1С в первую очередь имеются в виду сдвиг границы и пересчет итогов.
В идеале граница рассчитанных итогов должна быть на конец предыдущего месяца — тогда остатки за предыдущие периоды будут получаться быстро.
Рисунок 9. Установка периода рассчитанных итогов
Не стоит устанавливать период рассчитанных итогов далеко в будущем, иначе любая запись в регистр будет вызывать обновление итогов за все будущие месяцы. Это не только замедлит работу пользователя, но и увеличит время блокировки данных, что может привести к ожиданиям на блокировках.
Пересчет итогов также является важной регламентной операцией. При ее выполнении из таблицы удаляются нулевые итоги, которые могут занимать значительный объем. Также пересчет сворачивает строки, возникающие при работе механизма разделения итогов, что тоже уменьшает размер таблицы.
Полный пересчет итогов на больших базах занимает много времени, поэтому часто его предпочитают вообще не делать. Однако эту операцию необходимо проводить регулярно, чтобы не накапливать большое количество строк с нулевыми итогами. В качестве альтернативы можно выполнять пересчет только текущих итогов — эта операция выполняется гораздо быстрее.
6. Использовать таблицы итогов регистров сведений
Можно относительно легко ускорить запросы к срезам регистра сведений, если эти срезы выполняются без указания даты.
Ускорение достигается за счет механизма итогов для среза первых и последних. Если включить эту возможность, будут созданы отдельные таблицы, где хранятся только первые или только последние значения ресурсов по комбинации измерений.
Рисунок 10. Разрешение таблицы итогов регистра сведений
Включение этих флагов потребует времени для реструктуризации, особенно если таблица регистра сведений большая. Иногда это может занять очень много времени, поэтому лучше проводить такое обновление ночью или в выходные — так оно не помешает работе пользователей.
После обновления появятся отдельные таблицы срезов, обращение к которым будет идти, если в запросе не указана дата получения среза. Это сильно ускоряет чтение, особенно когда в регистре десятки миллионов строк и более.
У этого средства есть незначительный минус. На запись в регистр будет уходить чуть больше времени, т. к. помимо основной таблицы нужно будет обновлять и таблицы итогов.
7. Убрать лишнее
Этот способ ускорения системы заключается в том, чтобы отключить все, что не используется, но забирает ресурсы. Особенно это касается типовых конфигураций.
Кому-то покажется, что это совет от капитана Очевидность. Но стоит отбросить сарказм — есть множество баз, в которых работают все стандартные регламентные задания и оставлены настройки по умолчанию.
Проведите ревизию включенных регламентных заданий. Действительно ли все эти задания нужны? Может, часть относится к механизмам, которые Вы не используете?
Ситуация усугубляется, когда на сервере расположено большое количество баз: часть из них для разработки, часть — для тестов, еще часть кто-то когда-то зачем-то создал. В каждой из них выполняются задания, обновление полнотекстового поиска и т. д.
Все это никак не помогает производительности Вашей системы, поэтому стоит отключить все лишнее.
Первое, на что нужно обратить внимание при ревизии — это полнотекстовый поиск. Если он не используется, тогда лучше его отключить, чтобы он зря не «съедал» ресурсы системы.
(нажмите, чтобы увеличить картинку)
Рисунок 11. Отключение полнотекстового поиска 1С
Если же полнотекстовый поиск используется, тогда стоит оставить свойство «Полнотекстовый поиск» в значении Использовать только для тех реквизитов, где он действительно необходим. У остальных объектов следует его отключить.
Чек-лист быстрого ускорения системы
Итак, быстрые способы ускорить систему минимальными усилиями:
- Настроить параллелизм в MS SQL Server.
- Проверить, сколько ядер используют MS SQL Server и 1С.
- Проверить настройку Turbo Boost.
- Включить механизм версионирования в MS SQL для 8.2.
- Проверить выполнение регламентных операций СУБД и 1С.
- Использовать таблицы итогов регистров сведений.
- Убрать лишнее.
К любым рекомендациям следует относиться с осторожностью, в том числе и к тем, что представлены в этой статье. При изменении параметров обязательно наблюдайте за поведением системы, отмечайте произошедшие перемены, делай выводы и, исходя из них, решайте, что делать дальше.
Если 1С тормозит …
Но если Вы хотите подойти к вопросу оптимизации комплексно, рекомендуем наш курс «Ускорение и Оптимизация 1С. Базовый курс 2022».
Нам всем знакомо, как долго может идти обновление: это может занимать несколько часов, а в некоторых случаях – даже
несколько дней.
Однако, его можно заметно ускорить. А для этого нужно немного погрузиться в детали и поговорить о реструктуризации :)
Когда в 1С изменяются метаданные (добавляются документы, реквизиты, индексы), происходит изменение структуры таблиц.
При запуске обновления создается полная копия таблицы, включая индексы – уже с новой структурой. Этот процесс называется реструктуризацией. Разумеется, это все занимает довольно заметное время.
Для случаев, когда объемы данных небольшие, это не так чувствительно.
Но реструктуризация больших баз, в которых содержатся таблицы с десятками миллионов строк, может затянуться на несколько часов или даже дней. Потеря такого количества времени – это уже весьма болезненно.
Еще в платформе 8.3.11 появился механизм, который помогает ускорить реструктуризацию в разы, а в некоторых случаях – на порядки.
С момента выхода этого релиза прошло уже 5 лет, но, судя по вопросам в Мастер-группе, до сих пор многие не знакомы с этим механизмом и не знают о его преимуществах.
Сегодняшнее видео закрывает этот вопрос:
- Объясняем, чем механизм, который появился в 8.3.11, отличается от стандартного способа реструктуризации
- Показываем, как настроить и использовать новый механизм
- Демонстрируем его преимущества и рассказываем о его недостатках
- Объясняем, кому необходим этот механизм, а кому переходить на него не стоит.
Если Вы недовольны тем, с какой скоростью проходит реструктуризация в ваших базах, это видео обязательно к просмотру.
Но даже если Вы работаете в маленькой компании и с этой проблемой еще не столкнулись – рекомендуем все-таки найти 17 минут и посмотреть его. Если завтра Вы поменяете работу и столкнетесь с такой проблемой – не придется волноваться из-за того, что Вы не в курсе таких нюансов.
Ключевые моменты видео:
- 00:00 – Постановка задачи
- 00:28 – Старый способ реструктуризации и его недостатки
- 01:50 – Новый способ реструктуризации
- 02:17 – Плюсы нового способа
- 03:04 – Установка Java на сервер 1С
- 04:18 – Настройка файла conf.cfg на клиенте
- 05:40 – Демонстрация работы старого механизма
- 07:36 – Демонстрация работы нового механизма
- 08:58 – Особенности использования нового механизма
- 09:10 – Включение протокола TCP/IP для СУБД
- 10:52 – Проверка сторонних индексов
- 13:20 – Настройка параметра MAXDOP в MS SQL
- 16:36 – Итоги
Умение находить и устранять причины медленной и нестабильной работы систем на 1С обязательно для программистов 1С
Чтобы Вы могли быстро и без ошибок решать эти задачи, мы выпустили новый курс «Ускорение и оптимизация 1С, 2022».
После курса Вы сможете:
- Оценивать состояние системы в любой момент времени
- Быстро находить причины замедления в программном коде – и сразу писать его так, чтобы замедления в будущем не было
- Отслеживать динамику производительности за определенный период
- Устранять ожидания на блокировках и решать проблемы со взаимоблокировками
Для кого этот курс
- Писать код, за который не стыдно – в нестабильное время особенно важно быть в компании на хорошем счету
- Быть востребованным специалистом – на каждом втором собеседовании спрашивают про умение оптимизировать 1С
- Не терять клиентов из-за того, что «ваша 1С тормозит, а вы ничего не делаете» – это и раньше было нехорошо, а теперь и вовсе непозволительная роскошь
Комментарии / обсуждение (26):
Добрый день, вижу только текстовый материал, по какой-то причине видео отсутствует или не отображается на странице, почему?
Здравствуйте, Анастасия!
Проверили — видео на странице воспроизводится корректно.
Попробуйте почистить кэш и cookie-файлы. Если это не решит проблему, стоит проверить настройки браузера, установленные в нем расширения и плагины либо воспользоваться другим браузером.
Добрый день!
Включал новый механизм. Вроде бы прошло. После пришлось поставить версию java выше 8. Стала появляться ошибка.
Отключил новый механизм, но стала появляться ошибка:
Значит у вас в файле conf по прежнему стоит параметр для использования нового механизма обновления. Проверьте файл conf и на клиенте и на сервере.
Проверял и на сервере и на клиенте. Все убрал. Но все равно выходила ошибка. Выходила не на всех базах, только на одной. Хотя все базы расположены на одном сервере 1С.
Помогла переустановка платформы на сервере.
Оптимизация запросов – один из базовых навыков. Это не прихоть, а необходимость.
Всегда полезно знать, какие запросы в Вашей базе выполняются долго – медленные запросы нужно вовремя находить и устранять. Вопросы по оптимизации запросов уже стандартно задают на собеседованиях.
Наш мини-курс не закрывает полностью проблему оптимизации запросов, но Вы научитесь их отлавливать – и у Вас появится несколько простых рецептов, которые пригодятся в рабочих ситуациях.
Найдете медленные запросы
Узнаете, как анализировать запросы без контекста и работать с индексами.
Готовые алгоритмы
Разберете 4 основные причины замедления запросов и научитесь их устранять.
Инструмент «Монитор»
Освоите авторский инструмент «Монитор», который с высокой точностью «ловит» медленные запросы.
Для кого этот курс:
- Новичкам в оптимизации. Этот мини-курс — отличная возможность быстро (полтора часа) и структурно разобраться с основными приемами поиска медленных запросов и их оптимизации.
- Начали работать в фирме франчайзи. Вы не сможете проработать долго, если будете писать кривые запросы.
- Если Вы отвечаете за поддержку действующей системы. Если что-то работает медленно, то это рано или поздно приведет к конфликту, поэтому нужно уметь исправлять проблемы быстро.
- Если Вы вносите доработки в работающую систему. Чтобы потом не тратить время на переделывание своей работы, лучше сразу учесть задачи по быстродействию.
Программа мини-курса
Занятие 1: Как «поймать» медленные запросы.
Установим и настроим инструмент «Монитор», который «ловит» медленные запросы.
Монитор прост в использовании и у него высокая точность анализа. Ему не требуется подключение к интернету.
Занятие 2: Как анализировать запросы без контекста и работать с индексами.
Научимся проводить анализ на примере запроса с поиском без индекса.
Увидим, как запрос отображается в «Мониторе», и разберемся, почему у запроса может не быть контекста.
Узнаем, как создавать индексы и как ускорить реструктуризацию, обсудим минусы индексов.
Познакомимся с составными индексами, разберем, как они работают и как писать условия, попадающие в индексы.
Занятие 3: Четыре приема оптимизации для ускорения запросов.
Обсудим функцию на поле Условия и как это тормозит запрос.
Поговорим, как можно и нельзя использовать ВЫБОР КОГДА.
Разберем, когда условие ИЛИ безопасно, а когда приводит к проблемам.
Рассмотрим, как оптимизировать подзапросы через временные таблицы.
Для участников курса – Инструмент анализа производительности «Монитор»
Авторский инструмент Андрея Бурмистрова, который помогает решать проблемы производительности 1С.
Монитор позволяет проводить:
- Анализ блокировок 1С и СУБД
- Анализ взаимоблокировок 1С и СУБД
- Анализ запросов
Полный функционал бесплатно доступен участникам в течение трех месяцев.
Бесплатный функционал по анализу запросов остается у слушателей навсегда.
Автор курса – Андрей Бурмистров
В качестве эксперта участвовал в проектах по повышению быстродействия и стабильности компаний Enter, Комацу, Иркутскэнерго и многих других
Проводил корпоративное обучение для компаний Связной, DHL, Иркутская нефтяная компания, QIWI, Тинькофф
Автор курса «Ускорение и оптимизация систем на 1С:Предприятие 8.3. Подготовка на 1С:Эксперт по технологическим вопросам»
Разработал авторский инструмент для выявления и анализа проблем производительности в системах 1С.
Неоднократный докладчик конференций Инфостарт
Лауреат премии Infostart Awards 2021 за вклад в области «Администрирование СУБД. HighLoad оптимизация»
Для прохождения мини-курса Вам потребуются
Зарегистрируйтесь, чтобы пройти мини-курс
Этот курс поставляется в виде последовательной серии уроков, направляемых на электронную почту.
Это а) гарантирует, что Вы не потеряете ссылки, и б) увеличивает вероятность того, что Вы его посмотрите :)
Поэтому, пожалуйста, проверьте почту. Если Вы передумаете и не захотите получать какие-то либо письма от нас – в каждом письме есть возможность отписаться :)
Комментарии / обсуждение (39):
День добрый!
Не могу создать второй кластер, пишет:
Ошибка создания кластера:
Ошибка операции администрирования
Не найдено ни одного сервера с размещенным сервисом
serviceName=ClusterConfigService;
Платформа 8.3.20.1710
Второй кластер желательно но не обязательно, можете создать базу в том же кластере где и рабочие базы.
Так и сделал, но хотелось бы иметь возможность, добавлять кластер, в инете ничего не нашел, то, что предлагают: типа снести папку сервера и запустить заново, переустановка 1с, ничего не помогает, на одной из работ стоит старый релиз 1с 8.3.9.1850, там получилось, на 8.3.20 и 8.3.21 ни как.
А вы в строке подключения к базе порт нового кластера указываете?
Проверьте именно этот момент с портами.
До базы не доходит, т.к. в утилите администрирования сервера 1С не создается второй кластер.
Понял, но к сожалению без подключения ничего конкретного сказать не могу.
Ощущение что у вас вас на сервере не запущен менеджер кластера, хотя такого вроде как быть не должно, либо есть ограничение по портам, поэтому новый кластер и не может быть создан на новом порту, тут только гадать остается ни видя систему.
Добрый день. Не знаю, актуально еще получить ответ на вопрос, но рискну. Я установил “Монитор” на SQL, добавил в настройках монитора сервер SQL, сервер 1С. Протестировал доступы, ошибок нет. Подождал 5 минут. Запустил на выполнение запрос (8 секунд). В настройках было указано “Минимальная длит. запроса” = 1 сек. Однако, на вкладке “Запросы”, после указания периода и базы “Монитор”, по кнопке обновить данные о запросе не появляются, как у вас на видео. То есть не отображается тестовый запрос. Не могу понять, что я делаю не так. Не подскажите?
Здравствуйте.
На закладке Базы нужно выбрать исследуемую базу и нажать Анализ – Анализ запросов, только после этого искать запрос в списке.
А-а-а, вон оно, что. То есть перед каждым анализом необходимо выполнить команду “Анализ запросов”. Как то упустил этот момент. Спасибо за помощь, помогло.
В реальных условиях на боевой базе этого делать не нужно, т.к. периодически запускаются рег. задания и анализ происходит в автоматическом режиме в фоне.
Но на учебной базе что бы не ждать пока запуститься регламент, проще и быстрее запустить анализ по кнопке :)
Дело в том, что 17.12.2021 Вы из одного из наших писем отписались от наших рассылок. По этой причине письма не отправляются Вам на е-мейл.
Если Вы по ошибке отписались от рассылок и хотите восстановить подписку, напишите нам об этом.
Добрый день. Возможно ли на домашнем компьютере установить:
“1С клиент-серверная 8.3.12 или выше
СУБД MS SQL Server 2012 или выше (либо любые другие СУБД, кроме файловой).”
Есть ли в курсе инструкция как это сделать?
Да это возможно, на домашние ОС эти программы спокойно ставятся.
1С является платной, MS SQL Developer бесплатна.
И 1С и MS SQL не вызывает больших проблем при установке, подробных инструкций в курсе нет, но их полно в сети.
Здравствуйте. Для Postgres SQL и ОС Ubuntu этот курс актуален?
Евгений, здравствуйте!
Приемы оптимизации будут актуальны независимо от СУБД и ОС, но вот поставить Монитор на Ubuntu к сожалению не получится.
Вы вполне можете посмотреть видео и попрактиковаться в оптимизации запросов на демо-базе и без Монитора.
Спасибо за бесплатный доступ к информации – компактно, качественно,
профессионально!
Мне, как самоучке в 1С с десятилетним стажем, хорошо было пробежаться
по основным подходам к программированию в части оптимизации запросов.
Приятно было убедиться, что я в русле основных направлений ))) – не
прошли даром уроки Е.Гилева и Ф.Насипова!)))
Успехов Вам в профессиональной деятельности и прилежных учеников!
Вам большое спасибо!
Добрый день! Записался на этот курс. Видео посмотрел, спасибо что простым и доходчивым языком объясняете как можно оптимизировать запросы, новичкам думаю будет полезно. Но я так и не нашел ссылки ни на демо базу, ни на “Монитор”. Или в рамках этого бесплатного курса предоставление Монитора не предусмотрена?
Добрый день!
База и Монитор лежат в архиве с дополнительными материалами – в первом занятии курса.
Здравствуйте. Совпадают ли имена из видеоинструкции и того, что реально будет развернуто в результате описанных в ней действий?
DemoMiniCourse (то, что вижу в SQL Management Studio) и Demo (название из видео) – это одно и тоже?
03:26 видеоинструкции: “Указываем необходимые параметры”. Исходя из чего Вы их устанавливаете? Что в них нужно записывать?
Имя базы может не совпадать, это не принципиально, по факту база та же самая т.е. да это одно и то же.
Все параметры подробно описываются в видео.
Если будут вопросы по каким-то конкретным настройкам просто напишите здесь, постараюсь помочь.
Здравствуйте, получается если нет сервера и файловые базы, то не получится оптимизация или все-таки как-то можно?
Приемы оптимизации запросов в большинстве случаев универсальны, так что вы сможете применить эти знания и на файловой базе в том числе.
Курс бесплатный, вы ничего не теряете если его посмотрите даже не выполняя практические задания.
Просто тестовые примеры из курса на файловой базе не тестировались и самая тестовая база довольно большая, не уверен получиться развернуть ее в файловом варианте.
очень жаль что монитор я не могу установить
Монитор вы поставить с файловом режиме можете, просто придется вручную запускать анализ запросов т.к. рег. задания там работать не будут.
А вот базу для обучения, ввиду ее размера, развернуть в файловом режиме скорее всего не получиться.
Тем не менее курс бесплатный, в любом случае надеюсь что вы сможете узнать из него много полезного.
По поводу подзапросов и ВТ и соединения с ними. В практике бывали случаи, когда все наоборот – избавлялся от помещения данных в ВТ и соединения с ней тем, что выносил их в подзапрос. Накладные расходы на создание ВТ были слишком высоки. Еще не сказано, что если среди полей, выбираемых в подзапросе данных, есть индексируемые поля – то они (индексы) “наследуются наверх”, то есть для внешнего запроса соединение с вложенным по таким полям тоже будет быстрым (чего не происходит “автоматом” для ВТ – индексы нужно строить самому, что тоже накладно). Также интересный момент – иногда вложенный запрос, точнее соединение с ним превращается в “коррелированный” запрос, то есть, когда на каждую строку внешнего запроса системе приходится каждый раз выполнять вложенный подзапрос (вообще-то, это штатная возможность t-sql и через коррелированный подзапрос можно объявить любое поле в секции select, но нас в 1С этой возможности лишили). Толчком к такому “превращению” может послужить уровень вложенности подзапросов более чем 1 (про это тоже ничего не сказали).
Иногда, может сложиться так, что на уже долгое время работающей базе нужно изменить типа реквизита, или добавить индексируемые поля, или просто добавить реквизит. Так вот после этого, нас ожидает долгий процесс (если база больших размеров)реструктуризации таблицы. В этой статье я рассмотрю алгоритм значительного сокращения времени реструктуризации.
Итак. Программисты 80lvl скорее всего знают все и даже больше, чем описано в статье, поэтому эта публикация будет ориентирована в первую очередь на новичков. А так как у новичка скорее всего ни репутации и стартмани - все скрипты я не буду прикреплять, а выложу в статье.
Поехали. Предположим в вашей конфигурации есть некий документ, с 5 табличными частями. В СУБД (в нашем примере PosgreSQL, но все ниже сказанное справедливо и других СУБД) такой документ предстанет в виде 6 таблиц
Предположим вам необходимо добавить реквизит в табличную часть _document39_vt415, узнать какая именно табличная часть можно либо специальными обработками, либо просто посмотрев несколько записей из таблицы в самой СУБД. Что произойдет далее, точнее что сделает платформа 1С, она создаст копии всех 6 (!) таблиц документа и начнет копирование в них данных из старых таблиц - начнется реструктуризация. Процесс этот, мягко говоря, не быстрый. Почему я вообще пишу эту статью, потому что в моем случаи: количество документов (записей в _document39 было 1М) и записей в табличных частях 25М, процесс реструктуризации документа средствами 1С занял 48 часов. Так вот мы попытаемся обмануть платформу.
Продолжаем, добавляем реквизит в табличную часть в конфигураторе, у меня это число длинной 10, точность 0 (во время всех манипуляций его можно не закрывать), сохраняем, но не обновляем. Переименовываем все таблицы документа в pgAdmin или чем вы там пользуетесь (у меня это пара pgAdmin и EMS SQL Manager PostgreSQL), например _document39 в _document39_src
И создаем копии наших переименованных таблиц (пустые) с первоначальными именами, в нашем примере делаем пустую копию _document39_src с именем _document39.
Копии я создавал в EMS SQL Manager лишь потому, что в нем это проще, но можно и в pgAdmin. В нем надо в контекстном меню таблицы выбрать Скрипты - CREATE и в окне SQL редактора изменить имя таблицы на новое.
Если посмотреть в предприятии, у нас нет ни одного документа.
Теперь, когда 1С считает, что у нас нет документов, в конфигураторе жмем обновить, реструктуризация проходить мгновенно (если возникнут ошибки, жмем обновить еще раз, до тех пор, пока не появится окно о принятии изменений).
Смотрим какое имя получила новая колонка таблицы, которая соответствует новому реквизиту.
У меня это _fld1097. Возвращаемся к нашей исходной таблице, которую мы переименовали в _document39_src, добавляем новую колонку в нее
Ставим значение по умолчанию, здесь 0 и жмем ОК. Весь процесс занял около 1 часа (в 48 раз быстрее). После того как колонка создана, стираем значение по умолчанию и переименовываем таблицу обратно (у нас в _document39)
Запускаем предприятие и проверяем. Радуемся или плачем.
Итак, это мы добавили реквизит, рассмотрим теперь случай, если нам надо изменить тип реквизита, например, было число (5, 2), надо число (10, 4), или добавить индексов.
Тут есть два варианта.
Вариант первый. Создаем копии таблиц и заливаем в них данные из основной таблицы
После этого очищаем исходные таблицы, т.е. доходим до момента, когда 1С думает, что у нас нет записей в таблицах документ. Делаем все необходимые изменения в конфигураторе и обновляем. Теперь нам надо вернуть данные назад
Запускаем предприятие и проверяем. Радуемся или плачем.
Вариант второй. Кто-то считает, что INSERT INTO работает медленно, поэтому можно использовать следующие скрипты, работающие не с копиями таблицы а с файлами на диске
где 'e:/_document39' это файл в корне диска е.
Скрипт загружающий данные обратно
На этом, пожалуй все.
Как видно, процесс это все равно долгий (около 18 часов у меня). Что мы получили, около 19 часов против 48 при изменении типа реквизита и добавлении индексов, и около 1 часа против 48 часов при добавлении реквизита.
PS. У меня есть подозрение, что на других СУБД реструктуризация средствами платформы будет быстрей. К тому же у меня стоял старый PosgresSQL, еще 8.2.4-3.1
Читайте также: