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

Публикация № 1409398 24.03.21

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

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

О теме доклада

 

Наверное, каждый сталкивался с фразой: «У нас все висит, тормозит, ничего не работает – помогите!»

 

 

Что, как правило, делает 1С-ник? Открывает диспетчер задач, в лучшем случае видит загрузку памяти и начинает ее чистить, в худшем – видит картину, когда все вроде бы хорошо, но все тормозит. Тогда начинаются рестарты всего, что можно рестартовать.

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

По своему опыту и опыту коллег скажу, что все тормоза, как правило, возникают из-за неоптимального кода 1С, написанного программистами. Реже – из-за настройки серверов, СУБД и т.д. В любом случае, нет волшебной «галочки», которую можно поставить – и все летает.

В докладе:

  • разберем тормозящие запросы и что с ними делать;

  • научимся убирать ожидания на СУБД MS SQL Server;

  • узнаем, как чинить падающие рабочие процессы сервера 1С.

 

Первая проблема

 

 

Это был старт проекта на ERP:

  • Из типовой ERP использовалось очень мало, буквально пара подсистем. При этом был очень большой самописный модуль.

  • Серверы 1С и СУБД совмещены.

  • Оборудование не загружено.

  • RLS нет.

  • Но при этом все тормозит.

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

 

 

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

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

Наверное, все подумали о том, что проблема во все-таки включенном RLS, потому все и тормозит. Я тоже так решил и пошел его проверять. Оказалось, что он отключен.

 

 

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

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

На слайдах отмечено время в микросекундах – оба запроса выполняются почти мгновенно.

 

 

Откуда тогда могло взяться 3 секунды?

 

 

Давайте погрузимся в теорию. На слайде – типовая картинка с ИТС, показывающая клиент-серверную архитектуру. У нас все было примерно так же. Не было никаких веб-серверов, отладки по HTTP и т.д. – только тонкие клиенты.

Какие компоненты могут тормозить?

  • Первое – СУБД, но она у нас не тормозит. Техжурнал показал, что запрос выполняется быстро.

  • Второе – сеть между 1С и СУБД. Но она тоже не может тормозить, потому что ее попросту нет – у нас для сервера СУБД и сервера 1С используется одна машина. Плюс включен протокол Shared memory – используется общая оперативная память. Сети вообще нет, грубо говоря.

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

  • Остается одно звено – сервер 1С, с ним что-то было не так.

А что было не так?

 

 

Смотрим дальше.

  • Посмотрел, сколько ролей у проблемных пользователей. Оказалось – 1261 роль.

  • Напоминаю, что у нас ERP с подсистемами, которые не использовались. И однажды был создан профиль, который назывался «Для всех». Туда были добавлены вообще все типовые роли ERP без разбора – получилось столько ролей.

  • Также я сохранил конфигурацию в файлы, когда каждый объект метаданных сохраняется в отдельный файлик.

  • Посмотрел размер файлов ролей, и получилось так, что когда мы добавляем самописную роль, мы ставим в нее только пару галочек, поэтому она весит буквально несколько килобайт. А типовые роли за счет ограничений доступа, написанных для RLS, достаточно тяжелые. Они весят мегабайты, максимально – 25 мегабайт.

  • Убрали лишние роли, оставили порядка 150 штук, и все заработало быстро.

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

 

 

Выводы.

  • Не давать пользователю все роли без разбора, 1261 роль – это достаточно много.

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

  • Такое ощущение, что три секунды уходило на то, чтобы сервер 1С сформировал из текста запроса на языке 1С текст запроса на языке SQL. Возможно, он пытался для каждого поля поискать ограничения в выбранных для пользователя ролях. Но, так как он их не находил, то отправлял запрос точно такой же.

На слайде стоят знаки вопросов. Возможно, кто-то меня поддержит, а кто-то опровергнет мои догадки и кинет в меня ссылкой, потому что официального подтверждения своим догадкам я так и не нашел. Такой повод для дискуссий.

 

Вторая проблема

 

 

Перейдем к следующей проблеме:

  • Нагрузочный тест на 600 пользователей.

  • Использовалась также ERP, но практически типовая.

  • Серверы 1С и СУБД разнесены.

  • При начале итерации теста CPU на сервере СУБД возрастало до 100% и не отпускало несколько минут.

 

 

Предприняли самые простые действия.

