Ожидания RESOURCE_SEMAPHORE и RESOURCE_SEMAPHORE_QUERY_COMPILE – внешние проявления, и как с ними бороться

Публикация № 794607 03.03.18

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

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

Рассматривается один из типов массовых проблем в рабочих базах на связке «1С - MS SQL Server».
Случается стабильно несколько раз в квартал, всегда только на одном и том же сервере (из трех основных рабочих).
Возможно дело в том, что он standart 2012 (с соответствующим ограничением по максимуму оперативки), а может из-за того, что на более всего баз и пользовательских соединений (по количеству).
Симптоматика: «во всех базах сервера все мертво встало». Ехали, ехали, ехали — стоп. И стоит. Всё. Во всех пяти десятках баз.
Поскольку на сервере крутится расчет зарплаты, а также лежит основная бд техподдержки - реакция почти всегда мгновенна. Ночью, правда, не будят — сами спят.. и то хорошо.
Если посмотреть в такой момент в «консоли серверов 1С» сеансы любой причастной бд, упорядочив по «Время вызова (текущее)», то увидим:
 
Куча сеансов с большим «Время вызова (текущее)», Время вызова СУБД(текущее) и заполненным «Соединение с СУБД».
Очень напоминает ожидания на блокировках, и блокировки (как автоматические, так и управляемые) в наличии таки часто есть, но являются следствием (не исходной причиной проблем).
 
Если же смотреть на sql-сервер процедурой exec [sp_WhoIsActive] (или просто «активити монитором») - то картинка примерно такая:
 
Или вот такая:
 
Если отсортировать по «количеству использованной памяти»
exec [sp_WhoIsActive] @sort_order = '[used_memory] 
то наверх обычно вываливается три-четыре-пять одинаковых (с точностью до номеров времянок) запросов.
(и вероятно  exec sp_BlitzCache @ExpertMode = 1, @SortOrder = 'memory grant' покажет ту же картину. )
 
Вот искусственно созданный пример:
 
Согласно документации, [used_memory] — для активного запроса — количество восьмикилобайтовых страниц, использованных при выполнении этого запроса
Т.е. 2076855 * 8 Kb ~= 15 Gb.
Выделено 15 Gb на исполнение одного запроса.. а я их для верности четыре штуки запустил.
Минус 60 Gb у сервера.
А этот экземпляр - вообще-то Microsoft SQL Server 2012 Standard Edition — т.е. «Максимальный объем используемой памяти = 64 ГБ»
 
Глянув на историю sys.dm_os_memory_clerks (что потребляло память sql-сервера ) можно увидеть скачки MEMORYCLERK_SQLQERESERVATIONS (выделение памяти под исполнение запросов: When a query needs memory for sort/hash operations..)
 
В те же моменты видно снижение выделения памяти под кэш планов исполнения CACHESTORE_SQLCP, а часто и снижение памяти под кеш страниц данных MEMORYCLERK_SQLBUFFERPOOL (на данном графике нет вытеснения страниц данных — только потому, что серверу, который я выбрал для экспериментов, выставили maximum server memory в 110 Gb.. он хоть и стандарт — а все 110 забрал, под буферпул пользует максимальные 64, а прочий объем частью пользуется под все, кроме буферпула, а частью простаивает.. почти всегда.. но, как видите, иногда и идет в дело)
 
Не знаю точно, есть ли иные причины (интернет намекает, что для RESOURCE_SEMAPHORE_QUERY_COMPILE есть), но чаще всего вижу именно это: запрос (или несколько одинаковых) запускаются, съедают значительный кусок оперативки под исполнение, прочие запросы встают или на стадии компиляции (оно ж тоже хочет память!) , или на стадии исполнения (hash join-ы изрядно могут кушать, Hash Match Aggregate любит память  ,а также случается Sort в памяти).
 
Возникло стремление выявить топ чудесных запросов, потребляющих оперативку.
 
