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

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.

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

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

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


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

 


См. также

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

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024    7312    Evg-Lylyk    61    

42

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

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

13.03.2024    4277    spyke    28    

48

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

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

13.03.2024    6494    vasilev2015    20    

40

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

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

2 стартмани

15.02.2024    10235    207    ZAOSTG    74    

110

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

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024    4426    glassman    17    

40

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

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

09.01.2024    9362    doom2good    49    

70
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Smert-nik 24.03.21 16:43 Сейчас в теме
Спасибо за публикацию. Но есть пожелание, получать ссылки в виде текста, а не скринов, думаю не каждый найдет силы набрать ссылку врунчную
2. vikad 130 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 167 24.03.21 20:30 Сейчас в теме
(4)
Сразу же видно разницу в запросах

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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

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

(10)
Чистится и об этом сказано
Я никого не учу, я делюсь своим опытом, за полчаса доклада нельзя охватить все нюансы работы сервера 1С и скуля, поэтому пробежался по верхам и дал ссылки где почитать. Желающий разобраться в вопросе пройдет, прочитает и разберется
Да, возможно стоило уточнить про статистику, в моем случае она очищалась перед каждым запуском нагрузочного теста
17. Gilev.Vyacheslav 1916 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 1916 25.03.21 12:36 Сейчас в теме
(21) удовольствие Вам девушки доставлять должны, а на работе надо дело делать
9. PerlAmutor 130 24.03.21 20:36 Сейчас в теме
С компонентой штрих-кода в ERP проблема была и у нас при переходе с одной версии ERP на другую. В ТЖ действительно ничего полезного не удавалось найти, но зато удавалось найти в обычном EventViewer'е Windows, где косвенно, по именам файлов, можно было догадаться, что исключение возникало внутри одной из внешних компонент 1С.
11. AlexKriulin 167 24.03.21 21:11 Сейчас в теме
(9) Виндовый event viewer тоже смотрел, была ошибка на core83.dll и ещё на какой-то библиотеке, уже не помню какой
А можно подробнее, как Вы поняли что дело в компонентах?
Я ковырял эти ошибки и дампы открывал, наверное не хватило знаний и опыта...
12. PerlAmutor 130 24.03.21 21:14 Сейчас в теме
(11) Где-то там промелькнула надпись "ExtCompT".
22. asved.ru 36 25.03.21 10:25 Сейчас в теме
(11)
Смотрим стек падения, имена библиотек в нем. Для внешней компоненты характерно имя, соответствующее временному файлу. Также видна версия файла. Осталось найти в конфигурации ВК с бинарником с соответствующей версией.
Ну и в целом по последовательности вызовов в стеке даже без символов можно что-то предполагать.

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

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

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