Собрали трассировку запросов на SQL, сгруппировали, отсортировали по CPU.

На первом месте с большим отрывом – занимал в десять раз больше CPU, чем второе место – оказалось заполнение панельки «Текущие дела». По мере наполнения базы у нас этот запрос выполнялся порядка 15-20 минут. Оно крутится в фоне, никто этого не замечает, но оно нагружает базу.

Удалили эту панельку, стало легче.

 

 

Но раз уж я занимался СУБД, решил заглянуть в механизм ожиданий на SQL. Тут тоже будет немного теории.

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

  • Одно из таких представлений – sys.dm_os_wait_stats. Оно накапливает статистику с момента старта сервера – на чем ожидают запросы: когда запрос хочет, но не может выполниться из-за того, что чего-то ждет. Самый простой пример – блокировки.

  • DMV sys.dm_exec_requests – запросы, которые выполняются прямо сейчас, в эту секунду. Можно посмотреть, сколько они будут выполняться, и ждут ли они чего-то. А если ждут – чего им не хватает.

 

 

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

  • В целом, я ожидал увидеть первый тип, который называется SOS_SHEDULER_YIELD. Если вы его видите на SQL – это значит, что у вас просто малоядерное ЦПУ. Так как у нас была нагрузка, я ожидал увидеть его.

  • Также есть несколько типов, которые говорят о недостаточной производительности дисков – PAGEIOLATCH и WRITELOG

  • И еще один тип ASYNC_NETWORK_IO, который означает, что у вас либо проблема с сетью, либо сервер 1С перегружен настолько, что не может принять результат какого-то запроса.

  • Самое простое – LCK, блокировки.

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

 

 

Итак, мы выполнили запрос к DMV sys.dm_os_wait_stats:

  • SOS_SHEDULER_YELD, который я ожидал увидеть, оказался на втором месте и занимал всего 6% от всех ожиданий;

  • а на первом месте был некий PAGELATCH_UP.

 

 

Еще скриншоты с таблицы sys.dm_exec_requests, где показан список запросов, которые выполняются прямо сейчас.

На этом слайде показано 15 запросов, и все они ждут.

 

 

Здесь – 12 запросов.

 

 

Здесь – 18.

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

 

 

Прочитал определение PAGELATCH_UP – это тип ожидания, который имеет место, когда задача ожидает кратковременной блокировки буфера, находящегося не в состоянии запроса ввода-вывода.

 

 

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

 

 

Выяснил, что Latches – внутренние блокировки SQL-сервера, которые должны быть очень легкими и короткими, незаметными. И они блокируют доступ не на диске, а в оперативной памяти.

Давайте посмотрим, откуда они могли у нас взяться.

 

 

Если посмотреть внимательно на скриншоты таблички sys.dm_exec_requests – с запросами, которые выполнялись прямо сейчас – видно, что:

  • мы всегда ждем один и тот же ресурс – это некая страница 2:1:2;

  • все операции – запросы к базе tempdb, операции с #tt.

  • мы видим здесь команды CREATE TABLE (создание таблицы) и TRUNCATE TABLE (очистка таблицы).

 

 

Здесь еще несколько скриншотов и везде – CREATE TABLE и TRUNCATE TABLE, только страницы другие – 2:3:2, 2:4:2, 2:5:2.

 

 

Чтобы понять, что это за страницы, еще раз обращусь к теории.

  • Многие знают, что в MS SQL Server данные хранятся в страницах. Каждая страница занимает 8 килобайт. И это не настраивается. В PostgreSQL, по-моему, настраивается, но тоже лучше не менять.

  • Страницы, в свою очередь, объединяются в экстенты, по 8 страниц в каждом.

  • В MS SQL Server есть два типа экстентов: однородные и смешанные.

    • однородные – когда в экстенте хранятся данные только по одной таблице;

    • а смешанные – когда можем положить в него 8 разных страниц с данными по разным таблицам и индексам.

 

 

На слайде приведено куча определений – их можно не читать, я постараюсь донести суть.

В каждой базе на MS SQL Server есть ряд служебных страниц, которые контролируют заполненность наших страниц и экстентов.

Когда мы пытаемся добавить, записать какие-то данные, MS SQL Server обращается к картам, смотрит, что у него тут экстент свободный, тут – половинка и там – половинка, и решает, куда класть данные. После этого делает отметку в карте, что экстент заполнен, туда больше ничего не положить.