Сделать это можно с помощью анализа истории представления статистики исполнения sys.dm_exec_query_stats .
Начиная с Service Pack 3 (KB3072779) в Microsoft SQL Server 2012 у представления sys.dm_exec_query_stats появляются новые поля total_grant_kb и total_used_grant_kb — зарезервированная под исполнение и реально использованная запросом память. (ну и понятно, в SQL Server 2016 они уже с самого начала есть, а SQL Server 2014 под рукой нету).
Нам нужно первое, но представляет интерес и второе (об этом ниже) .
 
Исходная мысль была «найти запросы за проблемный период с максимальным суммарным значением total_grant_kb».
Нашлось несколько запросов со сканами небольших таблиц их последующим hash-соединением.
А ожидаемые запросы, которые были мне вживую видны в ходе проблем через  exec [sp_WhoIsActive] @sort_order = '[used_memory] - не нашлись..
Посмотрев на запросы со сканами небольших — понял, что они все быстрые (несколько миллисекунд) и погоды особо не делают.. ну забрал он 100 Mb на 10 мс.. ну так он тут же их отдал, как исполнился.
 
Мысль трансформировалась в «найти запросы за проблемный период с максимальным суммарным значением (total_grant_kb * время_исполнения_запроса. Идея, думаю, ясна..
Вот тут-то они все и полезли на свет..
 
 
 

Пример реальных проблем рабочего сервера.

Наблюдались проблемы с бд техподдержки и прочими базами sql-сервера h01 19 и 20 февраля.
В тот день нашел и поправил все "вручную", наблюдениями за сервером с помощью [sp_WhoIsActive], раскопками в журнале регистрации и т.д.
Теперь, спустя некоторое время - пытаюсь найти "корень бед" используя свою систему сбора и анализа информации по производительности серверов.
В процессе допиливаю ее немного напильником..
 
Смотрим ожидания сервера:
Есть блокировки, и ожидания RESOURCE_SEMAPHORE в наличии.. По блокировкам — убеждаюсь, что Head blocker-ами выступали запросы, повисшие на тех же RESOURCE_SEMAPHORE (как изучались блокировки здесь не разбираю — это отдельная тема).
Смотрю лог sys.dm_os_memory_clerks за те же дни: 
 
Хорошо видны моменты выделения оперативки под запросы.
Буду изучать три выделенных зеленым периода:
19.02.2018 07:00 — 19:00 (весь день меня эта штука мучила, очень хорошо помню)
20.02.2018 08:00 — 17:00
21.02.2018 08:00 — 17:00
 
Изучаю первый период, дополнил просмотрщик параметром «Полученная память на время (grant_kb * Duration_ms)».
 
Пара лидеров отлично видна — отчет в базе техподдержки и какое-то странное обращение к sys.spt_procedure_params_view
Третье место можно даже не смотреть пока.
Первый запрос (Отчет.ОтчетПоЗадачам) — довольно тяжелый, по 200 тыс логических чтений.. исполняется за секунду в среднем (есть прыжки до десятка секунд — это следствие тормозов на RESOURCE_SEMAPHORE видимо).
А количество запросов (колонка cnt) – по сто-двести за 30-60 мин (от creation_time до last_execution_time). Отчет популярный. Чего уж там - сам пользуюсь..
 
Смотрим выделение памяти (прокрутил нижнюю таблицу до нужных колонок)
 
Сервер выдает (avg grant_kg) по 2.5 Gb на запрос!
А запрос использует (avg used_grant_kg) из этого богатства менее 100 Kb!
В чем дело?
 
Смотрим текст и план исполнения:
SELECT
  T1._СсылкаRRef,
  ...
FROM
  _БизнесПроцесс.Обращение T1 WITH(NOLOCK)
  LEFT OUTER JOIN _БизнесПроцесс.Задание T2 WITH(NOLOCK)
  ON ((T1._СсылкаRRef = T2._ОбращениеRRef) AND (T2._ОсновноеЗаданиеRRef = @P3))
WHERE
  (T1._ПометкаУдаления = 0x00) AND (T1._ИнициаторRRef = @P4) 
  AND (NOT (((T1._СостояниеRRef IN (@P5, @P6, @P7, @P8, @P9, @P10))))) 
  AND CASE WHEN (@P11 = @P12) THEN CASE WHEN (@P13 <= T1._Дата) THEN 0x01 ELSE 0x00 END ELSE CASE WHEN ((T1._Дата >= @P14) AND (T1._Дата <= @P15)) THEN 0x01 ELSE 0x00 END END = 0x01
UNION ALL
SELECT
  ...
FROM
  _БизнесПроцесс.Задание T3 WITH(NOLOCK)
  LEFT OUTER JOIN _БизнесПроцесс.Обращение T4 WITH(NOLOCK)
  ON (T3._ОбращениеRRef = T4._СсылкаRRef)
WHERE
  (T3._ИнициаторRRef = @P18) 
  AND (NOT (((T3._СостояниеRRef IN (@P19, @P20, @P21, @P22, @P23, @P24))))) 
  AND CASE WHEN (@P25 = @P26) THEN CASE WHEN (@P27 <= T4._Дата) THEN 0x01 WHEN NOT (@P28 <= T4._Дата) THEN 0x00 END ELSE CASE WHEN ((T4._Дата >= @P29) AND (T4._Дата <= @P30)) THEN 0x01 WHEN NOT ((T4._Дата >= @P31) AND (T4._Дата <= @P32)) THEN 0x00 END END = 0x01
ORDER BY
  13, 6, 5, 1, 15

План содержит только одно подозрительное место:

Сканирование кластерного индекса _БизнесПроцесс.Задание с предикатом [_ИнициаторRRef]=[@P18] AND [_СостояниеRRef] <>[@P24] [_СостояниеRRef] <>[@P23] AND [_СостояниеRRef] <>[@P22 ... AND [_СостояниеRRef]<>[@P19]
Индекса по полю Инициатор нету.
Скорее всего кто-то промахнулся он нужен.
Но, несмотря на скан — оптимизатор довольно реалистично оценивает количество возвращаемых сканом строк, Estimated number of rows болтается в районе десяти (с десяток планов посмотрел, за очень разные периоды)... какого ж ему надо гигабайты — неясно. О том, чтоб скан сам по себе требовал память — не слыхал. Возможно, есть какая-нить пессимистичная оценка Estimated number of rows, и по ней выдается память на финальный Sort? Сплошные домыслы.. Может кто в курсе?
 
Локальный итог, однако, таков : создал требуемый индекс под запрос (он - запрос - такой оказался не один), скан ушел..
 
Смотрим статистику, вот собственно момент перехода:
 
Видно, что запрос становится быстрее, логических чтений на два порядка меньше, CPU потребляет на порядок меньше.. а что с памятью?
 
 
Теперь хочет всего полтора-два мегабайта на экземпляр.. ну отлично. Меня устраивает.
 
Смена индекса была 20.02.2018 в 15:40, однако подозрительные всплески расхода оперативки на запросы были и далее:
20.02.2018 08:00 — 17:00
21.02.2018 08:00 — 17:00
Тут уже работал странный запрос к sys.spt_procedure_params_view 
 
Не вдаваясь в подробности — мне удалось безболезненно нейтрализовать его к вечеру 21.02.2018
После этого живу вроде спокойно (это касается RESOURCE_SEMAPHORE на h01, о прочих аспектах моей жизни такого не скажешь - даже соседи кулачные бои на 23-е устраивали, не говоря уж о проблемах с серверами и кластерами).
 
Собственно, вот - спустя полторы недели после сбоя я нашел в статистике то, что видел и правил 19 и 20 февраля вживую.
 
 

Выводы 

Если на sql-серврере в наличии ожидания RESOURCE_SEMAPHORE и/или маловато оперативки — стоит регулярно просматривать топ запросов с максимумом (total_grant_kb * Duration_ms). И править хотя бы откровенные несуразности (вроде того самого скана кластерного).
Эти же запросы могут и обнаружиться в топе длительных, в топе потребляющих CPU, или в топе по логическим чтениям.. а могут и не обнаружиться!
В моем случае ни один из явных лидеров-пожирателей оперативки на всех трех рабочих серверах в передовиках по прочим ресурсам — не присутствовал. Т.е. все мои регламенты (~раз в два-три месяца просмотр/правка длительных, потребляющих CPU, с максимум физ чтений, обслуживание топ 3 блокирующих  + раз в неделю обслуживание топ 3 по логическим чтениям) — не имели шансов избавить меня от RESOURCE_SEMAPHORE.
 
В качестве бонуса — из памяти сервера ушел индекс PK___BPr45N__AC8ED0C47B030392
Вот топ 7 индексов/куч в памяти (в буферпуле) sql-сервера h01 за период:
 
До 20.02.2018 кластерный таблицы [БизнесПроцесс.Задание] постоянно торчал в буферпуле сервера, отжирая 2.2 Gb
Убрав сканирующий его запрос — освободил и память (понятно, тот запрос был не один такой — но все равно эффект заметен)
Наверное, будет в какой-то мере работать и обратное.. Анализируя наполнение буферпула и убирая наиболее вопиющие сканирующие запросы — есть вероятность уменьшить прыжки MEMORYCLERK_SQLQERESERVATIONS и соответственно снизить риск RESOURCE_SEMAPHORE.
 
 

P.S.:

Поизучал на своих рабочих и тестовых серверах запросы, требующие оперативку.
И условно раздел их на четыре группы.
 
1. Оно им и правда надо. Здоровенные, неповоротливые, исполняются раз в день — но по нескольку часов. Статистические расчеты. Заливки olap-кубов. Отчеты за год-два по всей сети по всем товарам. Переливки данных. Вот такое тоже лезет: Рег.УстановитьПериодРассчитанныхИтогов(ПериодРассчитанныхИтогов_Новый);
Вот так выглядит:
Данный запрос хочет на исполнение вообще 900 Gb.. ему дают 45.. и он исполняется 4 часа.
Это заливка куба на сервере со статистикой, к 1С не имеет отношения вообще.
План исполнения этого монстра в монитор не лезет, ни по высоте, ни по ширине.. а однако большой у меня монитор..
Обычно такие запросы и так уже в фокусе внимания (гляньте на количество чтений и расход CPU..).
Что тут скажешь.. не держите оперативных oltp-баз на одном сервере со статистическими olap-базами. А если уж деваться некуда — следите за количеством оперативки и ядер, да и версии standart и express не для этого варианта.
 
2. Откровенные косяки, с пропущенным индексом, со сканом и последующим hash match или sort. Они не слишком крупны / часто запускаемые, чтоб быть замеченными в топ 10 по потреблению CPU, или в топах по логическим и физическим чтениям.. но они есть, и они крадут память.
Вот такое например:
Три с половиной мегабайта — немного, но количество исполнений в течение 10 мин = 3-10 тыс — мое почтение..
Бывает и по-другому: исполняется раз в минуту, но желает гигабайт..
Причем, большей частью такое исправляются легким указанием «индексировать» в конфигураторе у соотвествующего поля нужного объекта.
Такие надо выявлять да чинить..
 
3. Непонятности, похожие на ошибки оптимизатора. Вроде нормальный план, правда, обязательно со сканом. Но при этом скан небольшой таблицы, Estimated number of rows от Actual number of rows близки к нулю.
Вот такое:
Стрелки тонкие, Estimated number of rows везде =1 , в реальном плане Actual number of rows тоже близко к 1.
С чего ж он хочет гигабайт и не использует потом из него совсем ничего?
Похожий случай мне и попался на h01
Оказывается, их таких довольно заметное количество.
 
4. Слеты планов
Когда план "ломается" — тоже, оказывается, может случается расход оперативки.
Оно и понятно — вылез скан вместо поиска, а следом сорт..
 
 

PPS:

Накаркал, дописался статей..
02.03.2018 в 13:30 на единственном рабочем
    Microsoft SQL Server 2012 (SP3) (KB3072779) - 11.0.6020.0 (X64)
    Oct 20 2015 15:36:27
    Copyright (c) Microsoft Corporation
    Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.3 <X64> (Build 9600: )
230 Gb оперативки
случился RESOURCE_SEMAPHORE:
 
В пятницу, в полдень ближе к вечеру.. традиция.
 
Зафиксировал текст / источник / объект / автора, убил сессии, запретил запускать.
В понедельник буду разбираться.. есть надежда, что план исполнения "испортился"..
 

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. bulpi 185 04.03.18 10:18 Сейчас в теме
1)Эта статья была бы значительно полезнее для 1с-ников, если бы Вы приводили тексты запросов на языке 1с
2)Что касается запроса по бизнес-процессам, то ошибка, ИМХО, очевидна, и это не отсутствие индекса, а отсутствие ограничения выборки по дате снизу.
triviumfan; +1 Ответить
2. fhqhelp 329 04.03.18 19:38 Сейчас в теме
Да, наверное нужно было исходный код.
Отбор по дате есть.
Тут методологическое скорее.. отчет запускается с пустыми по-умолчанию датами, и работает ветка "ВЫБОР КОГДА &Дата2 = ДАТАВРЕМЯ(1, 1, 1) ТОГДА &Дата1 <= Обращение.Дата" .. т.е. "И '1753-01-01 00:00:00' <= Обращение.Дата"
Отбор есть - толку нет.
На предложение "а давайте воткнем по-умолчанию последний год" последует "а у нас задания и по пять лет висят".

