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

26.11.20

База данных - HighLoad оптимизация

+136 –
> > > > > > > >
  • 1. Основные показатели CPU (% load, % user time, % privileged time).gif
  • 2. Доп. показатели (% простоя, % времени прерываний, % времени DPC).gif
  • 3. Показатели C-State.gif
  • 4. Длина очереди к процессору.gif
  • 5. Переключение контекста.gif
  • 6. Моя любимый rphost.gif
  • 7. Сеансы, сеансы, сеансы.png
  • image.png
  • image.png
Небольшая история о проблемах производительности из-за нехватки процессорных мощностей. А также описание основных показателей работы CPU.

Зачем мы здесь

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

Нет, мы не будем рассматривать все возможные проблемы и способы их диагностики в одной публикации. Вместо этого мы начнем с простейшей истории проблем производительности с мощностями CPU. Заодно пройдем по всем доступным счетчикам производительности Windows, которые позволяют диагностировать работу процессорной подсистемы. Большая часть рассмотренных ниже показателей производительности актуальны и для *.nix-систем.

И так, начнем с минимального объема теории.

Не хочу читать

А читать придется, но не много. Рассмотрим основные показатели производительности, которые можно использовать для диагностики работы в части ЦП. Их не много, чуть больше десяти.

 
 % загруженности процессора
 
 % работы в пользовательском режиме
 
 % работы в привилегированном режиме
 
 % времени прерываний
 
 Процент времени бездействия
 
 % времени C1, % времени C2, % времени C3
 
 % времени DPC
 
 C1-переходов/сек, C2-переходов/сек, C3-переходов/сек
 
 Прерываний/сек
 
 Длина очереди процессора
 
 Контекстных переключений/с

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

  • % загруженности процессора
  • % работы в пользовательском режиме
  • % работы в привилегированном режиме
  • Процент времени бездействия
  • % времени прерываний
  • Длина очереди процессора
  • Контекстных переключений/с

Все остальные - по ситуации.

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

Исходная задача

Поставим простую задачу, чтобы было интересней разбираться с перечисленными показателями. Нужно разобраться почему тормозит некоторый сервер, на котором установлен сервер 1С и периодически возникают пиковые нагрузки CPU до 100%. Из основных характеристик сервера - 8 ядер, частота 3.6 GHz, 16 ГБ RAM. Ничего сверхъестественного. Вот так эта нагрузка выглядит в диспетчере задач.

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

Базовые показатели

В первую очередь посмотрим на три базовых показатели нагрузки на CPU:

  • % загруженности процессора
  • % работы в пользовательском режиме
  • % работы в привилегированном режиме

Вот так появление этой нагрузки выглядит в системном мониторе (он же perfmon).

Как мы видим, общий % загруженности процессора доходит до 100 на продолжительное время. При этом % работы в привилегированном режиме держится выше 10%, а иногда доходит и до 60%! Явно что-то не так, но что?

Копнем глубже

Дополнительно посмотрим на другие показатели:

  • % времени прерываний
  • % времени DPC
  • Процент времени бездействия

На графике это будет выглядеть так.

Ничего особенного здесь не видим. Процент времени бездействия упал до 0, что соответствует общей нагрузке под 100%, которую мы видели на предыдущем графике. Показатели % времени DPC и % времени прерываний находятся на минимальном уровне. Значит явных проблем с драйверами, железом или ПО нету. И мы все еще ничего не узнали, пойдем дальше.

Какое состояние

Проверим состояния процессора в части энергосбережения. Может быть дело в этом? (что вряд ли, но взглянем для интереса):

  • % времени C1, % времени C2, % времени C3
  • C1-переходов/сек, C2-переходов/сек, C3-переходов/сек

Количество переключений в секунду отображены пунктиром, а проценты сплошной линией. Вот такой получился график.

Переходов в состояние ниже C1 нет, а они бы были самыми дорогими. Если состояние С1 в рабочим режим переходит за ~10 нс, то C2 уже необходимо 100 нс, а для C3 - 50 мкс. В общем, дело точно не в энергосбережении, и это хорошо! Пойдемте дальше.

Все в очередь

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

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