При очистке – то же самое, только наоборот. MS SQL Server данные из страницы убирает и ставит отметку в карту, что там свободно, можно что-то класть.

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

В случае с базой tempdb все как раз наоборот. 1С-ка с ней работает очень интенсивно – постоянно создает и очищает таблицы, на скриншотах это как раз и было видно – CREATE TABLE, TRUNCATE TABLE. Они на tempdb выполняются постоянно.

Как раз на этих картах у нас и было ожидание – страница 2:1:2 как раз отвечает за то, какие экстенты у нас заняты.

 

 

Решение здесь простое:

  • Разбить базу tempdb на несколько файлов. На сколько разбить? Рекомендации сайта ИТС говорят, что надо разбивать на 4 части.
    Я нашел более универсальную формулу: если у вас количество ядер меньше 8, то количество файлов должно быть равно количеству ядер, а если больше или равно – то количество файлов = 8. В целом, думаю, можно бить просто на 8 файлов и не париться – хуже не будет. Мы так и сделали, ожидания ушли.

  • Вторая рекомендация с сайта ИТС: флаг трассировки 1118. Этот флаг запрещает создание смешанных экстентов. Я этого не делал – мне хватило первой рекомендации. Но если у вас конкуренция за доступ к ресурсу 2:1:3, который отвечает как раз за смешанные экстенты – можно попробовать включить этот флаг. Но пользоваться этим нужно аккуратно, потому что если вы отключите смешанные экстенты, база будет расти.

 

Третья проблема

 

 

Еще одна ситуация:

  • Платформа 8.3.15.

  • Сервер 1С и сервер СУБД разнесены,

  • На сервере 1С – пять баз.

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

  • Но периодически вываливались непонятные ошибки.

Например, на слайде показана ошибка, с которой закрывалась 1С в разных базах, у разных пользователей. Это доставляло дискомфорт, с этим нужно было что-то сделать.

 

 

Для исследования настроили все возможные мониторинги.

  • Техжурнал с событиями, которые отвечают за работу сервера 1С: ATTN, PROC, CLSTR и тд.

  • Счетчики производительности Windows конкретно для процессов 1С: rphost, ragent, rmngr.

  • Изменили одну настройку: количество ИБ на процесс. У нас было 2, установили единицу.

Для чего это сделано? Когда количество ИБ=2, у вас один rphost хоть каждый день может обслуживать разные базы: в первый день у вас rphost обслуживает 1С:ERP и 1C:Документооборот, во второй день – 1С:Документооборот и БП, в третий – ЗУП и ERP и т. д. Когда возникает ошибка с падением – мы вылетаем из двух разных баз.

Чтобы понять: проблемы в какой-то из баз или платформа падает сама по себе – сделана вот такая настройка, что один rphost обслуживает одну базу.

Это дало результат – мы обнаружили, что падает только ERP. Мы хотя бы починили 4 базы из 5 – они падать перестали.

 

 

На слайде показан скриншот дампов, которые создавались из-за падений процессов. Здесь видно, что нет никакой закономерности, база падает каждый день по несколько раз. Из этого ничего было особо непонятно.

 

 

Это график потребления памяти одним из упавших rphost-ов. График получен с помощью стандартного мониторинга производительности Windows – Perfmon.

Мы видим график памяти:

  • перед падением нет никакого скачка, роста потребления;

  • нет и падения – не видно, что он пытается это отпустить, передать соединение на другой rphost;

  • он просто идет, живет своей жизнью и резко обрывается.

Снизу – запись rphost-а перед падением. В них нет описания ошибки, есть исключение операционной системы и больше никакой информации: «Я устал, я ухожу – вот тебе дамп, делай с ним, что хочешь».

Зачастую, когда падают rphost-ы, в логах rphost последней записью бывает прямо строчка кода, из-за чего он рухнул. И тогда сразу становится понятно, куда смотреть и что произошло. Но тут такого не было.

 

 

