Производительность сервера 1С и фоновые задания

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

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

производительность фоновое регламентное задание

52
В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

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

На рабочем сервере в Performance Monitor сняты показания счетчика %Processor Time, см. на картинке.
Интервалы 1 и 3 соответствуют времени когда в каждой базе открыта пользовательская сессия, интервал 2 — работает только фоновое задание.

Да вот и объяснение: https://partners.v8.1c.ru/forum/message/1767219

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

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

Провели небольшой эксперимент. На отдельном сервере 1С были развернуты 15 одинаковых типовых бухгалтерских баз. Никаких данных в базах нет. В каждой базе были отключены все регламентные задания за исключением одного, модуль которого заменили на пустую процедуру, это чтобы снять вопрос об оптимальности самого задания. Настроили расписание - выполнять каждые 10 секунд. Результат тот же - колоссальная нагрузка на процессор на сервере 1С в момент когда нет активных пользовательских сеансов. На сервере СУБД нагрузка практически отсутствует. Сеть не перегружена.

Похоже, можно делать выводы.

В первую очередь, что и подтолкнуло на самом деле написать эту заметку - теперь рекомендации по настройке фоновых и регламентных заданий коими полон интернет и которые обязательно услышишь от внедренцев, выглядят не совсем корректно. А именно. Часто рекомендуют отключить не нужные задания, и в первую очередь - убрать полнотекстовый поиск, кстати, очень удобная штука. Например здесь https://buhexpert8.ru/obuchenie-1s/administrirovanie-1s/1s-optimizatsiya-chto-delat-esli-programma-tormozit.html#i-2 или здесь http://fadmin.ru/vopros/pochemu-tormozit-1s-reglamentnye-zadaniya.

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

 

Задание

Расписание

Все обновления новостей

каждый день; каждые 300 секунд, завершать через 600 секунд

Все обновления 1СПАРК Риски

каждый день; каждые 3600 секунд

Все обновления 1СПАРК Риски (Область данных)

каждый день; каждые 43200 секунд

 

 

Извлечение текста файлов для поиска

каждый день; каждые 85 секунд

Обновление данных онлайн-сервисов регламентированной отчетности

каждый день; каждые 3600 секунд

Обновление задач бухгалтера

каждый день; с 2:22:00 один раз в день

Обновление индекса ППД

каждый день; с 8:00:00 каждые 60 секунд

Обновление проверок контролирующими органами

каждый день; с 0:55:15 один раз в день

Отложенное обновление ИБ

каждый день; каждые 60 секунд, повторять после завершения через 60 секунд

Отправка электронных документов

один день; один раз в день

Получение электронных документов

один день; один раз в день

Проверка контрагентов

каждый 7-й день; один раз в день

Проверка контрагентов на подключение к 1С-ЭДО

каждый 7-й день; один раз в день

Проверка кэша состояний ФНС

каждый день; с 2:25:05 один раз в день

Проверка новых электронных документов

каждый день; каждые 1800 секунд

Слияние индекса ППД

каждый день; с 1:00:00 один раз в день

Установка периода рассчитанных итогов

каждый день, 5-го числа месяца; с 1:00:00 один раз в день

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

В падении производительности сервера 1С виноваты не сами задания, они выполняют полезную работу, и должны выполнять. Но задания нельзя оставлять «наедине» с базой. В противном случае может быть плохо серверу.

У себя нашли выход с использованием дополнительной базы, выполняющей роль диспетчера. В этой базе создали регламентные задания, свое для каждой рабочей базы. Задание выполняет простую работу - проверяет имеются ли данные для загрузки, если да, по COM вызывается задание на загрузку в соответствующей рабочей базе. Теперь нагрузка на сервер 1С просто никакая, значения %Processor Time в среднем 15-20. Исчезли падения rphost-ов. Но жизнь идет. К сожалению, пришлось отказаться через некоторое время от этого решения, поскольку во время загрузки решили выполнять дополнительные расчеты в бухгалтерской базе, вызовом соответствующего кода самой базы. Но не все по COM, как оказалось, бухгалтерия позволяет сделать. Пока держим активными сеансы в базах.