ВЫБРАТЬ
    ...
ИЗ
    БизнесПроцесс.Обращение КАК Обращение
        ЛЕВОЕ СОЕДИНЕНИЕ БизнесПроцесс.Задание КАК Задание
        ПО Обращение.Ссылка = Задание.Обращение И (Задание.ОсновноеЗадание = ЗНАЧЕНИЕ(БизнесПроцесс.Задание.ПустаяССылка))
ГДЕ
    НЕ Обращение.ПометкаУдаления
    И Обращение.Инициатор = &Инициатор
    И НЕ Обращение.Состояние В (&СписокСост)
    И ВЫБОР КОГДА &Дата2 = ДАТАВРЕМЯ(1, 1, 1) ТОГДА  &Дата1 <= Обращение.Дата ИНАЧЕ Обращение.Дата МЕЖДУ &Дата1 И &Дата2 КОНЕЦ
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
    ...
ИЗ
    БизнесПроцесс.Задание КАК Задание
        ЛЕВОЕ СОЕДИНЕНИЕ БизнесПроцесс.Обращение КАК Обращение
        ПО Задание.Обращение = Обращение.Ссылка
ГДЕ
    Задание.Инициатор = &Инициатор
    И НЕ Задание.Состояние В (&СписокСост)
    И ВЫБОР КОГДА &Дата2 = ДАТАВРЕМЯ(1, 1, 1) ТОГДА &Дата1 <= Обращение.Дата ИНАЧЕ Обращение.Дата МЕЖДУ &Дата1 И &Дата2 КОНЕЦ