Дальше:

  • Попробовали открывать наши созданные дампы. Там были ссылки на библиотеку Windows, которая не могла быть источником проблемы.

  • Пособирали полный техжурнал, попытались найти закономерности – это нам тоже ничего не дало.

  • Тогда мы поставили экстремальную настройку, количество соединений на процесс = 1, из-за которой для каждого соединения создавался свой rphost. Нам повезло, что заказчик был достаточно лояльный и пошел нам навстречу с тяжелыми экспериментами. В результате rphost-ов было больше 100, все очень сильно тормозило, пользователи так поработали полдня. За эти полдня мы выловили несколько падений, надеялись увидеть какую-то закономерность: какой пользователь падает, выполняется ли перед этим какой-то запрос или форма. Нам это ничего не дало. Каждое падение было уникальным.

 

 

Идеи стали заканчиваться. Мы исследовали багборд 1С на предмет ошибок платформы и ERP, но ничего похожего по нашим симптомам не нашли. Google тоже ничего похожего не дал.

 

 

Решение нашлось случайно на партнерском форуме 1С. Там уже была создана тема с точно такими же симптомами, как у нас. Оказалось, что проблема была во внешней компоненте печати штрихкодов, которая лежит в общем макете в базе ERP.

Мы не нашли никаких ошибок, потому что эта компонента входит в состав библиотеки подключаемого оборудования. Когда мы искали ошибки на багборде, их нужно было искать не в платформе, не в системе, а в библиотеке.

Скачали новую библиотеку, обновили этот макет и падения ушли.

 

Вопросы

 

Создаваемые вами роли были отдельные (одна роль на один объект) или составные? И как вы догадались, что вес роли влияет на производительность? Это просто был перебор всех возможных комбинаций?

Роли мы создавали отдельные на каждый объект, составных ролей не было. А по поводу веса – не знаю, как догадался. То ли вычитал в интернете, то ли сам решил сделать это. Я до сих пор не уверен, что именно вес здесь вызвал проблему. Возможно, проблема была в количестве полей.

Поделитесь, какая версия MS SQL Server была, что вы словили проблему с tempbd с PAGELATCH_UP. Современный MS SQL Server по умолчанию ставит 8 файлов для tempdb.

У нас был MS SQL Server 2014. И там по умолчанию стоял один файл для tempdb.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Ekaterinburg.Online. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в тематических митапах Инфостарта и INFOSTART EVENT 2021 (6-8 мая, СПб).

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Smert-nik 24.03.21 16:43 Сейчас в теме
Спасибо за публикацию. Но есть пожелание, получать ссылки в виде текста, а не скринов, думаю не каждый найдет силы набрать ссылку врунчную
2. vikad 120 24.03.21 16:56 Сейчас в теме
(1) Все ссылки продублированы в тексте. Какую ссылку вы не нашли в тексте?
3. Smert-nik 24.03.21 17:10 Сейчас в теме
(2) Думал первой нет, а там на нее несколько раз ссылаться. Приношу извинения
4. toypaul 68 24.03.21 19:19 Сейчас в теме
"Сразу же видно разницу в запросах" и на картинке "Тексты запросов одинаковые!" 10 раз перечитал так и не понял какую разницу сразу видно в запросе
7. AlexKriulin 76 24.03.21 20:30 Сейчас в теме
(4)
Сразу же видно разницу в запросах

Разницу в запросах видно на скринах выше, где замеры из конфигуратора
5. toypaul 68 24.03.21 19:22 Сейчас в теме
"Возможно, он пытался для каждого поля поискать ограничения в выбранных для пользователя ролях" если динамический список (что скорее всего), то конечно каждое поле (объектное) будет проверяться на предмет вывода
8. AlexKriulin 76 24.03.21 20:32 Сейчас в теме
(5) Нет, там был обычный запрос, не ДС.
конечно каждое поле (объектное) будет проверяться на предмет вывода

Нууу, по-крайней мере для меня поначалу это было неочевидно
6. Gilev.Vyacheslav 1883 24.03.21 19:24 Сейчас в теме
(0) статья ничего нового не содержит, более того, даже начинающий "1С:Эксперт" кучу несоответствий заметит

по RLS - вы рекомендации на ИТС не читаете по религиозным соображениям?

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

третий кейс особенно радует, настраиваем все подряд и скрестив пальцы что то где то ищем. А потом гуглим. А потом "Решение нашлось случайно на партнерском форуме 1С. ". А что делать тем кому случайно не найдется?
А потом, ну а скачали бы новый библиотеку а проблема не ушла, что дальше по вашей методике, сухари сушить?
EliasShy; firma_unix; t278; spec8s; +4 1 Ответить
10. AlexKriulin 76 24.03.21 21:03 Сейчас в теме
(6)
статья ничего нового не содержит

