Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Публикация № 1240231 24.05.20

Администрирование БД - HighLoad оптимизация

запросы оптимизация производительность

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

В SQL Server топ запросов по потреблению ресурсов можно получить из кэша планов запросов или с помощью Query Store.

Первый способ не требует никаких предварительных настроек. DMV sys.dm_exec_query_stats, sys.dm_exec_sql_text и sys.dm_exec_query_plan предоставляют доступ, соответственно, к статистике выполнения, текстам и планам запросов из кэша. К недостаткам этого метода относится то, что в кэше сохраняются не все версии планов запросов, и то, что кэш не предназначен для постоянного хранения и может быть очищен.

Чтобы использовать Query Store его нужно включить, настроить и подождать пока в хранилище накопятся нужные данные.

Коротко рассмотрим оба способа.

Для получения информации о ресурсоемких запросах из кэша планов запросов можно использовать следующий запрос:


SELECT 
	topq.statement_text,
	topq.creation_time,
	topq.last_execution_time,
	topq.execution_count,
	topq.avg_worker_time,
	topq.avg_physical_reads,
	topq.avg_logical_reads,
	topq.max_dop,
	topq.plan_handle,
	qp.query_plan
FROM 
(
	SELECT TOP 20
		MIN(qstats.statement_text) AS statement_text,
		MIN(qstats.plan_handle) AS plan_handle,
		MIN(qstats.creation_time) AS creation_time,
		MAX(qstats.last_execution_time) AS last_execution_time,
		SUM(qstats.execution_count) AS execution_count,
		SUM(qstats.total_worker_time) / SUM(qstats.execution_count) AS avg_worker_time,
		SUM(qstats.total_physical_reads) / SUM(qstats.execution_count) AS avg_physical_reads,
		SUM(qstats.total_logical_reads) / SUM(qstats.execution_count) AS avg_logical_reads,
		MAX(qstats.max_dop) AS max_dop
	FROM
		(SELECT
			qs.query_hash,
			qs.plan_handle,
			qs.creation_time,
			qs.last_execution_time,
			qs.execution_count,
			qs.total_worker_time,
			qs.total_physical_reads,
			qs.total_logical_reads,
			qs.max_dop,
			SUBSTRING(st.text, (qs.statement_start_offset/2)+1,   
					((CASE qs.statement_end_offset  
					  WHEN -1 THEN DATALENGTH(st.text)  
					 ELSE qs.statement_end_offset  
					 END - qs.statement_start_offset)/2) + 1) AS statement_text
		FROM sys.dm_exec_query_stats AS qs
		CROSS APPLY sys.dm_exec_sql_text(qs.plan_handle) AS st

		WHERE st.dbid = DB_ID('database_1c') ) AS qstats

	GROUP BY qstats.query_hash
	HAVING MIN(qstats.statement_text) LIKE 'SELECT%'
	ORDER BY avg_worker_time DESC

) topq

CROSS APPLY sys.dm_exec_query_plan(topq.plan_handle) qp

Здесь DMV соединяются по идентификатору плана запроса в кэше – plan_handle. Результатом выполнения станет топ запросов по среднему процессорному времени:

Аналогично запросы можно упорядочить и по другим метрикам производительности, таким как логические или физические чтения.

Второй способ – Query Store, который впервые появился в SQL Server 2016. Включить его можно в окне свойств базы данных или с помощью запроса, например:


ALTER DATABASE database_1c SET QUERY_STORE = ON
GO
ALTER DATABASE database_1c SET QUERY_STORE (OPERATION_MODE = READ_WRITE,
    /*Регистрируются только запросы с временем выполнения > 1 сек и выполненные больше 3-х раз*/ 
    QUERY_CAPTURE_MODE = AUTO, 
    /*Максимальный размер хранилища в Мб (В 2016 по умолчанию - 100 Мб)*/
    MAX_STORAGE_SIZE_MB = 1000)
GO

Помимо прочих возможностей Query Store позволяет просматривать отчет «Основные запросы, потребляющие ресурсы» («Top Resource Consuming Queries»). Откроем отчет и выберем метрику «Время ЦП (мс)»:

Первым в топе мы видим тот же самый запрос, который ранее мы получили из кэша планов запросов с помощью DMV.

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

В нижней части окна отчета выводится текст запроса и план его исполнения.

Теперь, когда запрос для оптимизации выбран, выясним, что это за запрос. Для того чтобы определить место вызова запроса в конфигурации, настроим технологический журнал 1С следующим образом:


<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="true" location="D:\Debug\dumps" type="0" prntscrn="false"/>
<log location="D:\Debug\logs_dbmssql" history="600">
	<event>
        	<eq property="name" value="DBMSSQL"/>
		<eq property="p:processName" value="ibase_1c"/>
		<like property="sql" value="%LEFT OUTER JOIN dbo.\_Document761 T2%"/>
	</event>
	<property name="all"/>