Показать
3. bulpi 185 05.03.18 09:54 Сейчас в теме
(2)
Не.... Такой отбор по дате не поможет. Поздно пить боржоми, когда почки сели :) Нужно не полениться, и ввести отборы по дате ВНУТРЬ каждой таблицы, а именно : заменить текст
ВЫБРАТЬ
...
ИЗ
БизнесПроцесс.Обращение КАК Обращение

На
ВЫБРАТЬ
...
ИЗ
(ВЫБРАТЬ
* ИЗ 
БизнесПроцесс.Обращение 
ГДЕ Дата>=&ДатаНижнейГраницы
) КАК Обращение


Пусть даже эта ДатаНижнейГраницы будет 5 лет назад. Ты же выбираешь сначала ВСЕ (все миллионы записей), а потом уже в последнем ГДЕ отсекаешь по дате, это не помогает.
4. triviumfan 27 05.03.18 21:10 Сейчас в теме
(2) Странно, криминала то тут не видно =\ Может отбор по дате в соединение "запилить"?
7. fhqhelp 329 08.03.18 14:21 Сейчас в теме
(4)
Да не суть важно..
Конкретный запрос можно починить кучей способов - вопрос-то в другом..
Вопрос - как их выявлять, и желательно заблаговременно, до катастроф
5. Armando 1395 05.03.18 22:07 Сейчас в теме
Для SQL 2012 SP 3 расход памяти для sort или hash можно посмотреть в плане запроса при SET STATISTICS XML ON
https://support.microsoft.com/ru-ru/help/3107400/improved-tempdb-spill-diagnostics-in-showplan-xml-schema-in-sql-server
triviumfan; +1 Ответить
6. fhqhelp 329 08.03.18 14:17 Сейчас в теме
(5)
SET STATISTICS XML ON