На графике масштаб изначально 0.001, то есть в спокойном состоянии было около 8 тысяч переключений контекста. Затем мы видим резкий всплеск в момент возросшей нагрузки на ЦП, после чего показатель к предыдущим значениям практически не возвращался. То есть явно возросло количество активных потоков, которые требуют процессорных мощностей. Именно поэтому нужно анализировать этот показатель в динамике, чтобы было с чем сравнивать.

Настал момент посмотреть что за процессы все это вытворяют.

Узнаем правду

Перейдем в старый и добрый диспетчер задач и посмотрим какие процессы в ТОП'е. И о чудо!

Это рабочие процессы сервера 1С! Вот это поворот! Идем в консоль кластера, чтобы понять кто и что делает на сервере.

 
 Очень большой рисунок

Большое количество фоновых задания. В колонке "Процессорное время" теперь можно отследить кто съедает процессорные ресурсы, но не в нашем случае. И обратите внимание на названия информационных баз в первой колонке. Видите странность? (нет, я не про имена). Да, баз достаточно много, причем фоновое задание запускается каждое в отдельной информационной базе. Но что это за задания?

Идем в журнал регистрации и видим там это.

Да, в каждой информационной базе аналогичная картина - каждую минуту запускается фоновое задание обновления полнотекстового индекса. Но неужели это задание так может нагружать сервер?

В нормальных ситуациях - нет. Но если на сервере столько баз...

В общем, в чем проблема понятна. 100 баз на одном сервере с 8 ядрами. А ведь нагрузку могут создавать не только фоновые задания обновления индекса ППД, но и остальное (отчеты, проведение документов и многое, многое другое). Можно услышать оправдание такой настройки - но базы то не большие и в каждой работает по 1 пользователю. Как мы видим, это далеко не аргумент в создании такой конфигурации.

Какое тут решение? Думаю, Вы и сами догадываетесь о возможных решениях. Можете написать в комментариях, если есть что сказать. Но если Ваш ответ - нужно отключать полнотекстовый поиск, потому что он тормозит, то Вы не правы. Все служит своим целям, поэтому лучше сначала разобраться с настоящими причинами проблем.

Мониторинг и сбор информации

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

Очевидно, что нужен мониторинг на постоянно основе. Решений для этого достаточно много, но самым распространенным остается использование Zabbix. На Инфостарт не одна статья написана по этой теме. Ссылки на них добавил в конце публикации, а также вот еще некоторый материал, который может пригодиться:

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

История не из мира Highload

Это была простая история с предсказуемой концовкой. Даже можно сказать - очень упрощенная история. Цель была очень проста - показать какие показатели диагностики ЦП имеются в наличии у каждого под рукой и дать им краткое описание. Как бонус, на графиках мы посмотрели их изменение при возникновении пиковых нагрузок и докопались до истины.

В будущем рассмотрим более сложные примеры связанные с виртуализацией, облаками и прочими ужасами современного мира ИТ. А пока что все.

Всего хорошего и производительного!

 
 Будьте в курсе!