Для вас конечно нет, у вас многолетний опыт оптимизации, а вот "начинающим экспертам" думаю некоторые моменты будут интересны


(6)
по RLS - вы рекомендации на ИТС не читаете по религиозным соображениям?

Когда запрос выполняется под неполными правами сильно дольше, чем под полными, то первая мысль, по крайней мере у меня, хотя думаю что у большинства тоже, это RLS


(6)
по ожиданиям скуля - вас послушать так можно игнорировать время старта скуля

Статистика ожиданий очищалась перед запуском теста


(6)
вы так вместо задержек на создание временных таблиц словите очереди к диску

Очевидно, что время отклика диска и очередь к диску также мониторились, была хорошая СХД на nvme дисках, проблем не было
К тому же, с 2016 версии скуль по умолчанию предлагает бить темпДб на 8 файлов, наверное в этом что-то есть
ТемпДб на диске С это, конечно, сильно и тут уже дело явно не в количестве файлов


(6)
настраиваем все подряд и скрестив пальцы что то где то ищем

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


(6)
что дальше по вашей методике

По мне, дальше только писать в 1С с дампами и ТЖ. Предложите своё решение, что бы вы сделали дальше на моём месте?
15. Gilev.Vyacheslav 1883 24.03.21 21:22 Сейчас в теме
(10)
Очевидно, что время отклика диска и очередь к диску также мониторились,
да ну, кому очевидно?
19. AlexKriulin 76 25.03.21 08:50 Сейчас в теме
(15)
При нагрузочном тесте не мониторить железо? Серьезно?

(17)
Ну а я о чём сказал? Дальше только писать в 1С, а они далеко не всегда быстро отвечают, а падает сейчас
В статье есть скрин с дампами, не надо проходить никаких курсов эксперта чтобы понять из чего складываются имена файлов

(10)
Чистится и об этом сказано
Я никого не учу, я делюсь своим опытом, за полчаса доклада нельзя охватить все нюансы работы сервера 1С и скуля, поэтому пробежался по верхам и дал ссылки где почитать. Желающий разобраться в вопросе пройдет, прочитает и разберется
Да, возможно стоило уточнить про статистику, в моем случае она очищалась перед каждым запуском нагрузочного теста
17. Gilev.Vyacheslav 1883 24.03.21 21:33 Сейчас в теме
(10)
что бы вы сделали дальше на моём месте?
ну для начала я бы не стал писать / докладывать в таком ключе.
По большому счёту рассказали как вам "фортануло".
То что вы "доложили" называется "систематическая ошибка выжившего".
На курсах эксперта как минимум расказывают про рассшифровку имени файла дампа ИмяПроцесса_Релиз_АдресОшибки_ГГГГММДДЧЧММСС_PIDПроцесса.mdmp, по характерным фрагментам имени "АдресОшибки" можно обратиться в 1С и получить информацию есть ли решение дампов подобного характера.
21. imh0593 25.03.21 09:49 Сейчас в теме
(6)Вы хороший специалист, но работать с Вами навряд ли мне доставило бы удовольствие.
parshin; JohnyDeath; BomjBandit; AlexKriulin; +4 Ответить
23. Gilev.Vyacheslav 1883 25.03.21 12:36 Сейчас в теме
(21) удовольствие Вам девушки доставлять должны, а на работе надо дело делать
9. PerlAmutor 125 24.03.21 20:36 Сейчас в теме
С компонентой штрих-кода в ERP проблема была и у нас при переходе с одной версии ERP на другую. В ТЖ действительно ничего полезного не удавалось найти, но зато удавалось найти в обычном EventViewer'е Windows, где косвенно, по именам файлов, можно было догадаться, что исключение возникало внутри одной из внешних компонент 1С.
11. AlexKriulin 76 24.03.21 21:11 Сейчас в теме
(9) Виндовый event viewer тоже смотрел, была ошибка на core83.dll и ещё на какой-то библиотеке, уже не помню какой
А можно подробнее, как Вы поняли что дело в компонентах?
Я ковырял эти ошибки и дампы открывал, наверное не хватило знаний и опыта...
12. PerlAmutor 125 24.03.21 21:14 Сейчас в теме
(11) Где-то там промелькнула надпись "ExtCompT".
22. asved.ru 35 25.03.21 10:25 Сейчас в теме
(11)
Смотрим стек падения, имена библиотек в нем. Для внешней компоненты характерно имя, соответствующее временному файлу. Также видна версия файла. Осталось найти в конфигурации ВК с бинарником с соответствующей версией.
Ну и в целом по последовательности вызовов в стеке даже без символов можно что-то предполагать.