Вряд ли можно согласиться с утверждением, что это просто такая особенность платформы. Уж больно неприлично выглядит деградация сервера 1С при получении сеансовых данных на фоне того с какой легкостью эти данные отдает сервер СУБД.
Хотя наверное действительно особенность, неприятная. Впрочем, как не называй, учитывать следует.

Все проверялось на такой конфигурации:

Платформа 1С:Предприятие 8.3 (8.3.12.1529).
Конфигурация Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.65.80). 
СУБД - Microsoft SQL Server Management Studio 12.0.5589.7. 

Сервер 1С и сервер СУБД на разных машинах.

Конфигурации похожи - Intel(R) Xeon(R) CPU E5-4650v2 2,4 GHz, RAM - 32 GB.

52

См. также

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

Комментарии
Избранное Подписка Сортировка: Древо
1. Dream_kz 86 05.02.19 12:05 Сейчас в теме
Еще можно включить отладку на сервере, будет происходить отложенная загрузка метаданных
2. user715208 52 05.02.19 13:10 Сейчас в теме
Это на самом деле помогает мало.
Отладка включена.
3. kwazi 299 05.02.19 13:19 Сейчас в теме
Во Фреше используется единая очередь регламентных заданий.
Может в эту сторону посмотрите?
6. user715208 52 05.02.19 13:50 Сейчас в теме
4. nyam-nyam 05.02.19 13:30 Сейчас в теме
А что Вам на это сказали в поддержке 1С?
5. user715208 52 05.02.19 13:49 Сейчас в теме
В конце ноября направили в 1С, надеясь получить рекомендации какие-нибудь для обхода проблемы.
К сожалению, ничего не получили.
7. herfis 272 05.02.19 13:55 Сейчас в теме
Интересная инфа. Спасибо.
WellMaster; AlexK_2012; +2 Ответить
8. Goleff74 145 05.02.19 15:01 Сейчас в теме
Вынести фоновые задания на отдельный сервер и пущай себе падает на здоровье.
9. webester 28 05.02.19 15:15 Сейчас в теме
Не совсем понял, где проблема. Если в базе нет никого "нет активных пользовательских сеансов", то пусть будет нагрузка и пусть падает себе на здоровье: перезапустится. Не на чью работу это не повлияет. Ну кроме того, что само задание не выполнится.
10. user715208 52 05.02.19 15:40 Сейчас в теме
Задания должны выполняться даже если в базах нет пользователей.
Вся соль в том чтобы без участия бухгалтеров данные сваливались в базу бухгалтерии.
А вот посмотреть на окончательный результат может бухгалтер и, например, раз в день.
Оперативной работы там практически мало.
11. user715208 52 05.02.19 15:45 Сейчас в теме
Да, ведь падает сервер.
Падают базы где в этот момент бухгалтера могут работать и реально работают.
Проблема видна особенно когда баз на сервере много.
Написал "много" и задумался - что такое много баз?
12. waitklassik 05.02.19 15:59 Сейчас в теме
(11)ну а если изменить запуск фоновых заданий на момент когда минимум пользователей в базах? либо раскидать утро-вечер и ночь?
13. user715208 52 05.02.19 16:35 Сейчас в теме
(12)
Разумеется настроено расписание на ночь по-другому.
В первую очередь это и было сделано.
14. maksimov.andrey 17 05.02.19 16:44 Сейчас в теме
(9)Если на сервере 1С находится 100+ информационных баз и куча пользователей, то проблемы с нагрузкой в базе где "нет активных пользовательских сеансов" - будут проблемой всех клиентов сервера 1С.
15. PerlAmutor 33 05.02.19 18:53 Сейчас в теме
Если с информационной базой нет других соединений

Я правильно понимаю, если админ просто откроет оснастку консоли администрирования и подключиться к базе, то пока не выйдет - там всегда будет это 1 соединение и следовательно проблема должна уйти?

