Производительность сервера 1С и фоновые задания
Администрирование - Оптимизация БД (HighLoad)
производительность фоновое регламентное задание
При очередной реорганизации инфраструктуры на казалось бы ровном месте вдруг наблюдается к концу рабочего дня просто чудовищная нагрузка на сервере 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.
См. также
Специальные предложения
Вся соль в том чтобы без участия бухгалтеров данные сваливались в базу бухгалтерии.
А вот посмотреть на окончательный результат может бухгалтер и, например, раз в день.
Оперативной работы там практически мало.
Я правильно понимаю, если админ просто откроет оснастку консоли администрирования и подключиться к базе, то пока не выйдет - там всегда будет это 1 соединение и следовательно проблема должна уйти?
А вообще я часто наблюдаю следующую картину. Вечером уходишь с работы, висит, скажем, 20 rphost'ов. Утром приходишь, от силы остаются 1-2. Т.е. рабочие процессы сами завершаются, когда не остается соединений, ну и контекст тоже выгружается. И вот когда народ начинает заходить в базу утром, то может создаться десяток "мелких" (по памяти) rphost'ов, а затем соединения перекидываются на "крупняк", а этот десяток рабочих процессов завершается. Похожее происходит и при аварийном завершении одного из рабочих процессов. Соединения плодят кучу мелких рабочих процессов, а потом перекидываются на долгоживущие рабочие процессы.
Нет, консольные соединения не помогут. Нужен "честный" пользователь.
Написал обработку, которая получает список баз кластера и в цикле подключается к каждой, отключая ППД.
Стало получше. Но раз дело вообще в фоновых... пожалуй я их вообще отключу =/.
Спасибо. Проверим.
Это как с советами псевдоспецов - если растёт лог транзакций, то нужно поставить шринк в задание по обслуживанию базы. Или как с кастомными сборками винды, в которых "отключены все ненужные службы".
наблюдается как на MS SQL, так и на PostgreSQL.
Особенно если процессор относительно слаб. Старт РЗ (к примеру обновления индекса ППД) в ИБ без активного сеанса утилизирует процессор на 20-30% и длится секунд 10. в то время как то же РЗ в той же базе, но с активным сеансом отрабатывает менее чем за 1 секунду, практически не нагружая процессор.
А если на сервере пара-тройка десятков баз, которые запускают свои РЗ (ФЗ) примерно в одно и то же время, и каждая на 10 сек. жрет 20-30% процессора, а в минуте всего 6 раз по 10 секунд, то пользователям остаются только лаги интерфейса, или без плюшек, или процессор, который обеспечит комфортную работу с плюшками.
или всегда держать активный сеанс со всеми рабочими базами )
или костыли подставлять - при запуске базы спросить сервер: "есть ли уже активный сеанс к этой базе?" Если нет, то разрешить выполнение регламентных заданий на сервере для этой базы. А при закрытии проверять активные сеансы к базе. Если закрывается последний сеанс, то блокировать выполнение регламентных заданий на сервере для этой базы. Как то так ;)
или ждать решения от 1С
или...
Однако как говориться "терзают смутные сомнения".
При наличии такой, прости господи, ФИЧИ как относиться к таким новомодным штучкам встроенным в конфигурации как например APDEX, не будем бояться таких слов.
Что на самом деле может дать включение "Оценки производительности" в той же бухгалтерской базе?
Допустим включили. Заметили, документ проводится за 1 сек, через час стал проводиться за 10.
И появиться тормоза могли, оказывается только потому, что в других базах пользователи закрыли свои сессии.
Ой, что-то здесь не так.
APDEX, если его включить и посмотреть результаты, скажет, что производительность данной ИС в целом не удовлетворительна.
А тормоза появились не потому, что пользователи закрыли свои сессии, а потому, что у ИС не хватает производительности для удовлетворения пользователя )
что здесь не так? похоже на правду, но могу ошибаться.
что есть регламентное задание? некая процедура написанная на языке 1С Предприятия и размешенная в общем модуле. сервер 1С по расписанию запускает регламентное задание, а чтобы его запустить, необходимо загрузить конфигурацию ИБ и обработать указанный общий модуль препроцессором, скомпилировать в байт-код, а это все процессорное время даже без выполнения задания.
а когда существует активный сеанс к ИБ, то контекст на сервере уже подгружен, но это уже размышления на заданную тему, может оно и не так ) может и фантазирую.
И пусть оно крутится на каждой из баз.
Или нужен именно тонкий/толстый клиент? Если так, то тоже решаемо: запускать скрипт который по списку баз проверяет есть ли соединение, если их нет, то запускает тонкий клиент, пусть себе висит. На него обработчик ожидания может быть какой-нибудь повесить с легким запросиком.
Подойдет такое решение?
можно и отдельным сеансом, но, отраслевые конфигурации, к примеру, требуют отдельной лицензии на каждый сеанс, кроме того отдельный сеанс будет потреблять ресурсы сервера 100% времени, а не во время выполнения фонового задания, что удорожает стоимость владения
можно и расширениями, но расширения тоже не панацея - они не всегда дружат с новыми релизами, что требует дополнительных затрат на сопровождение.
можно и..., но....
и т.д.

Просмотры 5412
Загрузки 0
Комментарии 38
Создание 05.02.19 09:58
Обновление 05.02.19 09:58
№ Публикации 996126
Рубрики Оптимизация БД (HighLoad)
Тип файла Нет файла
Платформа Платформа 1С v8.x (все механизмы)
Конфигурация Конфигурации 1cv8
Операционная система Windows
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Раздел учета Не имеет значения
Доступ к файлу Бесплатно (free)
Код открыт Да