Но в общем случае дамп - это к 1С.
Gilev.Vyacheslav; +1 Ответить
13. Gilev.Vyacheslav 1883 24.03.21 21:14 Сейчас в теме
(10)
Когда запрос выполняется под неполными правами сильно дольше, чем под полными, то первая мысль, по крайней мере у меня, хотя думаю что у большинства тоже, это RLS

Вы до сих пор не читали рекомендации на ИТС?!!!
24. Slava_prog 25.03.21 13:23 Сейчас в теме
(13)
Дайте ссылку пожалуйста.
27. пользователь 25.03.21 17:33
Сообщение было скрыто модератором.
...
14. Gilev.Vyacheslav 1883 24.03.21 21:20 Сейчас в теме
(10)
Статистика ожиданий очищалась перед запуском теста

статистика автоматом чистится при рестарте скуля
только вы явно не въезжаете
вы когда исследуете продуктив, то учите людей опрашивать не пойми какую статистику
у кого то сервер полгода аптайм имеет, он там такого надиагностит
если уж рассказываете про вьюшку значений в буфере, то уж надо объяснять что нас интересует статистика за как можно более точный период статистики относительно старта и конца наблюдения проблемной операции
иначе правильных выводов сделать практически невозможно
16. Gilev.Vyacheslav 1883 24.03.21 21:24 Сейчас в теме
(10)
К тому же, с 2016 версии скуль по умолчанию предлагает бить темпДб на 8 файлов, наверное в этом что-то есть

18. t278 45 25.03.21 02:55 Сейчас в теме
хоть бы в конце статьи выводы описали чтобы не читать всю статью
20. sapervodichka 4683 25.03.21 09:19 Сейчас в теме
Полезная статья, автору, спасибо!
ardn; wowik; +2 Ответить
25. Slava_prog 25.03.21 13:31 Сейчас в теме
Вчера разбирался с проблемой как в №1.
База во Фрэше конфигурация Розница.
В РМК при нажатии кнопки оплаты (например Наличные) 1с висит 1-2 минуты.
Под полными правами 1-5 сек
Есть ограничения по магазинам, но их отключения не помогло.
Профиль типовой Кассир
28. Rustig 1292 25.03.21 18:29 Сейчас в теме
(25), (26)
ничё себе, как бывает!
26. starik-2005 2527 25.03.21 15:01 Сейчас в теме
Компонента ШК (и не только) - потоконебезопасна. Если одновременно печатаются два документа (разные пользователи, их много, они одновременно нажимают "Печать"), то происходит падение rphost. Мы это сто лет назад нашли и решили мьютеком (писал об этом раз пять, в частности о том, как реализовать мьютекс на 1С - в моих публикациях ищите если интересно). Этим же страдала компонента СЛК, тем же страдала компонента печати QR-кодов...
29. rukalico 25.03.21 22:37 Сейчас в теме
Кто-нибудь еще подтверждает Проблему 1 с большим количеством ролей? (без РЛС)
Неужели такой косяк живет в платформе. Например в типовом профиле Бухгалтер ЕРП находится 450 ролей.
30. AlexKriulin 76 26.03.21 07:27 Сейчас в теме
(29)
https://infostart.ru/1c/articles/1398274/ вот тут у ребят такая же проблема вспыла, недавно читал
Я сам больше ни разу не ловил такой кейс на проектах, хотя как-то даже специально пытался воспроизвести - не получилось
31. TSSV 1069 26.03.21 09:26 Сейчас в теме
Кто-нибудь еще подтверждает Проблему 1 с большим количеством ролей? (без РЛС)

