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

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.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    2969    spyke    26    

42

Быстродействие типовой 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    5104    vasilev2015    19    

37

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7631    158    ZAOSTG    67    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    5973    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

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

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8859    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

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

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5100    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16170    skovpin_sa    14    

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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

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

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

Но в общем случае дамп - это к 1С.
Gilev.Vyacheslav; +1 Ответить
13. Gilev.Vyacheslav 1910 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 1910 24.03.21 21:20 Сейчас в теме
(10)
Статистика ожиданий очищалась перед запуском теста

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

18. t278 56 25.03.21 02:55 Сейчас в теме
хоть бы в конце статьи выводы описали чтобы не читать всю статью
20. sapervodichka 6697 25.03.21 09:19 Сейчас в теме
Полезная статья, автору, спасибо!
ardn; wowik; +2 Ответить
25. Slava_prog 25.03.21 13:31 Сейчас в теме
Вчера разбирался с проблемой как в №1.
База во Фрэше конфигурация Розница.
В РМК при нажатии кнопки оплаты (например Наличные) 1с висит 1-2 минуты.
Под полными правами 1-5 сек
Есть ограничения по магазинам, но их отключения не помогло.
Профиль типовой Кассир
28. RustIG 1351 25.03.21 18:29 Сейчас в теме
(25), (26)
ничё себе, как бывает!
maksa2005; +1 Ответить
26. starik-2005 3033 25.03.21 15:01 Сейчас в теме
Компонента ШК (и не только) - потоконебезопасна. Если одновременно печатаются два документа (разные пользователи, их много, они одновременно нажимают "Печать"), то происходит падение rphost. Мы это сто лет назад нашли и решили мьютеком (писал об этом раз пять, в частности о том, как реализовать мьютекс на 1С - в моих публикациях ищите если интересно). Этим же страдала компонента СЛК, тем же страдала компонента печати QR-кодов...
maksa2005; Serg O.; +2 Ответить
29. rukalico 25.03.21 22:37 Сейчас в теме
Кто-нибудь еще подтверждает Проблему 1 с большим количеством ролей? (без РЛС)
Неужели такой косяк живет в платформе. Например в типовом профиле Бухгалтер ЕРП находится 450 ролей.
30. AlexKriulin 164 26.03.21 07:27 Сейчас в теме
(29)
https://infostart.ru/1c/articles/1398274/ вот тут у ребят такая же проблема вспыла, недавно читал
Я сам больше ни разу не ловил такой кейс на проектах, хотя как-то даже специально пытался воспроизвести - не получилось
31. TSSV 1144 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 1910 26.03.21 12:50 Сейчас в теме
(32) в последнее время фирма 1С изменила подход в типовых
теперь делается регистр, куда после записи данных документом стартует фоновик и пишет результирующее право доступа по всем ролям и группам
38. RustIG 1351 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 1910 26.03.21 14:51 Сейчас в теме
(35) версию не подскажу, не запомнил, но вероятно более поздние релизы
37. Fox-trot 156 27.03.21 05:34 Сейчас в теме
название статьи больше на замануху похоже
нестандартных проблем
так и не огласил
Оставьте свое сообщение