А вообще я часто наблюдаю следующую картину. Вечером уходишь с работы, висит, скажем, 20 rphost'ов. Утром приходишь, от силы остаются 1-2. Т.е. рабочие процессы сами завершаются, когда не остается соединений, ну и контекст тоже выгружается. И вот когда народ начинает заходить в базу утром, то может создаться десяток "мелких" (по памяти) rphost'ов, а затем соединения перекидываются на "крупняк", а этот десяток рабочих процессов завершается. Похожее происходит и при аварийном завершении одного из рабочих процессов. Соединения плодят кучу мелких рабочих процессов, а потом перекидываются на долгоживущие рабочие процессы.
17. user715208 52 05.02.19 20:22 Сейчас в теме
(15)
Я правильно понимаю, если админ просто откроет оснастку консоли администрирования и подключиться к базе, то пока не выйдет - там всегда будет это 1 соединение и следовательно проблема должна уйти?


Нет, консольные соединения не помогут. Нужен "честный" пользователь.
18. triviumfan 9 05.02.19 22:34 Сейчас в теме
(15) Можете скинуть настройки кластера и сетап сервера 1с?
19. PerlAmutor 33 06.02.19 06:48 Сейчас в теме
16. triviumfan 9 05.02.19 19:22 Сейчас в теме
У клиента похожая конфигурация, сеансов немного, порядка 20, но баз 150 (БП3.0+ЗУП3.1).
Написал обработку, которая получает список баз кластера и в цикле подключается к каждой, отключая ППД.
Стало получше. Но раз дело вообще в фоновых... пожалуй я их вообще отключу =/.
Спасибо. Проверим.
20. rozer 224 06.02.19 08:37 Сейчас в теме
отключение ППД эта такой древний "боянищее" ))
21. GreenDragon 06.02.19 10:37 Сейчас в теме
(20) Только вот "баянисты" не объясняют - почему именно его нужно отключать и какие проблемы это решает.
Это как с советами псевдоспецов - если растёт лог транзакций, то нужно поставить шринк в задание по обслуживанию базы. Или как с кастомными сборками винды, в которых "отключены все ненужные службы".
22. beard1 06.02.19 11:30 Сейчас в теме
полностью подтверждаю, проверено на практике, на собственном опыте.
наблюдается как на MS SQL, так и на PostgreSQL.
Особенно если процессор относительно слаб. Старт РЗ (к примеру обновления индекса ППД) в ИБ без активного сеанса утилизирует процессор на 20-30% и длится секунд 10. в то время как то же РЗ в той же базе, но с активным сеансом отрабатывает менее чем за 1 секунду, практически не нагружая процессор.
23. triviumfan 9 06.02.19 12:14 Сейчас в теме
(22) Тоже вчера это заметил) 20-30% загрузки при выполнении регл. задания "обновление новостей" на протяжении 10 секунд. Оно сейчас самое частое - раз в час (т.к. ППД отключено).
24. beard1 06.02.19 13:31 Сейчас в теме
(23) да вроде хочется ППД, удобно пользователям, кроме поиска еще проверка 1С Отчетности, СПАРК Риски и прочие плюшки.
А если на сервере пара-тройка десятков баз, которые запускают свои РЗ (ФЗ) примерно в одно и то же время, и каждая на 10 сек. жрет 20-30% процессора, а в минуте всего 6 раз по 10 секунд, то пользователям остаются только лаги интерфейса, или без плюшек, или процессор, который обеспечит комфортную работу с плюшками.
triviumfan; +1 Ответить
27. beard1 07.02.19 11:03 Сейчас в теме
(23) если секрет, какая СУБД?
база большая?
28. triviumfan 9 07.02.19 11:25 Сейчас в теме
(27) 150 баз бп+зуп по 3-5 гигов.
25. ITconsalting 07.02.19 09:32 Сейчас в теме
Так и как бороться с этим?
26. beard1 07.02.19 10:47 Сейчас в теме
(25) Таки суперкомп нужен, дабы в миг полностью загружать контекст информационной базы ;)
или всегда держать активный сеанс со всеми рабочими базами )
или костыли подставлять - при запуске базы спросить сервер: "есть ли уже активный сеанс к этой базе?" Если нет, то разрешить выполнение регламентных заданий на сервере для этой базы. А при закрытии проверять активные сеансы к базе. Если закрывается последний сеанс, то блокировать выполнение регламентных заданий на сервере для этой базы. Как то так ;)
или ждать решения от 1С
или...
ITconsalting; +1 Ответить
29. ITconsalting 07.02.19 14:21 Сейчас в теме
(26) А в 1С писали? Проблему они признали?
30. beard1 07.02.19 16:02 Сейчас в теме
(29) в процессе на текущий момент, но не думаю, что выйдет толк.
это не баг, а фича, как говорится.
особенность реализации механизма.
вряд ли получиться быстро изменить поведение платформы.
33. ITconsalting 08.02.19 09:44 Сейчас в теме
(30) Сообщите, пожалуйста, результат общения с поддержкой 1С.
31. user715208 52 07.02.19 17:37 Сейчас в теме
Не стал в заметке развивать тему тестирования, тему оценки производительности.
Однако как говориться "терзают смутные сомнения".
При наличии такой, прости господи, ФИЧИ как относиться к таким новомодным штучкам встроенным в конфигурации как например APDEX, не будем бояться таких слов.
Что на самом деле может дать включение "Оценки производительности" в той же бухгалтерской базе?
Допустим включили. Заметили, документ проводится за 1 сек, через час стал проводиться за 10.
И появиться тормоза могли, оказывается только потому, что в других базах пользователи закрыли свои сессии.
Ой, что-то здесь не так.
32. beard1 07.02.19 18:47 Сейчас в теме
(31) так и относиться к APDEX, как к новомодным штучкам )
APDEX, если его включить и посмотреть результаты, скажет, что производительность данной ИС в целом не удовлетворительна.
А тормоза появились не потому, что пользователи закрыли свои сессии, а потому, что у ИС не хватает производительности для удовлетворения пользователя )

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