Вот здесь о том же: https://infostart.ru/1c/articles/262271/
32. rukalico 26.03.21 11:53 Сейчас в теме
(30) (31) Читал, да интересные случаи.
Просто кажется, что вроде тогда у всех прям должна быть проблема такая.
У меня как раз профиль на 1100 ролей есть (к сожалению).
Вот думаю стоит ли его бежать разгружать.
Gilev.Vyacheslav; +1 Ответить
34. Gilev.Vyacheslav 1883 26.03.21 12:50 Сейчас в теме
(32) в последнее время фирма 1С изменила подход в типовых
теперь делается регистр, куда после записи данных документом стартует фоновик и пишет результирующее право доступа по всем ролям и группам
38. Rustig 1292 06.05.21 16:58 Сейчас в теме
(34) давно пора промежуточные регистры использовать для хранения такой и подобной инфы, а не на лету права в запросах определять....уж сколько копий сломано....
33. Slava_prog 26.03.21 12:25 Сейчас в теме
В старых конфигурация (УТ 10.3) так и было - по одной роли на пользователя.
Потом 1С придумала новую методику - куча ролей.

Почему платформа при создании юзера не может объединить все его роли и хранить у себя в памяти одну объединенную для работы ?
Serg O.; TMV; +2 Ответить
35. rukalico 26.03.21 12:58 Сейчас в теме
(34) В последнее время это когда и в каких версиях каких типовых, не подскажете?
Являюсь счастливым обладателем ЕРП 2.4.13.71
36. Gilev.Vyacheslav 1883 26.03.21 14:51 Сейчас в теме
(35) версию не подскажу, не запомнил, но вероятно более поздние релизы
37. Fox-trot 138 27.03.21 05:34 Сейчас в теме
название статьи больше на замануху похоже
нестандартных проблем
так и не огласил
Оставьте свое сообщение

См. также

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

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

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

22.04.2015    44062    Gilev.Vyacheslav    1    

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

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

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

20.10.2021    1742    sorter1    2    

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

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

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

09.09.2021    584    info1i    4    

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

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

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

07.09.2021    4213    ivanov660    23    

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

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

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

16.09.2012    36471    Aleksey.Bochkov    29    

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

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

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

13.08.2021    3645    Shmell    7    

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

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

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

02.08.2021    9519    ivanov660    77    

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

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

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

01.06.2021    9071    vasilev2015    17    

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

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

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

22.01.2014    69201    yuraos    112    

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

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

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

28.04.2021    1335    buganov    0    

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

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

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

28.04.2021    5795    vasilev2015    13    

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

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

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

22.04.2021    2500    a.doroshkevich    4    

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

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

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

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

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

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

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

12.03.2021    3634    vasilev2015    22    

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

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

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

09.02.2021    978    pashamak    2    

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

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

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

11.01.2021    26268    user662404_itlexusss    14    

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

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

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

19.02.2013    61385    Gilev.Vyacheslav    46    

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

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

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

18.12.2020    3616    zhichkin    7    

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

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

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

07.10.2020    5067    ivanov660    13    

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

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

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

02.10.2020    5462    Nykyanen    16    

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

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

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

11.02.2013    38252    gallam99    19    

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

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

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

14.09.2020    1934    capitan    25    

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

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

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

20.07.2020    2761    Филин    7    

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

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

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

24.05.2020    11582    DataReducer    22    

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

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

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

03.11.2012    45388    madmpro    32    

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

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

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

18.05.2020    2688    Aleksey.Bochkov    4    

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

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

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

06.04.2020    16677    YPermitin    0    

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

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

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

03.04.2020    9135    feva    15    

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

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

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

31.03.2020    16179    informa1555    35    

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

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

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

31.03.2020    3911    vasilev2015    11    

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

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

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

20.03.2020    7205    vasilev2015    34    

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

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

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

18.03.2020    8983    kaliuzhnyi    45    

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

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

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

17.02.2020    15168    Evil Beaver    13    

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

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

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

23.01.2020    7462    darkdan77    59    

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

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

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

23.01.2020    13887    Kaval88    26    

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

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

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

19.12.2019    15554    ivanov660    49    

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

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

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

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

14.10.2019    22345    YPermitin    31    

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

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

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

13.09.2019    10257    Repich    6    

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

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

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

09.09.2019    10019    2tvad    17    

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

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

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

19.07.2019    9767    Филин    12    

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

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

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

16.07.2019    12652    fhqhelp    0    

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

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

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

02.07.2019    12935    igordynets    120    

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

HighLoad оптимизация Инструменты администратора БД v8 1cv8.cf Бесплатно (free)

Решение проблемы "Нарушена целостность структуры конфигурации".

28.06.2019    6669    Repich    4    

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

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

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

27.06.2019    10888    YPermitin    17    

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

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

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

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