Вроде должно у меня показывать, но не вижу..
Спасибо, поразбираюсь..
8. nvv1970 12.04.19 12:34 Сейчас в теме
Отличная статья.
Сам впервые столкнулся с подобного рода ожиданием.
Попробуем оценить выделение памяти....
Оставьте свое сообщение

См. также

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) Промо

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

Если вы используете SQL Server 2016 или более позднюю версию, то у вас есть возможность использовать встроенную систему мониторинга, которая позволяет отслеживать самые базовые метрики выполняемых запросов и статистику ожиданий (потребления ресурсов). Эта информация позволяет быстро получить самые ресурсоемкие запросы с их планами и агрегированной статистикой выполнения.

26.04.2019    13675    Aleksey.Bochkov    7    

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

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

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

07.09.2021    2860    ivanov660    22    

Показатель Page Life Expectancy (PLE)

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

От переводчика: публикация составлена по материалам BrentOzar.com (Brent Ozar).

18.08.2021    1109    vasilev2015    6    

Кластер для отказоустойчивости

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

На Infostart Meetup «PostgreSQL VS Microsoft SQL» выступил руководитель проектов в по разработке ПО в компании «Газинформсервис» Денис Рожков. В рамках доклада Денис рассказал о том, какие механизмы кластеризации используются для PostgreSQL и в MS SQL и поделился с коллегами, какие решения можно использовать для построения отказоустойчивого кластера на PostgreSQL.