</log>
</config>

В журнал будут записываться только события DBMSSQL, регистрируемые при исполнении операторов SQL Server. Для этих событий мы установили отбор по имени информационной базы и по соответствию текста запроса заданному шаблону. Шаблон мы построили на основе части запроса, содержащей имя одной из таблиц. В начало и конец части запроса мы поместили «%», а специальный символ «_» экранировали обратной косой чертой.

После того, как запрос в очередной раз выполнится, в технологическом журнале мы найдём следующую запись:

В журнале фиксируется контекст исполнения оператора. В данном случае мы имеем дело с одной из процедур регламентного задания отражения документов в регламентированном учете. Этим и объясняется высокая частота выполнения запроса:

Мы видим, что текст запроса перед выполнением модифицируется. Если посмотреть процедуру ДобавитьВЗапросФильтрОтраженияВРеглУчете(), то можно сказать, что это делается с целью повторного использования кода.

Получим окончательный текст запроса с помощью отладчика:

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

План исполнения запроса, который мы видим в нижней части отчета Query Store – это предполагаемый план (Estimated Plan), сформированный до выполнения запроса. Чтобы дополнить его информацией времени выполнения, т.е. получить фактический план (Actual Plan), воспользуемся Extended Events.

Сеанс Extended Events можно создать с помощью графических средств, но быстрее и проще это сделать с помощью запроса:

CREATE EVENT SESSION [query_post_execution_capture_1] ON SERVER 
ADD EVENT sqlserver.query_post_execution_showplan(
    ACTION(sqlserver.sql_text)
    WHERE ([sqlserver].[equal_i_sql_unicode_string]([sqlserver].[database_name],N'database_1c') AND [sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%LEFT OUTER JOIN dbo._Document761 T2%')))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

Для события query_post_execution_showplan мы установили отбор по имени базы данных и шаблону текста запроса. В параметрах события мы включили дополнительное поле – sqlserver.sql_text (текст запроса).

Из контекстного меню созданного сеанса запустим сеанс и откроем окно событий – «Наблюдать за данными, передаваемыми в режиме реального времени» («Watch Live Data»).

Когда нужное событие будет зарегистрировано, остановим сеанс и посмотрим информацию о событии:

Мы видим, что наш запрос выполняется за 5,7 секунд (поле duration). Оптимизатор запросов оценил его предполагаемую стоимость как 180 (поле estimated_cost) и, в соответствии с настройками параллелизма, для запроса выбрана параллельная версия плана исполнения (поле dop). Для сравнения, порог стоимости плана запроса для использования параллелизма (cost threshold for parallelism) по умолчанию – 5.

Поле sql_text содержит текст запроса. Скопировав его в редактор запросов SSMS можно получить запрос в отформатированном виде:

Обратите внимание на условие отбора по полю Fld1490 для каждой таблицы. Это поле разделителя с типом "ОбщийРеквизит.ОбластьДанныхОсновныеДанные". Платформа 1С неявно подставляет такие условия в запросы для конфигураций, в которых заложена возможность разделения данных, независимо от того, включено разделение или нет. Это относится ко всем конфигурациям, основанным на современных версиях БСП.

Для того, чтобы узнать каким объектам конфигурации соответствуют таблицы и поля базы данных, нужно воспользоваться функцией глобального контекста ПолучитьСтруктуруХраненияБазыДанных(). Результат её выполнения можно посмотреть в отладчике:

Таким же способом можно получить структуру индексов таблиц базы данных:

Первое, что бросается в глаза в плане исполнения нашего запроса – это толщина стрелок, изображающих потоки данных. Мы видим, что вся таблица регистра сведений ОтражениеДокументовВРеглУчете (InfoRg30933), в которой более 1,3 миллионов записей, попарно соединяется с каждой из основных таблиц трех документов, участвующих в запросе. Если быть точным, соединяются не таблицы, а результаты поиска по некластеризованным индексам, где предикатом является значение поля разделителя Fld1490, которое уже было упомянуто выше. Т.к. разделение в базе отключено, селективность этого предиката равна единице, т.е. возвращаются все строки таблиц.

Во всех трех случаях для соединения используется оператор Hash Match. Оптимизатор обычно использует этот оператор для соединения больших входных данных, если они не отсортированы по полям соединения.

При соединении оператором Hash Match вычисляются хеши полей соединения верхних входных данных, называемых «Build». Таблица со значениями полей соединения и их хешами помещается в оперативную память. После этого выполняется построчное чтение нижних входных данных, называемых «Probe». Для каждой строки вычисляется хеш значений полей соединения и сравнивается с хешами в таблице из оперативной памяти. Для эффективного выполнения в качестве «Build» (верхних входных данных) выбирается меньший из двух потоков.

Поля, по которым выполняется соединение, можно увидеть в свойстве «Hash Keys Probe» оператора Hash Match.

В нашем случае стоимость операторам Hash Match увеличивает ещё и дополнительный предикат, соответствие которому должно быть проверено в ходе соединений. Его можно увидеть в свойстве «Probe Residual» операторов:

Из-за объема данных в нижнем потоке эти три оператора Hash Match наиболее затратны по CPU.

Наш запрос входит в топ по процессорному времени и по той причине, что для его исполнения используется параллелизм. Параллелизм уменьшает время выполнения запроса, но увеличивает потребление ресурсов. Если есть необходимость, параллелизм можно отключить не на уровне экземпляра или базы данных, а для конкретного запроса, добавив к запросу «Хинт» (Hint): OPTION (MAXDOP 1). Т.к с помощью средств платформы 1С мы не можем непосредственно изменять sql-запросы, хинт можно добавить в SSMS с помощью т.н. «Структуры планов» (Plan Guide):

Рассмотрим теперь этот фрагмент плана исполнения:

На плане мы видим, что верхний поток, в котором 1,3 млн. записей (результат соединения регистра сведений с документами), соединяется с таблицей константы «ДатаНачалаВеденияРеглУчета» с помощью оператора Nested Loops. В современных версиях платформы 1С каждой константе соответствует своя отдельная таблица базы данных.

Перед соединением на таблицу константы, как и на все другие таблицы, накладывается отбор по значению разделителя. Чтобы не производить поиск по этому значению на каждой итерации Nested Loops, результат поиска в индексе записывается в tempdb c помощью оператора Table Spool.

При выполнении Nested Loops операторы нижней ветки, в данном случае Table Spool, выполняются столько раз, сколько строк содержит верхний входящий поток, в нашем случае более 1,3 млн. раз. Это неоптимальное использование оператора Nested Loops, который эффективен, только если верхний поток содержит сравнительно малое количество строк.

Оператор Nested Loops проверяет условия соединения одним из двух способов. В нашем случае условия соединения находятся в свойстве «Predicate» оператора. Это значит, что оператор Nested Loops отбирает строки, соответствующие условиям, после того как получит значения из внутреннего цикла (нижняя ветка). Значения из верхнего набора строк в нижний не передаются. Нижние входящие данные в нашем случае статичны и возвращают одни и те же значения при каждом выполнении.

Условия соединения могут также проверятся в нижней ветке (во внутренних циклах). В этом случае мы бы увидели условия не в свойстве «Predicate», а в свойстве «Outer References» оператора Nested Loops.

Если мы посмотрим значение свойства «Predicate» оператора Nested Loops в плане исполнения нашего запроса, то мы увидим там все условия из секции «ГДЕ» запроса.

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

Перепишем запрос следующим образом:


ВЫБРАТЬ РАЗРЕШЕННЫЕ
	ОтражениеДокументовВРеглУчете.Регистратор КАК Документ
ИЗ
	РегистрСведений.ОтражениеДокументовВРеглУчете КАК ОтражениеДокументовВРеглУчете
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ Константы КАК Константы
		ПО (ИСТИНА)
ГДЕ
	ОтражениеДокументовВРеглУчете.Статус В(&СтатусыОтражения)
	И ОтражениеДокументовВРеглУчете.ДатаОтражения >= Константы.ДатаНачалаВеденияРеглУчета

ОБЪЕДИНИТЬ

ВЫБРАТЬ
	ОтражениеДокументовВРеглУчете.Регистратор
ИЗ
	РегистрСведений.ОтражениеДокументовВРеглУчете КАК ОтражениеДокументовВРеглУчете
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.СчетФактураВыданныйАванс КАК СчетФактураВыданныйАванс
		ПО (СчетФактураВыданныйАванс.Ссылка = ОтражениеДокументовВРеглУчете.Регистратор)
ГДЕ
	(СчетФактураВыданныйАванс.ДокументОснование ССЫЛКА Документ.ВводОстатков
	ИЛИ СчетФактураВыданныйАванс.ДокументОснование ССЫЛКА Документ.ПервичныйДокумент)

ОБЪЕДИНИТЬ

ВЫБРАТЬ
	ОтражениеДокументовВРеглУчете.Регистратор
ИЗ
	РегистрСведений.ОтражениеДокументовВРеглУчете КАК ОтражениеДокументовВРеглУчете
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.СчетФактураПолученныйАванс КАК СчетФактураПолученныйАванс
		ПО (СчетФактураПолученныйАванс.Ссылка = ОтражениеДокументовВРеглУчете.Регистратор)
ГДЕ
	(СчетФактураПолученныйАванс.ДокументОснование ССЫЛКА Документ.ВводОстатков
	ИЛИ СчетФактураПолученныйАванс.ДокументОснование ССЫЛКА Документ.ПервичныйДокумент)

ОБЪЕДИНИТЬ

ВЫБРАТЬ
	ОтражениеДокументовВРеглУчете.Регистратор
ИЗ
	РегистрСведений.ОтражениеДокументовВРеглУчете КАК ОтражениеДокументовВРеглУчете
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.СчетФактураНалоговыйАгент КАК СчетФактураНалоговыйАгент
		ПО (СчетФактураНалоговыйАгент.Ссылка = ОтражениеДокументовВРеглУчете.Регистратор)
ГДЕ
	СчетФактураНалоговыйАгент.ДокументОснование ССЫЛКА Документ.ПервичныйДокумент

ОБЪЕДИНИТЬ

ВЫБРАТЬ
	ОтражениеДокументовВРеглУчете.Регистратор
ИЗ
	РегистрСведений.ОтражениеДокументовВРеглУчете КАК ОтражениеДокументовВРеглУчете
ГДЕ
	(ТИПЗНАЧЕНИЯ(ОтражениеДокументовВРеглУчете.Регистратор) = ТИП(Документ.ВводОстатков)
	ИЛИ ТИПЗНАЧЕНИЯ(ОтражениеДокументовВРеглУчете.Регистратор) = ТИП(Документ.ВводОстатковВнеоборотныхАктивов)
	ИЛИ ТИПЗНАЧЕНИЯ(ОтражениеДокументовВРеглУчете.Регистратор) = ТИП(Документ.ВводОстатковВнеоборотныхАктивов2_4)
	ИЛИ ТИПЗНАЧЕНИЯ(ОтражениеДокументовВРеглУчете.Регистратор) = ТИП(Документ.НачальныеОстаткиНЗППоПартиямПроизводства)
	ИЛИ ТИПЗНАЧЕНИЯ(ОтражениеДокументовВРеглУчете.Регистратор) = ТИП(Документ.ОперацияБух)	
	ИЛИ ТИПЗНАЧЕНИЯ(ОтражениеДокументовВРеглУчете.Регистратор) = ТИП(Документ.ПервичныйДокумент))

Выполним запрос и посмотрим метрики его производительности в Extended Events:

Мы видим, что на этот раз исполнитель запросов счел запрос достаточно простым, чтобы выполнить его на одном логическом процессоре (estimated_cost=0, dop = 1). При этом измененный запрос выполнился за 0.13 секунд, т.е. в 43 раза быстрее оригинального запроса. Процессорное время, затраченное на выполнение (cpu_time), теперь равно 123870 микросекунд, что в 88 раз меньше, чем у оригинального запроса.

Посмотрим теперь на текст sql-запроса и на план его исполнения:

Для реализации логической операции объединения (Union) оптимизитор использовал физический оператор Merge Join, который требует, чтобы входные данные были упорядочены по полям объединения и не содержали дубликатов. Сам оператор Merge Join (Union) исключает из объединения дубликаты строк, которые есть в обоих наборах, но не учитывает дубликаты, которые могут быть в каждом из наборов по отдельности. Поэтому оптимизатор явным образом удаляет из наборов дубликаты либо с помощью оператора Sort (Distinct Sort), либо с помощью оператора Stream Aggregare (если данные в наборе уже упорядочены по нужным полям):

Посмотрим теперь, как оптимизатор формирует каждый из пяти объединяемых наборов данных, начиная с верхнего.

В секции «ГДЕ» верхнего запроса мы видим условия отбора по ресурсу «Статус» и по измерению «ДатаОтражения» регистра «ОтражениеДокументовВРеглУчете». Значения параметра &СтатусыОтражения передаются в запрос и объединяются с помощью оператора Concatenation. Ресурс «Статус» регистра проиндексирован, и поиск значений статусов выполняется в этом индексе.

Условие по Статусу высокоселективное: из 1.3 млн. строк выбирается 4 тысячи. Далее эти 4 тысячи строк соединяются с таблицей константы с отбором по Дате отражения, уже без использования индексов:

Используя терминологию из Методик разработки конфигураций 1С, условие по Статусу можно назвать «основным», а по Дате отражения – «дополнительным».

Следующие 3 объединяемых запроса по структуре почти не отличаются, но оптимизатор выбрал для них разные способы исполнения. Это объясняется разной оценкой количества элементов (Cardinality estimation), соответствующих условиям отбора. Эту оценку оптимизатор получает на основе статистики.

Наконец, для получения результата последнего из пяти запросов, достаточно выполнить поиск по индексу, т.к. все элементы в секции «ГДЕ», несмотря на то, что они объединены оператором «ИЛИ», накладывают отбор по одному и тому же полю – Регистратору.

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

Оригинальный запрос заменим оптимизированным в расширении конфигурации. В данном случае безопасней всего это сделать, расширив метод «ДобавитьВЗапросФильтрОтраженияВРеглУчете()» следующим образом:

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

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Painted 40 25.05.20 10:23 Сейчас в теме
1С рекомендует отказаться от параллелизма и выставлять maxdop = 1. У вас не возникают проблемы? И какое значение maxdop вы используете? И сколько ядер на сервере?
2. nomad_irk 57 25.05.20 10:56 Сейчас в теме
(1) Рекомендациям более 4 лет, думаю, они утеряли свою актуальность.
MAGDevelopment; +1 Ответить
8. Salavat 13 27.05.20 08:38 Сейчас в теме
(2) Своей фразой, Вы элементарно сказали - это было вчера, а сегодня, настал новый день.
С таким же успехом - и Ваша фраза, ничего не стоит.
Ведь и Вы сказали - уже не сегодня.
Irwin; buganov; sapervodichka; +3 Ответить
11. buganov 183 29.05.20 08:23 Сейчас в теме
(8)он просто, возможно, не понимает смысла настройки параллелизма
12. nomad_irk 57 29.05.20 09:39 Сейчас в теме
(11)Из каких моих слов вы сделали умозаключение о том понимаю я настройки параллелизма или не понимаю?
13. buganov 183 29.05.20 09:52 Сейчас в теме
(12)
Рекомендациям более 4 лет, думаю, они утеряли свою актуальность.

Вот тут мне так показалось.

MaxDOP штука, конечно, классная, но готовить ее тоже надо уметь. И 4 года назад надо было уметь. Если воткнуть MaxDOP = 0, то для одного запроса возможно(!) станет лучше, но при этом есть вероятность утилизировать все процессоры. А если запрос выгребает половину базы при этом, то остальным тупо не хватит ресурсов. На среднезагруженных системах параллелизм ни к чему, кмк, на highload только для некоторых операций, которые не такие уж и частые(закрытие месяца, например). Гораздо полезнее будет оптимизировать алгоритмы и запросы, чем нагружать оборудование.

Так что настройка MaxDOP = 1 очень даже актуальна и по сей день и позволяет в случае, например, нереального запроса Sel ect * FR OM * не положить систему, а оставить ее работоспособной, хоть и с оговорками.
14. nomad_irk 57 29.05.20 10:00 Сейчас в теме
(13)У вас свое видение настроек параллелизма, у меня - свое. Мое видение полностью совпадает с (3) + за 4 года произошли заметные изменения в принципах написания запросов в типовых, т.к. много изменений произошло в структуре хранения и логике работы конфигурации в целом.
15. buganov 183 29.05.20 10:12 Сейчас в теме
(14) а при чем тут типовые запросы? И что именно изменилось за 4 года? Регистры остались регистрами, итоговые таблицы так и остались итоговыми. На вскидку могу предположить только итоги для срезов регистров сведений, но это не повод к радикализму.
16. nomad_irk 57 29.05.20 10:24 Сейчас в теме
(15)например:
уход от использования виртуальных таблиц регистров(СрезПоследних, Обороты, ОстаткиИОбороты)
добавление дополнительных регистров для хранения той же информации, что и в основном регистре, но в другой структуре
18. buganov 183 29.05.20 12:57 Сейчас в теме
(16)а примеры то будут? Видел все перечисленное в последней комплексной и унф
19. nomad_irk 57 29.05.20 12:58 Сейчас в теме
(18)Примеры чего, если вы сами видели?
20. buganov 183 30.05.20 09:02 Сейчас в теме
(19) Ну, например, куда ушел срез последних по ценам
21. nomad_irk 57 30.05.20 10:46 Сейчас в теме
(20)Про срез последних по ценам не скажу, т.к. не копал конфигурации на эту тему, могу сказать за кадровую историю сотрудников, которая состоит теперь из 2-х регистров: кадровая история сотрудников и кадровая история интервальный.
Структура у них немного разная и второй регистр не является подчиненным. Записи в нем формируются при записи в кадровую историю.

Текущее состояние сотрудника получается именно из второго регистра. Срезы последних при этом заменяются на "динамические срезы последних", как я их называю, т.е. последнее значение на каждую дату.
3. DataReducer 288 25.05.20 11:29 Сейчас в теме
(1) Некоторые рекомендации 1С даны для того, чтобы гарантировать приемлемую работу усредненной системы без необходимости тонкой настройки и мониторинга. MAXDOP - пример такой рекомендации.

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

Нет значения этого параметра, которое однозначно подходило бы для всех систем. Оно выбирается в зависимости от рабочих нагрузок и их характера. Увеличивая MAXDOP нужно также подбирать значение параметра «Cost threshold for parallelism» (значение по умолчанию слишком низкое).

Конкретно на этой системе MAXDOP=2, всего 4 логических процессора.
4. Painted 40 25.05.20 14:40 Сейчас в теме
(3)
Конкретно на этой системе MAXDOP=2
Понятно. MAXDOP=0 - это перебор? Можно повесить базу?
6. Gilev.Vyacheslav 1883 26.05.20 09:23 Сейчас в теме
(4) если запросов будет слишком много, то можно положить процессоры
если интенсивность будет меньше запасов мощности сервера, то даже положительно скажется
sapervodichka; METAL; +2 Ответить
9. Salavat 13 27.05.20 08:40 Сейчас в теме
Я бы даже сказал, что это относится ко всему, что нужно делать -
(3)
но делать это нужно с контролем
5. DataReducer 288 25.05.20 17:30 Сейчас в теме
(4) Это значит, что для выполнения запроса могут быть задействованы все логические процессоры. Теоретически это может сказаться на производительности других запросов. Имеет смысл устанавливать меньшее значение, чем общее количество процессоров.
7. nvv1970 27.05.20 08:29 Сейчас в теме
Объединить без ВСЕ можно выполнить ради свёртки только в последнем запросе, а не выполнять ее много раз.
10. DataReducer 288 27.05.20 10:13 Сейчас в теме
(7) Справедливое замечание, спасибо.
17. triviumfan 28 29.05.20 12:51 Сейчас в теме
Запрос простой, "невооруженным глазом" было видно, что нужно переписать его через объединения. Но за анализ все равно спасибо, таких статей очень мало.
nekit_rdx; It-developer; Fox-trot; +3 Ответить
22. DataReducer 288 31.05.20 12:07 Сейчас в теме
(17) И вам спасибо. Запрос действительно простой, и на практике не было бы необходимости смотреть план его исполнения. Но хотелось показать методику подхода к таким задачам.
It-developer; +1 Ответить
Оставьте свое сообщение

См. также

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Технологический журнал v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    32840    MrWonder    42    

Базовые приемы работы с кластером 1С при помощи БСП

Администрирование СУБД БСП (Библиотека стандартных подсистем) v8 1cv8.cf Бесплатно (free)

В данной публикации я рассматриваю базовые приемы работы с кластером серверных баз 1С, используя типовые типовые возможности библиотеки стандартных подсистем (БСП).

26.10.2021    3085    quazare    6    

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB HighLoad оптимизация v8 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    1627    sorter1    2    

Обновление платформы 1С тонкого клиента с вебсервера, когда сервер 1С ПРОФ

Администрирование веб-серверов Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Обновление платформы 1С: тонкого клиента с вебсервера описывается на https://its.1c.ru/db/v8316doc#bookmark:adm:TI000001058, но по факту, следуя точно инструкциям вендора с ИТС, никому не удалось добиться результата. Выражаю благодарность Панюшкину Михаилу Михайловичу за разбор задачи и доведение ее до практического результата.

19.10.2021    1464    ser6702    13    

Долго открывается конфигуратор Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    44017    Gilev.Vyacheslav    1    

Клиент-серверный режим базы данных 1С8 для тестирования

Инструменты администратора БД Администрирование СУБД v8 1cv8.cf Бесплатно (free)

В публикации рассматриваются некоторые аспекты настройки базы данных 1С8.3 в серверном режиме, для тестирования обработок или расширений.

30.09.2021    1393    etmarket    3    

Зависание базы при создании/редактировании пользователей после конвертации базы с платформы 8.1 на 8.3

Администрирование СУБД v8 УТ10 Россия Бесплатно (free)

При переводе базы с платформы 8.1 на платформу 8.3 возникает проблема - база конвертится замечательно, но при редактировании или создании новых пользователей база напрочь зависает. Речь пойдёт о серверной базе данных.

29.09.2021    445    Kitri    4    

Оптимизация проведения документов списания партий в УПП 1.3

HighLoad оптимизация v8 УТ10 УПП1 Бесплатно (free)

Почти в каждой конфигурации УПП 1.3 (возможно, и в УТ 10.3) есть медленный запрос, тормозящий проведение документа списания. Данная публикация раскрывает места вызова данного запроса и приводит пример оптимизации. Пример показывает результаты проведения документа «Реализация товаров и услуг», но метод работает и для других документов списания партий.

09.09.2021    564    info1i    4    

Видеодемонстрация применения Теста-центра для нагрузочного тестирования конфигураций Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

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

16.09.2012    36458    Aleksey.Bochkov    29    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода Технологический журнал v8 Бесплатно (free)

Расскажем про инструменты, рассмотрим планы запросов, увидим, как отслеживать и бороться с проблемами производительности на боевой базе.

07.09.2021    4081    ivanov660    23    

Перекуем Cloud на Oracle. Тестируем размещение 1С в облачной платформе Oracle Cloud.

Администрирование СУБД Облачные сервисы, хостинг v8 1cv8.cf Бесплатно (free)

После цикла публикаций про размещение 1С в облачных сервисах я думал, что все различные варианты рассмотрены и тема для меня закрыта. Однако есть события, мимо которых не пройти. Так вот и сейчас, когда наблюдается аттракцион невиданной щедрости от Oracle, мимо этого просто так не пройти.

02.09.2021    681    capitan    22    

Адекватный параллелизм в 1С

HighLoad оптимизация v8 Бесплатно (free)

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    3533    Shmell    7    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    69174    yuraos    112    

Снова про анализ технологического журнала с помощью PowerShell

Технологический журнал v8 Бесплатно (free)

Универсальная методика анализа технологического журнала (далее - ТЖ) с помощью Powershell без применения алгоритмов программирования.

05.08.2021    1564    cdiamond    1    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода v8 Бесплатно (free)

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

02.08.2021    9416    ivanov660    77    

Своя форма выбора типа, метаданных (Infostart Toolkit)

Структура метаданных v8 1cv8.cf Россия Бесплатно (free)

Зачем своя форма выбора? Полезные функции и особенности работы.

26.07.2021    2526    Evg-Lylyk    17    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

HighLoad оптимизация v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    59233    Антон Ширяев    117    

Обновление 1С: Розницы с релиза 2.3.8.27 до 2.3.9.28

Администрирование СУБД v8 Розница Россия Бесплатно (free)

Многие уже столкнулись с тем, что не смогли обновить 1С: Розницу релиз 2.3.8.27 на более поздние релизы. Напомню, релиз 2.3.8.27 - позволял-таки нам работать в ЕГАИС 4. Но а вот с дальнейшими обновлениями...

05.07.2021    6338    13D    25    

Разбор причины ошибки "Нарушение целостности чтения объекта базы данных из-за параллельного изменения объекта другим сеансом"

Технологический журнал v8 1cv8.cf Бесплатно (free)

При нагруженной работе начали возникать ошибки чтения из-за параллельного изменения. Здесь приводится расследование причин проблемы.

25.06.2021    1029    pashamak    0    

Parameter sniffing и генерация планов для разработчиков 1С

HighLoad оптимизация v8 Бесплатно (free)

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    8967    vasilev2015    17    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

HighLoad оптимизация v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    61353    Gilev.Vyacheslav    46    

Как подключиться к хранилищу конфигурации на сервере за NAT, если есть доступ по RDP?

Администрирование СУБД Хранилище v8 Бесплатно (free)

В статье находится инструкция по подключению базы 1С к хранилищу конфигурации, если хранилище не опубликовано в интернет, но опубликовано по TCP в локальной сети клиента.

01.06.2021    2647    Dipod    13    

Как добыть последнюю версию SQL Server 2012 Native Client

Администрирование СУБД Администрирование ИТ-инфраструктуры v8 Бесплатно (free)

Краткое руководство администраторам 1С по получению свежей версии SQL Server 2012 Native Client, необходимого для работы сервера 1С.

13.05.2021    2255    tedkuban    3    

Ускорение реструктуризации больших таблиц. Мой вариант

HighLoad оптимизация Администрирование СУБД BigData v8 1cv8.cf Бесплатно (free)

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

28.04.2021    1320    buganov    0    

Параллельные вычисления в 1С 8 Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    38244    gallam99    19    

Поиск причин блокировок СУБД

HighLoad оптимизация v8 v8::blocking 1cv8.cf Бесплатно (free)

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    5740    vasilev2015    13    

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

HighLoad оптимизация v8 1cv8.cf Россия Бесплатно (free)

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

22.04.2021    2439    a.doroshkevich    4    

Xubuntu 20.04 для бухгалтера 1С

Linux Администрирование СУБД v8 БП3.0 Россия Бесплатно (free)

В публикации представлен необходимый минимум для настройки Xubuntu 20.04 в качестве рабочего места бухгалтера, ведущего учёт в программе 1С: Бухгалтерия 3.0 файловый вариант. Кроме этого, настроено подключение и других сотрудников через тонкий клиент 1С к опубликованной на веб-сервере базе бухгалтерии.

12.04.2021    4833    compil7    25    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных HighLoad оптимизация v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    45375    madmpro    32    

Режим совместимости конфигурации 1С

Администрирование СУБД v8 1cv8.cf Россия Бесплатно (free)

Приветствую, коллеги! В этой статье будет сделан обзор функции совместимости конфигурации 1С с другими версиями конфигураций 1С, а также рассмотрено, как выбрать и настроить режим совместимости конфигурации с версией 1С 8.3. Во-первых, разберём главное понятие в этой статье: режим совместимости в конфигурации – это устройство, благодаря которому выводится номер версии системы, под которую станет открыто приложение 1С:Предприятие. Данный режим существует на платформе 1С начиная с версий 8.2 и 8.3 (платформа версии 1С:Предприятие 8.3 совместима с платформой версии 1С:Предприятие 8.2).

31.03.2021    5997    Koder_Line    3    

Решение нестандартных проблем производительности на реальных примерах

HighLoad оптимизация v8 Бесплатно (free)

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    5001    AlexKriulin    37    

Соединение вложенными циклами

HighLoad оптимизация v8 Бесплатно (free)

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    3614    vasilev2015    22    

Чтение метаданных 1С в SQL Server

Структура метаданных v8 Бесплатно (free)

Описание файла DBNames таблицы Params и файлов объектов метаданных таблицы Config.

16.02.2021    4144    zhichkin    63    

Долгое воспроизведение звука по RDP с удаленной машины

HighLoad оптимизация v8 Бесплатно (free)

При воспроизведении короткого звука в 38 Кб, сигнализирующего об успешном сканировании, порою происходило подвисание примерно в 5 секунд.

09.02.2021    974    pashamak    2    

Highload-оптимизация 1С: теория и практика на примере консолидированной отчетности группы "Магнит" и розничной аптечной сети "Магнит"

HighLoad оптимизация BigData v8 Бесплатно (free)

Тема оптимизации 1С на больших данных бесконечная и всеобъемлющая, поскольку на производительность влияет целый ряд факторов – количество пользователей, данных, транзакций, неоптимальные запросы и т.д. Об инструментах для локализации проблем производительности и практических кейсах оптимизации рассказал Алексей Олейник, руководитель сектора автоматизации отчетности МСФО компании «Информационные технологии Магнит».

11.01.2021    26225    user662404_itlexusss    14    

Платформа 8.3.18 Обновление ИБ в пакетном режиме поломалось? Решено

Администрирование СУБД v8 Бесплатно (free)

Уже давно работаем с большим количеством ИБ и обновляем, естественно, в пакетном режиме, но с переходом на новую платформу 8.3.18.1208 этот пакетный режим поломался. Стало появляться окно конфигуратора и спрашивать вопросы, раньше такого не было. Решение найдено.

24.12.2020    6288    VPanin56    14    

Анализ блокировок СУБД: таблица изменений плана обмена 1С

HighLoad оптимизация v8 Бесплатно (free)

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    3571    zhichkin    7    

Метаданные и их идентификаторы

Структура метаданных БСП (Библиотека стандартных подсистем) v8 Бесплатно (free)

Идентификаторы (GUID'ы) метаданных конфигурации. Немного о том, как их получить.

05.12.2020    12720    YPermitin    27    

Анализ проблем производительности по динамике мониторинга RAS 1C

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

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

07.10.2020    5024    ivanov660    13    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

HighLoad оптимизация v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    5423    Nykyanen    16    

Тест скорости работы мобильной платформы 1С

Мобильная разработка HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

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

14.09.2020    1917    capitan    25    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    30196    YPermitin    38    

Адаптация автоматической классификации ошибок технологического журнала при появлении новых текстов и типов

Технологический журнал v8 1cv8.cf Бесплатно (free)

Корректируем классификацию ошибок ТЖ в процессе работы для конфигурации мониторинг производительности

17.08.2020    939    ivanov660    0    

Восстановление полнотекстового поиска в базе данных. Клиент-серверный вариант. Моя практика.

Администрирование СУБД v8 Бесплатно (free)

Восстановление полнотекстового поиска в базе данных. Клиент-серверный вариант.

06.08.2020    1120    premierex    3    

Администрирование списка баз Windows правами.

Администрирование СУБД v8 Бесплатно (free)

Все пользуются, а статьи по администрированию списка баз нет. Непорядок.

03.08.2020    1267    sergey279    0    

Нестандартные блокировки при работе с OLAP-нагрузкой

HighLoad оптимизация v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    2746    Филин    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    4519    ivanov660    13    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

HighLoad оптимизация v8 Бесплатно (free)

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

18.05.2020    2684    Aleksey.Bochkov    4