что есть регламентное задание? некая процедура написанная на языке 1С Предприятия и размешенная в общем модуле. сервер 1С по расписанию запускает регламентное задание, а чтобы его запустить, необходимо загрузить конфигурацию ИБ и обработать указанный общий модуль препроцессором, скомпилировать в байт-код, а это все процессорное время даже без выполнения задания.
а когда существует активный сеанс к ИБ, то контекст на сервере уже подгружен, но это уже размышления на заданную тему, может оно и не так ) может и фантазирую.
34. testerpro1 09.02.19 17:50 Сейчас в теме
Как вариант, если работа пользователей строго задана, скажем с 8 до 17, то можно настроить время работы трех наиболее часто запускающихся регл. заданий с 8 до 17.
35. pbabincev 104 17.02.19 04:22 Сейчас в теме
А нельзя запустить постоянно работающее регламентное (фоновое) задание? Ну задержка в цикле там или еще чего. Цель - постоянно держать соединение.
И пусть оно крутится на каждой из баз.
Или нужен именно тонкий/толстый клиент? Если так, то тоже решаемо: запускать скрипт который по списку баз проверяет есть ли соединение, если их нет, то запускает тонкий клиент, пусть себе висит. На него обработчик ожидания может быть какой-нибудь повесить с легким запросиком.
Подойдет такое решение?
36. beard1 17.02.19 08:31 Сейчас в теме
(35) можно, но изменять типовую конфигурацию крайне не желательно, если не нельзя.
37. pbabincev 104 17.02.19 11:55 Сейчас в теме
(36)
Это всё можно решить абсолютно без изменения конфигурации, например, с помощью механизма расширений
38. beard1 17.02.19 12:55 Сейчас в теме
(37) я не спорю, что можно, решить, и один из вариантов решения предлагал выше.
можно и отдельным сеансом, но, отраслевые конфигурации, к примеру, требуют отдельной лицензии на каждый сеанс, кроме того отдельный сеанс будет потреблять ресурсы сервера 100% времени, а не во время выполнения фонового задания, что удорожает стоимость владения
можно и расширениями, но расширения тоже не панацея - они не всегда дружат с новыми релизами, что требует дополнительных затрат на сопровождение.
можно и..., но....
и т.д.
Оставьте свое сообщение