18.08.2021    1330    FB_3393521717335803    0    

Опыт миграции из собственного датацентра в облако AWS Промо

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

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    12174    Aleksey.Bochkov    9    

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

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

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

13.08.2021    2753    Shmell    7    

Создаем счетчики производительности Windows для 1С

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

В статье описан подход, позволяющий создавать счетчики производительности Windows для 1С:Предприятие.

09.08.2021    3278    blackhole321    8    

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

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

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

05.08.2021    1308    cdiamond    0    

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

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

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

30.10.2017    32436    MrWonder    42    

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

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

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

02.08.2021    8267    ivanov660    77    

Fill factor

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

От переводчика: Публикация составлена по материалам BrentOzar.com (Brent Ozar).

02.08.2021    2501    vasilev2015    6    

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

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

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

01.06.2021    7328    vasilev2015    15    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

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

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    66698    Sergey.Noskov    119    

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

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

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

28.04.2021    5372    vasilev2015    13    

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

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

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

22.04.2021    2088    a.doroshkevich    4    

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

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

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

24.03.2021    4653    AlexKriulin    37    

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

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

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

22.04.2015    43628    Gilev.Vyacheslav    1    

Рецепты приготовления технологического журнала

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

Понимание принципов событий технологического журнала позволяет решать многие проблемы производительности и стабильности работы платформы 1С. О том, как взаимосвязаны события технологического журнала и как с их помощью можно анализировать серверные вызовы 1С, на INFOSTART MEETUP Ekaterinburg.Online рассказал программист 1С из компании ДНС-Ритейл Максим Старков.

22.03.2021    4390    max_st    5    

Анализ полного технологического журнала, 100ГБ+

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

В этой статье рассматривается анализ полного технологического журнала, размер которого за 1 час достигает 50Гб+. Когда у какого-то пользователя что-то происходит, но не постоянно, и выделить определенного пользователя не получается, и проще собрать полный технологический журнал. Но на дальнейшем анализе доступные визуальные средства не выдерживают таких объемов, и просмотр журнала объемом 50Гб попросту вылетает. Но поведение 1С все же хотелось бы изучить и проанализировать, что происходит.

18.03.2021    2527    Axel2009    18    

Анализ производительности: Трассировка + Логи системного монитора

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

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

16.03.2021    926    AlekseyBelyy    8    

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

