Неоптимальности вида «план исполнения запроса "испортился"» - поиск и исправление

Публикация № 779869

Администрирование - Производительность и оптимизация (HighLoad)

Запрос оптимизация неоптимальность производительность план исполнения система сбора и анализа информации по производительности работы баз данных работающих под связкой «кластер 1С 8.2/8.3 - Microsoft SQL server».

Рассматривается один из частых типов проблем в рабочих базах (второй после блокировок, пожалуй... впрочем, часто и тесно с ними связанный). Материал относится к базам данных на связке «1С - MS SQL Server».

Из недавнего, случай номер раз

После нового года сообщение со склада: «обработка  ПеремещениеКонтейнеровГрузчиками тормозит».

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

Выясняю имя компа, имя пользователя, периоды «когда тормозила» и «когда работала нормально»

Смотрю  лог длительных запросов техжурнала :

Смотрю лог длительных запросов sql-сервера, фиксируемый сессией XE :

Тоже самое, и тоже на первом месте — даже не надо делать поиск по слову «ПеремещениеКонтейнеровГрузчиками»

Проблема в запросе

Форма.Вызов : Обработка.ПеремещениеКонтейнеровГрузчиками.Форма.Форма.Модуль.ОбновитьИнформациюИзРабот
  Обработка.ПеремещениеКонтейнеровГрузчиками.Форма.Форма.Форма : 2525 : МассивРезультатов = Запрос.ВыполнитьПакет();

Запрос простой:

INSERT INTO #tt280 (_Q_001_F_000_TYPE, _Q_001_F_000_RTRef, _Q_001_F_000_RRRef) 
SELECT DISTINCT
  T2._Документ_TYPE,
  T2._Документ_RTRef,
  T2._Документ_RRRef
FROM 
  #tt278 T1 WITH(NOLOCK)
  INNER JOIN _Справочник.РаботыПоДокументам T2 WITH(NOLOCK)
  ON ((T1._Q_000_F_000 <= T2._Дата) AND (T1._Q_000_F_001 >= T2._Дата))
WHERE 
  (T2._СотрудникRRef = ?) AND (T2._ВидРаботRRef IN (?, ?))
p_0: 0x82671C6F65D4C9E511E6F4D5B9451D40
p_1: 0x826B902B345B065011E79DD1E6AFA776
p_2: 0x826B902B345B065011E79DD1E6AFA77D

Сам запрос — в процедуре ОбновитьИнформациюИзРабот(), которая повешена на пару кнопок + на обработчик ожидания вот так:

&НаКлиенте
Процедура ПриОткрытии(Отказ)
    ПодключитьОбработчикОжидания("ОбновитьИнформациюИзРаботКлиент", 15);
КонецПроцедуры

Показывает какую-то статистику сборщику в нетбуке по его производительности.
Тормозит работу, раздражает (минимум каждые 15 сек подвисание на 2-3 сек)
Не жизненно важно.. оперативно отключили.
Ведущий: «Но оно же работало вот уже кучу времени, как так?».
Разбираемся.

Работало оно так действительно не всегда.
До 07.01.2018 и сведений-то нет по запросу — значит, исполнялся строго менее полсекунды (не попал в трассу длительных rpc_completed eXtended Events), и в логе sys.dm_exec_query_stats тоже нет данных.
Легкий был запрос.
Ночью седьмого он начинает сбоить:

Резко увеличивается как длительность (до 1-3 секунд), увеличивается количество чтений и нагрузка запросом на CPU. При этом avg rows не меняется, да и параметры на входе запроса тоже гарантированно не скачут (это видно из кода).
Значит поменялся план исполнения.

Справочник.РаботыПоДокументам нужен для подсчета сдельной части оплаты труда складского персонала (в основном содержит что-то вроде «5 января - перемещение №23434 - Вася Иванов - перенос тяжестей - 5 кг») 
Он имеет десяток реквизитов, из которых проиндексированы «ВидРабот», «Дата» и «Документ». 
Вопрос «а чего это он справочник, а не регистр сведений» уходит корнями год этак в 2007-ой, когда «трава была зеленее, вода мокрее, а база работала на 8.1».. так вот получилось, и легким движением руки - не изменишь.

Планов зафиксировано достаточное количество, чтобы разобраться..

Вот «плохой» план:

Index Seek,  seek predicates содержит отбор по диапазону [_Справочник.РаботыПоДокументам]._Дата.
Т.е. отберем  РаботыПоДокументам за период, а потом (во время key lookup к кластерному) глянем — соответствует ли WHERE (T2._СотрудникRRef = ?) AND (T2._ВидРаботRRef IN (?, ?))
Учитывая то, что в рабочей складской бд рождается по несколько десятков документов в секунду, и почти в каждом сдельщина -  Index Seek по «Дата в диапазоне» выходит накладным. 
Диапазон дат не уменьшить — данные выводятся за текущую смену (несколько временных интервалов во времянке #tt497, суммарно ~8 часов).

А вот «хороший» план:

Тут отбираются данные по индексу поля «ВидРабот» (Seek Predicates по ВидРабот > параметр1 И ВидРабот < параметр2), в отобранном отрабатывает фильтр (Predicate) по «T2._СотрудникRRef = ?», и ТОЛЬКО ПОТОМ соединяем с таблицей диапазонов дат.
Т.е. «хороший» план тоже ужасен.
Ну а вдруг таких работ за год будет миллион? Тогда первый index seek грохнется.. а почему, кстати, пока не грохается?

По ходу дела выясняется, что «..оно же работало вот уже кучу времени...» = примерно три месяца. И тогда же были созданы два новых «вида работ».
Пока записей с данными «видами работ» было мало — стратегия «отбираем все записи с этими видами работ, а что получилось — фильтруем по Сотруднику и Дате» работала неплохо. 
А вот как их стало поболее — оптимизатор решил «не, индекс по Дате более классный». Хотя это на самом деле _пока_ не так. 

Периодический пересчет статистик таблицы _Справочник.РаботыПоДокументам настроен.
UPDATE STATISTICS _Reference4544 — выполняется раз в день, задачей на sql-сервере.

Пробую пересчитать статистику вручную и пробно запустить запрос — нет, план «плохой».
Хорошо, пересчитываю WITH FULLSCAN (тяжелая операция, таблица большая, но что не сделаешь ради истины) – ага, некоторое время план «хороший», потом опять срыв в «плохой».

Итого имеем:  
1. Идеальное решение проблемы — выпилить запрос из системы совсем. Не подходит. Пользователи говорят «оно нам надо»..
2. Плохое решение проблемы — включить индексирование поля «Сотрудник». Некоторое время поработает. Но потом таки найдется сотрудник, проработавший в этой обработке полгода — у него посыпется опять.. Да и вообще, как-то неприятно плодить такие.. как оно -  «суррогаты»?..
3. Нереальное решение проблемы — переделать со справочника на регистр сведений (внешнюю базу данных, иное — нужное подчеркнуть).. ну да, делов-то на год для трех человек (три конфигурации этой штукой пронизаны насквозь, одних впрямую использующих отчетов — десятка три).
4. Спорное решение проблемы — новый индекс для таблицы _Reference4544 объекта _Справочник.РаботыПоДокументам, по полям _СотрудникRRef,  _ВидРаботRRef, _Дата, с include-полями _Документ_TYPE, _Документ_RTRef, _Документ_RRRef.
Но 1С штатно такое делать не умеет.
Вопрос создания новых /модификации стандартных индексов — тема спорная.. 
Позиция 1С  понятна — хочется чтоб работало «как надо» само при правильном выборе типа объекта и порядке реквизитов.. да и неподготовленный новичок может наворотить всякого самописными индексами..
Но с другой стороны, ситуации «очень надо именно вот такое» весьма часты. И думаю, в 1С догадываются, что «они все равно это делают». 
Лучше всех, сдается мне, сказал Андрей Бурмистров:  «..Надеюсь я доживу до того дня, когда платформа позволит создавать индексы произвольного состава средствами конфигуратора.». Кстати, внимательный читатель может таки уже задать вопрос «а почему в “хорошем” плане нет key lookup к кластерному, и почему проверка T2._СотрудникRRef = ? идет в индексе по “ВидРабот”?»

В данном случае и индекс по полю «Сотрудник» (что штатный простой, что самописный с доп. полями «ВидРабот» и «Дата») - тоже не решение.
Справочник содержит ~500 млн строк, 70 Gb кластерный индекс, порядка 100 Gb прочие индексы..
Создание нового индекса - к бабке не ходи - подвесит работу всего склада блокировками на полчаса минимум.
Это при том, что технологическое окно — 20 мин в сутки, расписано по минутам (крупные реструктуризации — тот еще цирк..).
И весить структура будет гигабайты.
Если более нигде этот индекс не нужен — то веского обоснования создания нет.
А он, как ни странно, не особо нужен:
- в sys.dm_db_missing_index_... хоть и есть похожий, но даже не в первой сотне (за месяц ~100 unique_compiles, ~350 user_seeks).
- в топе тяжелых запросов ничего к Работам, кроме разбираемого случая, не светится
- ведущий говорит, что ему не надо (и я таки после предыдущих пунктов верю) 

Рекомендовал попробовать получать ту же информацию, но из других источников (кидать запрос к документам, которые плодит обработка). 
Думают..
 

Из недавнего, случай номер два

Заданий (jobs в SQL Server Agent) по пересчету статистик на главном sql-сервере — всего два.
Одно раз в три часа отрабатывает, в нем все наиболее динамически меняющиеся объекты (таблица итогов регистра остатков, резервов, шапки основных документов вроде расх. накл. и т. п.). С десяток объектов. 
Второе отрабатывает раз в сутки, объекты туда попадают по факту наличия сбоев (слетел план запроса по регистру такому-то — убедились, что пересчет статистик помог, добавили в джоб строчку «UPDATE STATISTICS _AccumRgT...» с комментарием «смотри задача нумер такой-то»).
Переместили пересчет статистик таблицы итогов остаточного регистра «РезервТоваров» из первого во второе (как так вышло - дело десятое..).
Как результат — спустя неделю задача вида «один из важных процессов склада периодически идет критически медленно».

Пользователя и период его «медленной» работы предоставили.
Смотрю статистику по пользователю (длительные dbmssql в тежурнале)

Запрос простенький

SELECT
    ...
FROM 
    (SELECT DISTINCT  T2._Q_000_F_000RRef AS Q_001_F_000RRef, T2._Q_000_F_001RRef AS Q_001_F_001RRef FROM #tt967 T2 WITH(NOLOCK)) T1
    LEFT OUTER JOIN 
        (SELECT
            T4._ТоварRRef AS ТоварRRef,
            ...
            CAST(SUM(T4._Количество) AS NUMERIC(32, 8)) AS КоличествоBalance_
        FROM 
            _РегистрНакопления.РезервТоваров(Итоги) T4
        WHERE 
            T4._Период = ? AND ((T4._ТоварRRef IN (SELECT T5._Q_000_F_000RRef AS Q_003_F_000RRef FROM #tt967 T5 WITH(NOLOCK)) AND (T4._СкладRRef = ?)))
        GROUP BY 
            ...
        HAVING (CAST(SUM(T4._Количество) AS NUMERIC(32, 8))) <> 0.0
        ) T3
    ON ((T3.ТоварRRef = T1.Q_001_F_000RRef) AND (T3.БлокRRef = T1.Q_001_F_001RRef))
    ORDER BY (T1.Q_001_F_000RRef), (T1.Q_001_F_001RRef)

Код тоже

    ВЫБРАТЬ
        Товары.Товар КАК Товар, Товары.Блок КАК Блок, Резервы.Документ, Резервы.Вид, ….
        ЕСТЬNULL(Резервы.КоличествоОстаток, 0) КАК Остаток
    ИЗ
        (ВЫБРАТЬ РАЗЛИЧНЫЕ Товар, Блок ИЗ времТов) КАК Товары
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.РезервТоваров.Остатки(, Товар В (Выбрать Товар ИЗ времТов) И Склад = &Склад) КАК Резервы
        ПО Резервы.Товар = Товары.Товар И Резервы. Блок = Товары. Блок

Вообще-то этот запрос за миллисекунды обычно отрабатывает
Гляжу статистику исполнения (лог sys.dm_exec_query_stats) – обнаруживается начало сбоя

Записи, выделенные зеленым — относятся вообще 16 января (вывел историю в надежде глянуть «как оно было ранее» - получилось)
«Плохие» исполнения начинаются с 05:55 10 января (на самом деле раньше, но статистика фиксируется только с этой точки)

Аналогично нахожу завершение «плохих» исполнений 

Причем здесь есть возможность глянуть и «плохой», и «хороший» планы исполнения (плюсики, отмеченные фиолетовым).

«Хороший план», как и ожидалось — по кластерному индексу таблицы итогов регистра (измерения Товар,Блок,Склад,...)

Отбираем из кластерного таблички итогов РезерваТоваров записи по периоду (3999-11-01) и списку товаров, проверяем выбранное на склад и сливаем со списком товаров/блоков (merge).
Нормально.
Можно и лучше, но нормально.


«Плохой» план.. тут ожидал пробежки по индексу реквизита «Склад», но реальность еще интереснее

Отбираем из кластерного таблички итогов РезерваТоваров ВСЕ записи по периоду (в seek predicates только _Период), потом в найденном проверим склад..  .
И ожидается, что получим одну строчку.
А уж потом мы залезем в список товаров (nested loops) и т. д.
Явно по табличке статистики кривые.

В данном случае решение — просто перенесли пересчет статистик таблицы итогов регистра «РезервТоваров» назад, в задание «раз в три часа»
И нормализовалось.

Более правильное решение, как представляется — переписать запрос так, чтоб в seek predicates попадали все четыре условия: по _Период, _Товар, _Блок и _Склад
Вполне реально, если загнать во времянку все четыре поля и соединять — страшно сказать — с РегистрНакопления.РезервТоваров.Остатки(,) без условий в срезе.
Это вроде идет против всех правил и наставлений по написанию запросов, однако начиная с mssql2012 часто вижу, что оптимизатор в планах исполнения успешно загоняет соединения в самое начало последовательности исполнения, раскрывая скобки подзапросов виртуальной таблицы Остатки().. поумнел.
Вот попробовал 

    ВЫБРАТЬ
    …
    ИЗ
        времТов КАК Товары
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.РезервТоваров.Остатки(,) КАК Резервы
        ПО Резервы.Товар = Товары.Товар И Резервы.Блок = Товары.Блок И Резервы.Склад = Товары.Склад

и получил что требовалось

Clustered Index Seek  в данном случае имеет Seek Predicates  вот такой (в скриншот категорически не лезет): 
Seek Keys[1]: Prefix: BINARYIS([skladM].[dbo].[_РегистрНакопления.РезервТоваров(Итоги)]._Период; [skladM].[dbo].[_РегистрНакопления.РезервТоваров(Итоги)]._ТоварRRef; [skladM].[dbo].[_РегистрНакопления.РезервТоваров(Итоги)]._БлокRRef; [skladM].[dbo].[_РегистрНакопления.РезервТоваров(Итоги)]._СкладRRef,Scalar Operator([@P1]); Scalar Operator([tempdb].[dbo].[#tt151].[_Q_000_F_000RRef] as [T1].[_Q_000_F_000RRef]); Scalar Operator([tempdb].[dbo].[#tt151].[_Q_000_F_001RRef] as [T1].[_Q_000_F_001RRef]); Scalar Operator([tempdb].[dbo].[#tt151].[_Q_000_F_002RRef] as [T1].[_Q_000_F_002RRef]))
Видно, что поиск в индексе по периоду и трем первым измерениям регистра.
Количество логических чтений (даже с учетом создания индекса, создание которого я для верности воткнул во времянку) — уменьшилось до 120-250
Хороший вариант, но люди от него шарахнутся, как черт от ладана.. срез без условий..  Да и толку бизнесу от этой вкусовщины немного, пара микросекунд прибыль не принесет — и так «good enough»...

Этот прием нельзя рекомендовать как общее правило.. слишком много оговорок и условий для стабильной работы 
(желательно текущие итоги /не задана дата/, присоединение РегистрНакопления.ИМЯ.Остатки(,) внутренним или левым к времянке, которая содержит измерения регистра начиная с первого, условия соединения по измерениям с первого и далее — чтоб ложилось в кластерный; минимальное количество таблиц в запросе,  лучше времянка + ..Остатки(,) ).

Спустя пару дней после написания абзаца заглянул — как оно работает? Так вот  - увидел «хороший» план, только merge join сменился на Nested Loops, и Clustered Index Seek  идет .. по периоду и первым трем измерениям!.. оптимизатор сообразил поменять два обращения к времянке местами (условие виртуальной таблицы Остатков по «товар в выборке» проверяет уже после поиска в кластерном регистра). Чудеса, однако..

Вывод раз. 
Несмотря на принятое решение «оставить как есть и чаще пересчитывать статистику», в похожих случаях лучше всеж переписать запрос.. 
Упростить, иногда разобрать на несколько времянок — но в каждом запросе пакета оставить оптимизатору один, наиболее очевидный и выгодный вариант. 
Если запрос важен для бизнес-процесса, то пусть работает на пять микросекунд дольше и плодит на две сотни логический чтений больше — зато стабильно, без срывов и отказов.. да и вас ночью не разбудят.

Вывод два.
В регистре резервов измерение «Склад» почему-то не на первом месте. Поиск в конфигураторе выдает сотни три ссылок по «РезервТоваров.Остатки», просмотрел наискосок около трети — везде отбор по складу или набору складов. Насчитал десять исключений (из них три похожи на баги). Однако - и по первому теперешнему измерению "Товар" отбор тоже всегда есть. Скорее теоретический вопрос, "как бы оно было бы лучше"..

Вывод три.
Вспомнил вот хорошую статью  (Автору отдельное спасибо за скрипт настройки немедленной рассылки «писем счастья» вида «SQL Server Alert System: 'Error 9002' occurred on \\VS1Test07» - пользуюсь)
Там поминалось  о пересчете статистик в зависимости от даты последнего обновления и количества изменений в таблице со времени последнего обновления.
Ну и накидал скрипт апдейта.. страховочный, с условиями having max(sp.modification_counter) > 20000 and min(STATS_DATE(o.[object_id], ss.[stats_id])) < DATEADD(day, -3,GETDATE()) and ISNULL(SUM(sp.[rows]),SUM(p.[rows])) > 300000
Запускаю его раз в день, от описанного инцидента не спасет, но может поможет в чем другом.
Теперь думаю — нельзя ли поменять параметры и его переделать на запуск раз в час, чтоб спасал "от всего"..
Может есть у кого что-то похожее?


Из стародавнего, случай номер три

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

Результаты = Запрос.ВыполнитьПакет();

Исполнение пакета запросов, внутри десяток запросов. Какой? Нашли в техжурнале. Но почему?
В общем, когда оно три дня спустя изволило вернуться — я уже ждал с профайлером наперевес..
Запрос немудреный (не стал его совсем вырезать — закомментировал на память..) 

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

Остаточный регистр накопления ОстаткиТоваров — брат-близнец РезерваТоваров, с измерениями Товар, Блок, Склад,...
Вот тут как раз было переключение на план исполнения по индексу измерения «Склад» !
Оптимизатору казалось, что начать с отбор с таблицы итогов по периоду и складу, а уж далее в найденном проверить (nested loops) на список товаров — отличная идея.
На деле же на складе оказывалось весьма много записей, index seek выходил долгим и возвращал довольно много строк.
UPDATE STATISTICS соответствующего _AccumRgT.. + чистка кеша планов запросов поправляли дело — план менялся на  index seek в кластерном .. но ситуация повторялась черед день-два.
Пикантность ситуации состояла в том, что UPDATE STATISTICS того регистра (и вообще всех значимых) в то время работал чуть не «раз в час» (еще не умели толком ловить конкретные запросы, и действовали в соответствии с тактикой «Алеша, посыпь его мелом»).
Т.е. оно и так пересчитывается с дикой частотой, но в какой-то момент невыгодный план  все равно оказывается в кэше.
Наверное тогда в первый раз сознательно применили тактику «пусть чуть хуже, но много стабильнее».
Загнали подзапрос с товарами во времянку, и вторым этапом соединили времянку с виртуальной таблицей остатков (остатки брали строго со всевозможными отборами - тогда еще вольностей себе не позволяли).  
Работать стало стабильно.
Даже когда позже начали снижать частоту запуска UPDATE STATISTICS и выкидывать из нее таблицы по одной — все равно работало стабильно.
До сих пор оно так и работает (и наверное не тронет никто..  ибо "работает - не трогай").

 

Ну и самый типичный случай, не сказать, чтоб «миллионы их»... но полно

Жил-был запрос в пакете.. нормальный, иногда компактный (в пару таблиц), чаще крупный (с десяток и более таблиц), но хорошо работал и всех радовал.
Далее вариации:
- пользователь захотел добавить него еще пару полей, программист добавил пару таблиц, некоторое время работало - потом "опа.."
- таблицы, по которым работал запрос, изрядно выросли - и "опа.."
- у таблиц, по которым работал запрос, поменялась структура - и "опа.."
- просто так, без видимых причин и на ровном месте - "опа.. оно ж работало столько лет.. нет, это твой сервер дурит!"
А потом, на разборе,  видна вот такая например картина исполнений:   
  10000 logical reads, 
  10000 logical reads, 
  10000 logical reads, 
  10000 logical reads,
  500000000 logical reads, 
  500000000 logical reads, 
  ...
И зачастую - не больно-то старая статистика по таблицам запроса.  Апдейт + чистка кэша чаще помогает, но иногда и нет, а иногда "помогает, но не надолго".
Раньше разбирал "плохой" план, разбирал "хороший" и рекомендовал разбить план в соответствии с "хорошим":  "..соединения таких-то таблиц выделить в отдельный запрос, результат - во времянку, далее времянку соединять с ...".
Теперь пишу "упростить запрос, например разбить на два через времянку".. и все.. вполне, оказывается, достаточно в большинстве случаев.

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

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Evil Beaver 6751 05.02.18 12:19 Сейчас в теме
Побольше таких статей, побольше!

А что за утилитка на .NET для анализа техжурналов?
RailMen; GreenDragon; sergey.novikov; sashocq; +4 Ответить
2. logarifm 1076 05.02.18 12:32 Сейчас в теме
И все же я оспорю "плохой" план. У вас производит поиск данных по ключу. А что это значит. Только то что был найден кластерный индекс но поскольку нету покрытия индекса происходит поиск страницы с данными чтобы извлечь информацию.

Дополню: известно то что получить данные дорогостоящая операция поскольку серверу неизвестно на каком витке В-дерева находится страница с данными.
7. w.r. 579 06.02.18 05:46 Сейчас в теме
Было бы хорошо, если бы время выполнения к каждому из запросов приложили (с хорошим и плохим планом)
11. fhqhelp 310 06.02.18 19:10 Сейчас в теме
(7) На скриншотах закладки "подробно статистика исполнения" колонка AvgDuration_ms - оно и есть. Среднее время исполнения в миллисекундах.
Т.е. планы фиксируются автоматом вместе со статистикой исполнения, далее при просмотре статистики можно двойным щелчком в нужной строчке по колонке "plan" открыть заинтересовавший план. Что я, собственно, и сделал.
3. logarifm 1076 05.02.18 12:45 Сейчас в теме
для себя открыл недавно много нового при чтении книги Роберта Вьейра SQL Server 2000 Програмирование. Глава 9 "Структура Индексов"
Ничего нового нет но материал изложен как-то иначе...
4. logarifm 1076 05.02.18 12:49 Сейчас в теме
В данном случае вы ищите данные но еще хотите получить информацию из реквизита которая не покрывается индексом, вот вам и поиск испортился.... Не вижу здесь плохого плана если честно...
5. logarifm 1076 05.02.18 13:06 Сейчас в теме
ошибочка вышла просто ИНДЕКС у вас (я написал кластерный) сбил другой скрин.
6. genayo 05.02.18 23:34 Сейчас в теме
По первому случаю - очередное подтверждение, что кривую архитектуру ни одна СУБД нормально не переварит. Очевидно, что все 500 млн записей хранить, да еще и в одной таблице, никакого смысла нет..
12. fhqhelp 310 06.02.18 19:25 Сейчас в теме
(6) Архитектура - зачастую данность, которую не изменить (сложно, долго, дорого). Но, даже с не шибко хорошей архитектурой можно таки ужиться. Даже не так - приходится уживаться, и есть способы уживаться.
>> ..Очевидно, что все 500 млн записей хранить..
Не очевидно, нет.
Было бы ненужно - резали бы нещадно, без придыханий (ну или переливали бы куда).
Хотели было сворачивать.. но что-то не задался проект.
8. echo77 1156 06.02.18 08:28 Сейчас в теме
(0) Хорошая статья. Спасибо.
Тут опечатка, по-моему:
«Плохие» исполнения начинаются с 05:55 10 января (на самом деле раньше, но статистика фиксируется только с этой точки)

Мне кажется, вы имели ввиду 05:55 20 января

и скрины, все таки лучше в .png делать
13. fhqhelp 310 06.02.18 19:28 Сейчас в теме
(8) спасибо, да, это опечатка

ок, попробую .png..
9. ADirks 182 06.02.18 09:14 Сейчас в теме
Я бы все запросы, в которых одна и та же табличка используется в фильтре для ВТ, и в условиях соединения, преобразовал бы, убрав вообще фильтры из ВТ. И смысла не вижу (в фильтрах) - т.к. всё равно снаружи ещё фильтр накладывается, и оптимизатору легче.
Типа:

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

преобразовывал бы к

ВЫБРАТЬ
    ...
ИЗ
    (
		ВЫБРАТЬ РАЗЛИЧНЫЕ
	        Товары.Товар КАК Товар,
	        Товары.Блок КАК Блок
	    ИЗ
	        Документ.ПеремТов.Товары КАК Товары
	    ГДЕ
	        Товары.Ссылка = &Ссылка
	) КАК Товары
	
    ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ОстаткиТоваров.Остатки(,) КАК Остатки ПО
		Товары.Товар = Остатки.Товар
		И Товары.Блок = Остатки.Блок
		И Остатки.Склад = &Склад
Показать



И ещё сильно подумал бы, чтобы избавиться от ВЫБРАТЬ РАЗЛИЧНЫЕ. Особенно в подзапросах.
Aleskey_K; +1 Ответить
14. fhqhelp 310 06.02.18 19:43 Сейчас в теме
(9) Да, но есть засада - оптимизатор не всегда сумеет верно оценить количество строк, которые отдаст подзапрос
( ВЫБРАТЬ РАЗЛИЧНЫЕ ..ИЗ Документ.ПеремТов.Товары КАК Товары ГДЕ Товары.Ссылка = &Ссылка )
По разным причинам (например неактуальные статистики по ПеремТов или неудачное значение &Ссылка).
А если выделить этот подзапрос во времянку - такой ошибки быть уже не может.. Количество строк во времянке число абсолютно конкретное, и оно известно оптимизатору ДО создания плана (запроса к остаткам).
Поэтому и предпочитаю времянки.. хуже, да стабильней..
Впрочем, будет ли на этом sql ошибаться в каждом конкретном случае, и насколько часто - еще тот вопрос.. тут практика критерий истины.. тут "эксперимент - сбор статистики - анализ - правки"
Дмитрий74Чел; +1 Ответить
15. KAV2 08.02.18 07:13 Сейчас в теме
16. RailMen 798 08.02.18 09:13 Сейчас в теме
Спасибо за статью. С многим сталкивался. Побольше бы таких статей про "разбор причин замедлений". Это лично мне очень интересно.
17. nvv1970 09.02.18 08:39 Сейчас в теме
Фиксим быстренько планы в хранилище запросов и радуемся )))
18. Armando 1393 24.02.18 02:26 Сейчас в теме
3. Нереальное решение проблемы — переделать со справочника на регистр сведений

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

Диапазон дат не уменьшить — данные выводятся за текущую смену (несколько временных интервалов во времянке #tt497, суммарно ~8 часов)

Если это текущая смена сотрудника, почему нельзя сравнивать с датой на равенство? Если в справочнике поле Дата включет время, то в предлагаемом регистре можно сделать без времени и брать по равно, и отказаться от соединения. Только для ночных переходящих смен может не взлететь, если они есть.
Дмитрий74Чел; +1 Ответить
19. Sergey.Noskov 1144 29.03.18 14:03 Сейчас в теме
Спорное решение проблемы — новый индекс для таблицы _Reference4544 объекта _Справочник.РаботыПоДокументам, по полям _СотрудникRRef, _ВидРаботRRef, _Дата, с include-полями _Документ_TYPE, _Документ_RTRef, _Документ_RRRef.
Но 1С штатно такое делать не умеет.
Вопрос создания новых /модификации стандартных индексов — тема спорная..

Обидно, что любая дискуссия с 1С на эту тему заканчивается ничем. И основной довод (который уже проявился и в коментах) - сами виноваты, проектируйте лучше (есессно в завуалированной форме). Т.е. из условий задачи вычитается факт существования системы, её владельцы (бизнес), их затраты на "переделку по правилам". Влияет еще и изменяемость самих бизнес-процессов, когда вчерашняя архитектура уже не соответствует потребностям сегодня.
Ограничивать разработчиков - Ок, они должны действовать по стандартам и методикам. И это правильно. Но текущая позиция 1С косвенно генерирует ограничения для бизнеса, чего бизнес не любит.
21. fhqhelp 310 30.03.18 21:17 Сейчас в теме
(19) >>.. заканчивается ничем ..
Это вроде-бы уже не так.
От однозначного "нет, это нарушение закона" риторика на партнерском форуме вроде смещается в сторону "не рекомендуется, на ваш страх и риск, и забудьте в этом случае про техподдержку".
Хотелось бы, конечно, более быстрого развития событий.
Оставьте свое сообщение

См. также

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

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

30.10.2017    28724    0    MrWonder    42    

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

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

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

25.06.2020    1737    0    ivanov660    12    

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

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    5878    0    DataReducer    22    

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

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

18.05.2020    1600    0    Aleksey.Bochkov    3    

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

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

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

22.04.2015    39998    0    Gilev.Vyacheslav    1    

Эти занимательные временные таблицы

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

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    9917    0    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

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

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    3201    0    feva    14    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    11042    0    informa1555    21    

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

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

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

22.01.2014    66400    0    yuraos    112    

Многострочный контекст событий

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

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

31.03.2020    2730    0    vasilev2015    9    

Анализ взаимоблокировок

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

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

20.03.2020    4003    0    vasilev2015    21    

Многопоточность

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

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    6040    0    kaliuzhnyi    43    

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

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

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

21.06.2013    53190    0    Антон Ширяев    116    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    7974    0    Evil Beaver    13    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

23.01.2020    5817    0    darkdan77    59    

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

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

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

19.02.2013    53840    0    Gilev.Vyacheslav    46    

Улучшаем производительность 1С. Рекомендации

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

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    7098    0    Kaval88    26    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    9843    0    ivanov660    16    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    6892    0    EugeneSemyonov    11    

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

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

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

11.02.2013    29597    0    gallam99    19    

Обслуживание баз данных. Не так просто, как кажется

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

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    16296    0    YPermitin    28    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    8446    0    Repich    5    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    17388    0    Sloth    24    

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

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

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

03.11.2012    41788    0    madmpro    32    

Хранение файлов - как уменьшить размер базы данных

Чистка базы Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 Россия Бесплатно (free)

Хранение файлов в базе 1С можно оптимизировать для уменьшения размера хранимых данных.

09.09.2019    7921    0    2tvad    17    

Анализ производительности APDEX

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

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

31.08.2019    9757    2    YPermitin    7    

Неочевидные проблемы производительности: важность системного подхода при анализе

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    8428    0    Филин    12    

Ловля блокировок на связке "Microsoft SQL server - 1С"

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    9054    0    fhqhelp    0    

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка v8 Бесплатно (free)

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

02.07.2019    10553    0    igordynets    119    

Ускорение чтения правил обмена в УПП 1.3 в 20 раз!

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

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    9291    0    YPermitin    16    

Хотите снизить нагрузку на процессор сервера в 2 раза?

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

В статье рассмотрено влияние частого запуска регламентных заданий на процессор сервера 1С.

27.06.2019    8885    0    Дмитрий74Чел    6    

Непридуманные истории по оптимизации. История 1

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

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    12062    0    Repich    117    

Оптимизация: неэффективные запросы

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

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

13.06.2019    5564    0    slayer-ekb    10    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    22735    0    dmurk    144    

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С

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

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    17638    0    ivanov660    9    

Не думать о секундах свысока...

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

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    7571    0    vasilev2015    21    

Альтернативная стратегия управления блокировками

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

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    6793    0    zhichkin    15    

Мониторинг SQL Server с помощью Extended Events (и не только) для 1С. Как держать руку на пульсе?

Производительность и оптимизация (HighLoad) Бесплатно (free)

Что и как мониторить в работе SQL Server, чтобы держать Вашу систему в форме.

05.05.2019    31267    0    YPermitin    23    

Как работают управляемые блокировки

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

29.04.2019    21159    0    comol    198    

Странное потребление места на диске С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    13678    0    kuzyara    12    

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

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

25.04.2019    13053    0    Elf1k    27    

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

18.04.2019    27610    0    ivanov660    77    

Как разбить базу на файлы и не сойти с ума

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    14936    0    YPermitin    30    

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз

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

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    14962    0    w.r.    23    

Простое программное решение проблем с блокировками SQL

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

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    8597    0    dmitrydemenew    38