При очередной реорганизации инфраструктуры на казалось бы ровном месте вдруг наблюдается к концу рабочего дня просто чудовищная нагрузка на сервере 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.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Еще можно включить отладку на сервере, будет происходить отложенная загрузка метаданных
Это на самом деле помогает мало.
Отладка включена.
Во Фреше используется единая очередь регламентных заданий.
Может в эту сторону посмотрите?
А что Вам на это сказали в поддержке 1С?
В конце ноября направили в 1С, надеясь получить рекомендации какие-нибудь для обхода проблемы.
К сожалению, ничего не получили.
Спасибо, посмотрим.
Интересная инфа. Спасибо.
Вынести фоновые задания на отдельный сервер и пущай себе падает на здоровье.
Не совсем понял, где проблема. Если в базе нет никого «нет активных пользовательских сеансов», то пусть будет нагрузка и пусть падает себе на здоровье: перезапустится. Не на чью работу это не повлияет. Ну кроме того, что само задание не выполнится.
Задания должны выполняться даже если в базах нет пользователей.
Вся соль в том чтобы без участия бухгалтеров данные сваливались в базу бухгалтерии.
А вот посмотреть на окончательный результат может бухгалтер и, например, раз в день.
Оперативной работы там практически мало.
Да, ведь падает сервер.
Падают базы где в этот момент бухгалтера могут работать и реально работают.
Проблема видна особенно когда баз на сервере много.
Написал «много» и задумался — что такое много баз?
(11)ну а если изменить запуск фоновых заданий на момент когда минимум пользователей в базах? либо раскидать утро-вечер и ночь?
(12)
Разумеется настроено расписание на ночь по-другому.
В первую очередь это и было сделано.
(9)Если на сервере 1С находится 100+ информационных баз и куча пользователей, то проблемы с нагрузкой в базе где «нет активных пользовательских сеансов» — будут проблемой всех клиентов сервера 1С.
Я правильно понимаю, если админ просто откроет оснастку консоли администрирования и подключиться к базе, то пока не выйдет — там всегда будет это 1 соединение и следовательно проблема должна уйти?
А вообще я часто наблюдаю следующую картину. Вечером уходишь с работы, висит, скажем, 20 rphost’ов. Утром приходишь, от силы остаются 1-2. Т.е. рабочие процессы сами завершаются, когда не остается соединений, ну и контекст тоже выгружается. И вот когда народ начинает заходить в базу утром, то может создаться десяток «мелких» (по памяти) rphost’ов, а затем соединения перекидываются на «крупняк», а этот десяток рабочих процессов завершается. Похожее происходит и при аварийном завершении одного из рабочих процессов. Соединения плодят кучу мелких рабочих процессов, а потом перекидываются на долгоживущие рабочие процессы.
У клиента похожая конфигурация, сеансов немного, порядка 20, но баз 150 (БП3.0+ЗУП3.1).
Написал обработку, которая получает список баз кластера и в цикле подключается к каждой, отключая ППД.
Стало получше. Но раз дело вообще в фоновых… пожалуй я их вообще отключу =/.
Спасибо. Проверим.
(15)
Нет, консольные соединения не помогут. Нужен «честный» пользователь.
(15) Можете скинуть настройки кластера и сетап сервера 1с?
(18) Вам для чего?
отключение ППД эта такой древний «боянищее» ))
(20) Только вот «баянисты» не объясняют — почему именно его нужно отключать и какие проблемы это решает.
Это как с советами псевдоспецов — если растёт лог транзакций, то нужно поставить шринк в задание по обслуживанию базы. Или как с кастомными сборками винды, в которых «отключены все ненужные службы».
полностью подтверждаю, проверено на практике, на собственном опыте.
наблюдается как на MS SQL, так и на PostgreSQL.
Особенно если процессор относительно слаб. Старт РЗ (к примеру обновления индекса ППД) в ИБ без активного сеанса утилизирует процессор на 20-30% и длится секунд 10. в то время как то же РЗ в той же базе, но с активным сеансом отрабатывает менее чем за 1 секунду, практически не нагружая процессор.
(22) Тоже вчера это заметил) 20-30% загрузки при выполнении регл. задания «обновление новостей» на протяжении 10 секунд. Оно сейчас самое частое — раз в час (т.к. ППД отключено).
(23) да вроде хочется ППД, удобно пользователям, кроме поиска еще проверка 1С Отчетности, СПАРК Риски и прочие плюшки.
А если на сервере пара-тройка десятков баз, которые запускают свои РЗ (ФЗ) примерно в одно и то же время, и каждая на 10 сек. жрет 20-30% процессора, а в минуте всего 6 раз по 10 секунд, то пользователям остаются только лаги интерфейса, или без плюшек, или процессор, который обеспечит комфортную работу с плюшками.
Так и как бороться с этим?
(25) Таки суперкомп нужен, дабы в миг полностью загружать контекст информационной базы 😉
или всегда держать активный сеанс со всеми рабочими базами )
или костыли подставлять — при запуске базы спросить сервер: «есть ли уже активный сеанс к этой базе?» Если нет, то разрешить выполнение регламентных заданий на сервере для этой базы. А при закрытии проверять активные сеансы к базе. Если закрывается последний сеанс, то блокировать выполнение регламентных заданий на сервере для этой базы. Как то так 😉
или ждать решения от 1С
или…
(23) если секрет, какая СУБД?
база большая?
(27) 150 баз бп+зуп по 3-5 гигов.
(26) А в 1С писали? Проблему они признали?
(29) в процессе на текущий момент, но не думаю, что выйдет толк.
это не баг, а фича, как говорится.
особенность реализации механизма.
вряд ли получиться быстро изменить поведение платформы.
Не стал в заметке развивать тему тестирования, тему оценки производительности.
Однако как говориться «терзают смутные сомнения».
При наличии такой, прости господи, ФИЧИ как относиться к таким новомодным штучкам встроенным в конфигурации как например APDEX, не будем бояться таких слов.
Что на самом деле может дать включение «Оценки производительности» в той же бухгалтерской базе?
Допустим включили. Заметили, документ проводится за 1 сек, через час стал проводиться за 10.
И появиться тормоза могли, оказывается только потому, что в других базах пользователи закрыли свои сессии.
Ой, что-то здесь не так.
(31) так и относиться к APDEX, как к новомодным штучкам )
APDEX, если его включить и посмотреть результаты, скажет, что производительность данной ИС в целом не удовлетворительна.
А тормоза появились не потому, что пользователи закрыли свои сессии, а потому, что у ИС не хватает производительности для удовлетворения пользователя )
что здесь не так? похоже на правду, но могу ошибаться.
что есть регламентное задание? некая процедура написанная на языке 1С Предприятия и размешенная в общем модуле. сервер 1С по расписанию запускает регламентное задание, а чтобы его запустить, необходимо загрузить конфигурацию ИБ и обработать указанный общий модуль препроцессором, скомпилировать в байт-код, а это все процессорное время даже без выполнения задания.
а когда существует активный сеанс к ИБ, то контекст на сервере уже подгружен, но это уже размышления на заданную тему, может оно и не так ) может и фантазирую.
(30) Сообщите, пожалуйста, результат общения с поддержкой 1С.
Как вариант, если работа пользователей строго задана, скажем с 8 до 17, то можно настроить время работы трех наиболее часто запускающихся регл. заданий с 8 до 17.
А нельзя запустить постоянно работающее регламентное (фоновое) задание? Ну задержка в цикле там или еще чего. Цель — постоянно держать соединение.
И пусть оно крутится на каждой из баз.
Или нужен именно тонкий/толстый клиент? Если так, то тоже решаемо: запускать скрипт который по списку баз проверяет есть ли соединение, если их нет, то запускает тонкий клиент, пусть себе висит. На него обработчик ожидания может быть какой-нибудь повесить с легким запросиком.
Подойдет такое решение?
(35) можно, но изменять типовую конфигурацию крайне не желательно, если не нельзя.
(36)
Это всё можно решить абсолютно без изменения конфигурации, например, с помощью механизма расширений
(37) я не спорю, что можно, решить, и один из вариантов решения предлагал выше.
можно и отдельным сеансом, но, отраслевые конфигурации, к примеру, требуют отдельной лицензии на каждый сеанс, кроме того отдельный сеанс будет потреблять ресурсы сервера 100% времени, а не во время выполнения фонового задания, что удорожает стоимость владения
можно и расширениями, но расширения тоже не панацея — они не всегда дружат с новыми релизами, что требует дополнительных затрат на сопровождение.
можно и…, но….
и т.д.