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

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

Администрирование - Производительность и оптимизация (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 174 04.03.18 10:18 Сейчас в теме
1)Эта статья была бы значительно полезнее для 1с-ников, если бы Вы приводили тексты запросов на языке 1с
2)Что касается запроса по бизнес-процессам, то ошибка, ИМХО, очевидна, и это не отсутствие индекса, а отсутствие ограничения выборки по дате снизу.
triviumfan; +1 Ответить
2. fhqhelp 310 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 174 05.03.18 09:54 Сейчас в теме
(2)
Не.... Такой отбор по дате не поможет. Поздно пить боржоми, когда почки сели :) Нужно не полениться, и ввести отборы по дате ВНУТРЬ каждой таблицы, а именно : заменить текст
ВЫБРАТЬ
...
ИЗ
БизнесПроцесс.Обращение КАК Обращение

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


Пусть даже эта ДатаНижнейГраницы будет 5 лет назад. Ты же выбираешь сначала ВСЕ (все миллионы записей), а потом уже в последнем ГДЕ отсекаешь по дате, это не помогает.
4. triviumfan 17 05.03.18 21:10 Сейчас в теме
(2) Странно, криминала то тут не видно =\ Может отбор по дате в соединение "запилить"?
7. fhqhelp 310 08.03.18 14:21 Сейчас в теме
(4)
Да не суть важно..
Конкретный запрос можно починить кучей способов - вопрос-то в другом..
Вопрос - как их выявлять, и желательно заблаговременно, до катастроф
5. Armando 1393 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 310 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    10691    0    Aleksey.Bochkov    7    

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

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

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

25.06.2020    1737    0    ivanov660    12    

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

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

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

25.05.2020    7383    0    starik-2005    216    

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

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

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

24.05.2020    5879    0    DataReducer    22    

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

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

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

29.07.2018    11145    0    Aleksey.Bochkov    9    

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

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

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

12.05.2020    4373    0    SergeyN    3    

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

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

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

27.04.2020    3567    0    ivanov660    5    

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

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

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

23.04.2020    2349    0    vasilev2015    6    

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

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

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

30.10.2017    28724    0    MrWonder    42    

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

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

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

21.04.2020    2753    0    ivanov660    3    

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

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

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

06.04.2020    9917    0    YPermitin    0    

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

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

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

31.03.2020    11042    0    informa1555    21    

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

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

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

05.08.2015    60311    0    Sergey.Noskov    119    

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

Производительность и оптимизация (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    

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

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

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

22.04.2015    39998    0    Gilev.Vyacheslav    1    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

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

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    4351    0    ildarovich    7    

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

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

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

15.03.2015    39286    0    gallam99    17    

Делаем быстрее POSTGRESQL COUNT (*)

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

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    2181    0    w.r.    1    

Простое обнаружение проблем производительности в PostgreSQL

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

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    3499    0    w.r.    4    

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

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

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

17.02.2020    7974    0    Evil Beaver    13    

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

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

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

22.01.2014    66400    0    yuraos    112    

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

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

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    8696    0    a.doroshkevich    17    

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

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

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

23.01.2020    5817    0    darkdan77    59    

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

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

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

23.01.2020    7098    0    Kaval88    26    

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

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

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

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

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    5338    0    nixel    22    

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

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

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

19.12.2019    9843    0    ivanov660    16    

История роста и работы команд 1С в условиях HighLoad и BigData

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

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    6943    0    user826155    11    

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

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

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

19.02.2013    53840    0    Gilev.Vyacheslav    46    

Весёлые картинки о работе 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    

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

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

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

14.10.2019    16296    0    YPermitin    28    

Набор скриптов для знакомства с SQL Server

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

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

30.09.2019    20593    0    YPermitin    14    

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

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

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

11.02.2013    29597    0    gallam99    19    

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

Производительность и оптимизация (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    

Подбор оборудования для информационных систем на платформе 1С

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

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    8547    0    jf2000    8    

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    

Руководство по SQL: Как лучше писать запросы (Часть 2)

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

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    7097    0    w.r.    2    

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

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

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

31.08.2019    9757    2    YPermitin    7    

Руководство по SQL: Как лучше писать запросы (Часть 1)

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

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    10143    0    w.r.    19    

Использование Union вместо OR

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

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    3745    0    w.r.    35    

Тюнинг производительности запросов в PostgreSQL

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

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    7088    0    w.r.    5    

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

Производительность и оптимизация (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    

Настройка параметров PostgreSQL для оптимизации производительности

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

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    6562    0    w.r.    19    

Сравнительное тестирование работы PostgreSQL с большими страницами Linux

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

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    4397    0    w.r.    6    

Настройка параметров ядра Linux для оптимизации PostgreSQL

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

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    5192    0    w.r.    1