Для Вас интересны темы по разработке на платформе 1С и связанные темы по разработке, администрированию? Присоединяйтесь в Telegram-канал, где будет появляться информация о моих новых статьях и разработках на Инфостарт, выходу обновлений, а также некоторые материалы по не1Сной тематике (СУБД, мониторинг, C# и кое-что другое).

Часть материалов, не подходящих сюда по темам, будут выходить на сайте. Там же можно ознакомиться с полным списком разработок для 1С. Думаю, что будет интересно.

Другие ссылки

Авторские разработки (все разработки на одной странице)

 
 Другие разработки (бесплатные и за $m)

1С контекст потоки процессор ресурсы диагностика

+136 –

См. также

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

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

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

13.03.2024    3589    spyke    28    

47

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

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

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

13.03.2024    5548    vasilev2015    19    

38

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

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

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

1 стартмани

15.02.2024    8313    169    ZAOSTG    74    

101

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

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

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

09.01.2024    6600    doom2good    48    

65

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

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

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

20.11.2023    9436    ivanov660    6    

76

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

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

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

15.11.2023    5361    a.doroshkevich    20    

72

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

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

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

11.10.2023    16608    skovpin_sa    14    

101

Поиск часто повторяющихся запросов. Мониторинг производительности

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

Расскажем, как найти часто повторяющиеся запросы.

05.10.2023    5896    ivanov660    3    

73
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. VKislitsin 968 26.11.20 13:20 Сейчас в теме
Юрий, размещу тут рекламную ссылку на маленькую хитрость настройки PerfMon-a, с Вашего позволения?
BairamovTM; YPermitin; +2 – Ответить
2. IssakN 45 26.11.20 13:25 Сейчас в теме
"Ужасная" титульная картинка) Так и тянет попереключать ползунки:-).
YPermitin; Sh00rick; +2 – Ответить
3. buganov 200 26.11.20 14:16 Сейчас в теме
А еще, раз уж заговорили про очереди, на системах с высокой интенсивностью работы проблемы может создавать журнал регистрации, который генерит очередь к диску. У меня такое было совсем недавно, понять не мог, откуда очередь под 20 и тормоза в системе. Поотключали все лишнее, сначала спали очереди до 8, после очередной чистки ушли очереди и тормоза снова уменьшились.
BairamovTM; +1 – Ответить
20. Дмитрий74Чел 234 23.04.21 16:14 Сейчас в теме
(3) ЖР случаем не "устаревшего" формата sql?
+ – Ответить
21. buganov 200 23.04.21 19:42 Сейчас в теме
(20) sql как раз новый формат. Я про тот, что в тексте хранится
+ – Ответить
4. limus80 26.11.20 14:27 Сейчас в теме
Обычное дело с фоновыми на сервере где оч много однотипных баз.
Просто отключением ненужных заданий, разнесения по времени оставшихся и увеличением их интервалов выполнения снизил нагрузку цп сервера на 20%
+ – Ответить
5. ivanov660 4345 26.11.20 15:09 Сейчас в теме
1. Вообще-то от различных экспертов по 1С я слышал фразу (мне рассказывали через вторые "руки" что даже сами 1С про это говорили), что полнотекстовый поиск - это зло и его лучше не использовать вообще. Т.е.
отключаем его сразу и смотрим что там не так работает.
2. Далее не увидел других важных показателей - очередь к дискам и др., счетчики СУБД, захваты СУБД, время вызова текущее. СУБД я так понимаю стоит на отдельном сервере.
3. А так похоже многовато хостов 1С для 8 ядер.
+ – Ответить
8. PerlAmutor 129 26.11.20 19:49 Сейчас в теме
(0)
Всеми свои цели и средства, лучше сначала разобраться с настоящими причинами.

Что, простите?

(5)
1. Вообще-то от различных экспертов по 1С я слышал фразу (мне рассказывали через вторые "руки" что даже сами 1С про это говорили), что полнотекстовый поиск - это зло и его лучше не использовать вообще. Т.е.
отключаем его сразу и смотрим что там не так работает.


И ваши пользователи сразу заметят тормоза в некоторых формах ERP при подборе контрагентов или номенклатуры. Я пробовал =)

(5)
А так похоже многовато хостов 1С для 8 ядер.

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

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

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

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

Функция ЗаменитьСсылки(Знач ПарыЗамен, Знач Параметры = Неопределено) Экспорт
	
	ТипСтрока = Новый ОписаниеТипов("Строка");
	
	ОшибкиЗамены = Новый ТаблицаЗначений;
	ОшибкиЗамены.Колонки.Добавить("Ссылка");
	ОшибкиЗамены.Колонки.Добавить("ОбъектОшибки");
	ОшибкиЗамены.Колонки.Добавить("ПредставлениеОбъектаОшибки", ТипСтрока);
	ОшибкиЗамены.Колонки.Добавить("ТипОшибки", ТипСтрока);
	ОшибкиЗамены.Колонки.Добавить("ТекстОшибки", ТипСтрока);
	
	ОшибкиЗамены.Индексы.Добавить("Ссылка");
	ОшибкиЗамены.Индексы.Добавить("Ссылка, ОбъектОшибки, ТипОшибки");
	
	Результат = Новый Структура;
	Результат.Вставить("ЕстьОшибки", Ложь);
	Результат.Вставить("Ошибки", ОшибкиЗамены);
	
	// Значения по умолчанию.
	ПараметрыВыполнения = Новый Структура;
	ПараметрыВыполнения.Вставить("УдалятьНепосредственно",     Ложь);
	ПараметрыВыполнения.Вставить("ПомечатьНаУдаление",         Ложь);
	ПараметрыВыполнения.Вставить("ВключатьБизнесЛогику",       Истина);
	ПараметрыВыполнения.Вставить("ПривилегированнаяЗапись",    Ложь);
	ПараметрыВыполнения.Вставить("УчитыватьПрикладныеПравила", Ложь);
	ЗаменаПарыВТранзакции = Истина;