Нагрузочное тестирование v8 1cv8.cf Бесплатно (free)

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

16.09.2012    36310    Aleksey.Bochkov    29    

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

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

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

12.03.2021    3425    vasilev2015    22    

Негативное влияние большого количества ролей на производительность 1С

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

Столкнулись с интересной проблемой во время работ с базой ERP. Первоначально проблема была в том, что один дописанный функционал работал слишком медленно и требовалось понять почему , однако вскоре выяснилась любопытная деталь – скорость выполнения операции под разными пользователями отличалась.

10.03.2021    3711    aviconsult    21    

"Крест ИТ", или как жить, если у вас в ИТ ландшафте выросло Кудрово/Мурино/Девяткино

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

Добавлять новую функциональность в ИТ-ландшафт, базирующийся на тяжелых «монолитах», с каждым годом становится все сложнее. О способах преодоления проблем больших и сложных приложений на INFOSTART MEETUP Saint Petersburg.Online рассказал архитектор компании BIA Technologies Марат Шайхутдинов.

09.03.2021    975    MSChe    3    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

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

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

15.03.2015    44826    gallam99    17    

Использование системы мониторинга Zabbix с 1С для мониторинга ключевых показателей бизнеса

Zabbix Бесплатно (free)

Мониторинг бизнес-показателей в базе 1С помогает руководителям оперативно принимать решения, реагировать на сбои, видеть реальное состояние каждого из этапов бизнес-процесса. О том, как использовать Zabbix для построения дашбордов и мониторинга ключевых показателей бизнеса, на митапе Infostart Saint Petersburg.Online рассказал Алексей Орловский.

17.02.2021    6340    orlovskiy-a    0    

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

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

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

11.01.2021    26008    user662404_itlexusss    14    

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

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

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

18.12.2020    3194    zhichkin    7    

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

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

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

22.01.2014    68930    yuraos    112    

Контекст всегда важен. История проблем производительности

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

Небольшая история о проблемах производительности из-за нехватки процессорных мощностей. А также описание основных показателей работы CPU.

26.11.2020    7283    YPermitin    21    

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

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

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

07.10.2020    4670    ivanov660    13    

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

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

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

02.10.2020    5255    Nykyanen    16    

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

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

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

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

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

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

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

19.08.2020    26734    YPermitin    38    

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

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

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

17.08.2020    889    ivanov660    0    

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

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

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

20.07.2020    2649    Филин    7    

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

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

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

19.02.2013    61125    Gilev.Vyacheslav    46    

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

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

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

25.06.2020    4263    ivanov660    13    

Выбор процессора для 1С: конец споров или начало?

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

Периодически занимаясь исследованиями производительности я повидал много решений. Делюсь некоторыми выводами на основании теста Гилева и собственных мыслей.

25.05.2020    25675    starik-2005    248    

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

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

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

24.05.2020    10961    DataReducer    22    

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

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

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

11.02.2013    36833    gallam99    19    

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

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

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

18.05.2020    2624    Aleksey.Bochkov    4    

Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

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

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

12.05.2020    8882    SergeyN    3    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

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

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

27.04.2020    5046    ivanov660    5    

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

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

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

03.11.2012    45259    madmpro    32    

Замеры APDEX против "ощущений" бухгалтеров

Автоматизация ИТ-компании APDEX Бесплатно (free)

Очень часто пользователи недовольны, как работает информационная система. Но даже когда ИТ-специалисты все полностью меняют, пользователи остаются недовольными. О том, как объективно оценить проведенные изменения, на конференции Infostart Event 2019 Inception рассказал руководитель ИТ-службы ИООО «Лукойл Белоруссия» Роман Жульпо.

24.04.2020    4779    it-boy    19    

Пример поиска ошибок в технологическом журнале

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

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

23.04.2020    3922    vasilev2015    7    

Фреймворк "Мониторинг производительности". Руководство пользователя

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

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    4792    ivanov660    3    

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

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

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

06.04.2020    15798    YPermitin    0    

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

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

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

03.04.2020    8438    feva    15    

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

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

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

31.03.2020    15764    informa1555    35    

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

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

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

31.03.2020    3798    vasilev2015    11