Показать


Очевидно же, что этот участок не изменится, возможно, до следующего обновления конфигурации. Результат будет всегда один и тот же, т.к. тут просто нет параметров с переменным значением. Для чего парсить все это, выполнять построчно, выделять память и в итоге получать на выходе каждый раз одно и то же? Подобные блоки можно было бы выносить в спец.функции с директивой типа "&ГлобальнаяПовторноеИспользование". Собирать статистику использования таких функций и вычислять результат разом для всех самых "популярных" при старте системы. После каждого обновления конфигурации пересчитывать при необходимости, если были внесены изменения в модуль.
+ – Ответить
14. buganov 200 02.12.20 10:01 Сейчас в теме
(8)
какой смысл в каждом отдельном сеансе вычислять результат функции с повторно используемыми параметрами, результаты, которых кэшируются для каждого из сеанса? Почему бы не сделать специальный тип глобальных функций, которые бы позволили вычислять значения один раз при старте сервера и сохранять эти значения при перезапуске для того, чтобы их результат работы был доступен пользователям сразу же при подключении? Нет, 1Ска упорно будет выбирать одни и те же данные из базы, которые, возможно, не меняются годами, под каждым из них, проводить над ними одни и те же вычисления, сотни, тысячи раз.


Вы же понимаете, что старт сервера при таком раскладе должен вычислить ВСЕВОЗМОЖНЫЕ варианты на ВСЕ методы повторного использования?
Например есть условный метод ПолучитьЗначнеиеДопКонстанты(Имя). ЧТо при этом надо вычислить? Какие имена подставлять?

Вы не совсем правильно понимаете смысл повторного использования. Для описанного Вами сценария, когда значения не меняются годами, есть константы. Если какие то значения надо вычислять и они могут измениться и зависят от различных условий, то ПовтИсп тут прям в тему.
И глобавльное кеширование, конечно, хорошо, но в рамках ООО Рога и копыта, где сидит три калеки. Не забывайте, что есть системы с сотнями пользователей и зачем держать в кеше неиспользуемый мусор, который не нужен или был нужен только одному сеансу?

Статистику собирать? А что если сейчас надо, а потом бизнес-процессы будут меняться и станет не надо? Тогда мы получим конкретный такой временной лаг на мусоре.
+ – Ответить
6. Painted 49 26.11.20 18:15 Сейчас в теме
Мораль проста - загляните сначала в диспетчер задач и консоль кластера. И perfmon вам не понадобится.
А обслуживание полнотекстного индекса можно делать пореже, еще лучше ночью.
+ – Ответить
7. insurgut 207 26.11.20 19:45 Сейчас в теме
Но если Ваш ответ - нужно отключать полнотекстовый поиск, потому что он тормозит, то Вы не правы.


Я так и не понял, кто прав кто виноват? Слабенький процессор?
sashapere; +1 – Ответить
9. info1i 223 26.11.20 22:44 Сейчас в теме
Ко мне частенько поступают задачи производительности, в том числе и с загрузкой процессора, и с полнотекстовым поиском.
Как раз на эту тему публикации пример из моего опыта: https://alexanderrudnitskiy.blogspot.com/2019/10/1-1.html
И рекомендации тоже есть.
Разница в том, что не всегда есть возможность оперативно посмотреть, что в данный момент грузит, поэтому часто подобные задачи решаются с помощью технологического журнала.
BairamovTM; ivv1970; YPermitin; +3 – Ответить
10. buganov 200 30.11.20 15:51 Сейчас в теме
(9) Дополню, с Вашего позволения. У Вас в примере
posDlit = match($0, "-");
posCALL = match($0, ",CALL");
LenDlit = posCALL - posDlit;

показывается, что нагрузка = времени вызова, что совсем не равнозначно.
Например. Есть РЗ, которое выполняется раз в минуту. И, чтобы не открывать новое соединение каждый раз, может случиться так, как в конструкции
Пока Истина Цикл
ВыполнитьДействие();
Ожидание(60);
КонецЦикла;


Он всегда будет в топе.

Или другой пример, когда длительный серверный вызов не успел нагенерить проблем, а послал на SQL запрос, который там и крутится. Основная нагрузка будет именно на сервер СУБД, а CALL покажет только длительность вызова и хосты будут простаивать. Запрос может быть длинным, спору нет, но только на длительность опираться не стоит. В последних 8.3. в ТЖ для вызова появились удлобные свойства отслеживания нагрузки на процессор и память. Но для 8.2 и старых 8.3. не работает, к сожалению.
+ – Ответить
11. info1i 223 30.11.20 19:59 Сейчас в теме
(10)
Он всегда будет в топе.

Да, бывало и такое нераз; но на практике в большинстве случаев именно длительные вызовы являются причиной нагрузки процессора. И даже бывали случаи с указанными паузами (БСП и прочие), но мы ведь смотрим целый список топов, поэтому причину трудно не заметить.
Я в курсе про поле CpuTime в ТЖ в новых версиях 8.3; но, к сожалению, у заказчиков используются разные старые версии, и даже 8.2.
Ну и длительные вызовы - это ведь тоже нехорошо (с позиции стабильности и производительности).
+ – Ответить
12. buganov 200 30.11.20 22:48 Сейчас в теме
(11) Ну спорно, спорно, если честно. Длительный вызов может быть и не только по нехорошей причине ведь, например, если заложено бизнес-логикой по нажатию на кнопку сформировать стопку заказов. Длительная операция? Да. Нехорошая? Нет.
А если сюда приплюсовать кучу аналитических отчетов, то они будут висеть в топе, но нагрузка уйдет уже на СУБД, и, как правило, крупные базы имеют разделенные сервера 1С и СУБД, и там ищи ветра в поле.
Да, 8.3 сделали огромный шаг, добавив в ТЖ MemoryPeak и CPUTime, так хоть можно увидеть реальную нагрузку на сервере 1С, а не коня в вакууме, ибо на 8.2, с которой я сейчас и работаю, одними CALLами вообще не обойтись, а приходится прям комплексно исследовать. И большое время вызовов было на банальные запросы(огромный пласт логики передан в руки роботов), отчеты, особенно, если пользователю вздумалось построить выручку за все времена(с 2011, "Ачетакова?"(с)).
И вот тут уже выходит на пьедестал любой скриптовый язык(мне лично понравился питон с его возможностью утилизировать любое количество ядер, а не 4, как у баша), которым собираем вызовы, минусуем запросы, получаем хоть какую то картину, приближенную к реальности.
Ни в коем случае не критикую, просто решил внести свою лепту, вдруг, кто то имеет проблемы с производительностью на архаике, как я.
+ – Ответить
13. triviumfan 93 01.12.20 21:10 Сейчас в теме
Про что статья то?
+ – Ответить
15. buganov 200 02.12.20 10:02 Сейчас в теме
(13)Небольшая история о проблемах производительности из-за нехватки процессорных мощностей. А также описание основных показателей работы CPU.
+ – Ответить
16. ByNiko1984 02.12.20 14:24 Сейчас в теме
(15) он троль или токсик. Ему ответ не нужен был)))
BairamovTM; +1 – Ответить
17. sergvagner2018 02.12.20 15:43 Сейчас в теме
(0) С возвращением. Давно публикаций не было
+ – Ответить
18. DAAbramov 10 03.12.20 23:02 Сейчас в теме
Конкретно в этом случае поможет включение режима отладки (контекст базы будет грузится порционно и не полностью) и настройка сквозного расписания заданий
+ – Ответить
19. Дмитрий74Чел 234 23.04.21 16:12 Сейчас в теме
Проблема высокой загрузки процессора фоновыми заданиями ранее рассмотрена в статье https://infostart.ru/1c/articles/996126/
Там же есть и решение: держать активными пользовательские сеансы в базах. Я на такой случай сделал обработку https://infostart.ru/public/1075520/
+ – Ответить
Оставьте свое сообщение