8.3.22.1709 Тормоза фоновых заданий
Добрый день. После всех известных событий 15.11.2022, пришлось спешно обновлять платформу, до этого стояла 8.3.21.1508. После обновления, посыпались сначала сообщение от бухгалтеров о том, что ооочееень долго формируется ОСВ в Бухгалтерии 3.0.124.18 (а сервер у нас не слабый 160Gb ОЗУ, 2*XEON E5-2670 и RAID 10 на SAS + LDF на отдельном физическом серверном SSD на PCI Express), затем начал замечать что рег. задания обмена РИБ (конф. РОЗНИЦА) висит, методом наблюдений выяснил, что зависает оно, когда после очередного запуска не успело отработать и запускается снова по расписанию и в этот момент зависает, соответственно обмены не работают, т.е. странное поведение. Решил сначала поразбираться с ОСВ в бух 3. начитался всякого конечно я здесь, ну конечно и перепробовал всё, начиная от настройки СУБД, профилями питания сервера, заканчивая всякими танцами с бубнами и правками регистра бухгалтерии, свойства "Длина уточнения периода" =0 + все запросы (, что не привело ни к камим улучшением/ухудшением ситуации. Решил всё-таки копаться в сторону фоновых заданий, взял в отчете "ОборотноСальваяВедомость" в модуле формы в процедуре "Сформировать отчет на сервере()" уведел такой код:
т.е. если база серверная, то запускаем фоновое задание и ждем его выполнения, так вот в таком варианте отчет формируется (период один месяц) за 1 минуту 8 секунд, сразу вспомнил зависшие задания в рознице (т.к. не успевали отрабатывать) изменил код на:
т.е. фактически то же формирование, только не в фоне, результат 1-2 секунды!!!!
Далее пробовал на данные момент платформу 8.3.21.1624, думал может дело именно в 22, но ситуация аналогичная. Повторюсь, на платформе 8.3.21.1508 таких проблем не было, всё отлично работало до 15.11.2022
У кого какие мысли по этому поводу? Куда копать?
Если ОбщегоНазначения.ИнформационнаяБазаФайловая() Тогда
АдресХранилища = ПоместитьВоВременноеХранилище(Неопределено, УникальныйИдентификатор);
БухгалтерскиеОтчетыВызовСервера.СформироватьОтчет(ПараметрыОтчета, АдресХранилища);
Иначе
РезультатВыполнения = ДлительныеОперации.ЗапуститьВыполнениеВФоне(
УникальныйИдентификатор,
"БухгалтерскиеОтчетыВызовСервера.СформироватьОтчет",
ПараметрыОтчета,
БухгалтерскиеОтчетыКлиентСервер.ПолучитьНаименованиеЗаданияВыполненияОтчета(ЭтаФорма));
АдресХранилища = РезультатВыполнения.АдресХранилища;
ИдентификаторЗадания = РезультатВыполнения.ИдентификаторЗадания;
КонецЕсли;
Показатьт.е. если база серверная, то запускаем фоновое задание и ждем его выполнения, так вот в таком варианте отчет формируется (период один месяц) за 1 минуту 8 секунд, сразу вспомнил зависшие задания в рознице (т.к. не успевали отрабатывать) изменил код на:
АдресХранилища = ПоместитьВоВременноеХранилище(Неопределено, УникальныйИдентификатор);
БухгалтерскиеОтчетыВызовСервера.СформироватьОтчет(ПараметрыОтчета, АдресХранилища);
т.е. фактически то же формирование, только не в фоне, результат 1-2 секунды!!!!
Далее пробовал на данные момент платформу 8.3.21.1624, думал может дело именно в 22, но ситуация аналогичная. Повторюсь, на платформе 8.3.21.1508 таких проблем не было, всё отлично работало до 15.11.2022
У кого какие мысли по этому поводу? Куда копать?
Ответы
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
В клиент-серверном варианте для выполнения фоновых заданий используется планировщик заданий, который физически находится в менеджере кластера. Планировщик получает наименее загруженный рабочий процесс для всех поставленных в очередь на выполнение фоновых заданий и использует его для выполнения соответствующего фонового задания. Рабочий процесс выполняет задание и уведомляет планировщик о результатах выполнения.
Поробуй разделить розницу и бухгалтерию на разные кластера. Что-то у тебя не так с менеджером кластера.Проверь загрузку rmngr.exe.
(2) rmngr.exe процессор не нагружен, памяти отъедает 500Mb. сложно оценить много это или мало на 5 ИБ 2 из которых достаточно нагружены. Включил настройку "менеджер под каждый сервис" Основной менеджер стал потреблять около 600 Mb, остальные по 70-80Mb и только 2 перевалили за 110MB это Менеджер заданий и менеджер журнала регистрации, но не думаю, что это большое потребление
Разобрался, может кому пригодится. При включении настройки "менеджер под каждый сервис", (это настройка как раз для целей поиска проблем), каждый сервис стал писать лог, так вот JobService (сервис заданий) писал различные ошибки при этом в каждой строке лога указывал идентификатор базы DBName=NULL. У меня каталог 1С сервера находится не по стандартному пути и существует уже с 2016 года, и конечно за это время удалялись и добавлялись ИБ и не в малом количестве, т.к. были различные внедрения и т.п. + копии баз и т.д. В итоге пошёл по самому простому пути:
1. из каталога сервера 1С у нужных ИБ сохранил журналы транзакций;
2. остановил службу сервера 1С;
3. удалил каталог сервера 1С "srvinfo";
4. запустил службу сервера 1С;
5. подключил нужные базы.
Как итог ОСВ формируется за 1-2 секунды )))
П.С. видимо сервис заданий пытался запустить какие фоновые задания для несуществующей ИБ, которую сервер 1С где то там разглядел, соответственно задержка на запуск реальных фоновых заданий была больше минуты
П.С.С. на потребление (утечку) памяти процесса rmngr.exe никак не влияло
1. из каталога сервера 1С у нужных ИБ сохранил журналы транзакций;
2. остановил службу сервера 1С;
3. удалил каталог сервера 1С "srvinfo";
4. запустил службу сервера 1С;
5. подключил нужные базы.
Как итог ОСВ формируется за 1-2 секунды )))
П.С. видимо сервис заданий пытался запустить какие фоновые задания для несуществующей ИБ, которую сервер 1С где то там разглядел, соответственно задержка на запуск реальных фоновых заданий была больше минуты
П.С.С. на потребление (утечку) памяти процесса rmngr.exe никак не влияло
Разделение на два кластера тоже не помогло(( только усугубило, теперь основной кластер потребляет 1000 Mb ОЗУ, а дополнительный (где базы без рег. заданий) 100 Mb. Видимо придёться включать ТЖ на поиск утечки памяти
Добрый день, поставили платформу 8.3.22.1709 на сервер и на локалки, через какое-то время получаем тормоза, во всех базах, несколько зависших фоновых заданий, нагрузку на процессор. Фоновых заданий много, работают долго. Пару дней мучались, искали причину, в итоге понизили платформу до 8.3.20.2184. Все прошло, скорость вернулась в норму, фоновые задания отрабатывают быстро.
Анализ техножурнала показал длительное начало фоновых заданий без всяких на то причин, просто долго начинается (около 60 секунд) события SESN и CONN. Причём, часто повторяющиеся задания (например обновление индекса ПП), со временем зависают, т.к. не успевают отрабатывать и по новой запускаются, и зависают так, что их не сбросить никак, даже через консоль администрирования сервера, помогает, только рестарт агента сервера. попробую откатиться до 8.3.20.2184
Прикрепленные файлы:
(15) за 10 лет работы писал в поддержку раз 30, решений 0. Хорошо и быстро решают, только вопросы лицензирования. Так, что я знаю о чём пишу, все данные есть в этой теме, кто хочет, может потратить своё время. И вообще считаю, что такие темы и форумы должны быть со стороны 1С и они должны делать выводы, а не оставлять только партнерский форум, к которому у простых смертных нет доступа, вот мы простые смертные набираемся опыта между собой на этой замечательной площадке.
(16) ИМХО если не направлять им информацию, то ничего меняться и не будет. Как в свое время говорил представитель разработчика - "ой какой интересный случай". Вы сделали большую выборку - не думаю что на такую выборку имеет 1С - ну и потратьте свое время отправьте эти данные в 1С. Свое может и не решите оперативно, но на будущее задел сделаете... Иначе когда будете опять обновлять платформу - опять на те же грабли наткнетесь...
(17)
Я, в своё время, ошибки платформы активно репортил. Пока эти доблестные гаврики не начали требовать прислать видео как именно разваливается платформа в специально приложенной демобазе с ровно одной демо кнопкой...
Так что ну их. Больше косяков - больше лучей поноса в 1С, может шевелится начнут. А обойти ошибки квалификации хватает.
ну и потратьте свое время отправьте эти данные в 1С
И стукнетесь о первую линию поддержки с их дебильными ответами, очень скоро вам это надоест.
Я, в своё время, ошибки платформы активно репортил. Пока эти доблестные гаврики не начали требовать прислать видео как именно разваливается платформа в специально приложенной демобазе с ровно одной демо кнопкой...
Так что ну их. Больше косяков - больше лучей поноса в 1С, может шевелится начнут. А обойти ошибки квалификации хватает.
Не только во времени же дело, вот в (18) правильно описали, что начнут, пришлите это, пришлите то, сделайте лог, теряется время на ерунду, а это действующий бизнес 24/7 и такие эксперименты рынок не прощает. А что в итоге? в Итоге будет отписка, что эта такая особенность поведения платформы и к ошибкам никак не относится. В самом лучшем случае втихаря исправят, но как говорится "вы тут ни причем" ))))
(22) Это прекрасно, что есть люди, которые имеют возможность постоянно писать в 1С и поддерживать с ними диалог, а тем более есть время на поиск проблем и способы их решения с платформой, я же пишу про то, что времени у меня на это нет, т.к. знаю, что 1С попросит те или иные данные (для воспроизведения ошибки), которые я уже не смогу предоставить т.к. не пользую проблемную платформу в связи с тем, что бизнес не может ждать и, как следствие, 1С теряет к этому вопросу интерес. И вообще, почему то тема превращается в ЗА и ПРОТИВ писанины в техподдержку 1С, предлагаю тем, кому это интересно, вывести в отдельный топик и запустить голосование, а не разводить дебаты не по теме. Т.к. тему я создавал именно для того, чтобы поделиться опытом друг с другом по данной проблеме, чтобы те кто не ставил последние 21 и 22 платформу не наступили на грабли, а кто поставил, увидел, что есть проблема и принял правильное для себя решение.
П.С. И кстати, я его (Старых Сергей Александрович (Tormozit, tormozit@mail.ru)) инструментами и пользовался, при анализе техножурнала. Спасибо Сергею за отличные инструменты разработчика.
П.С.С. Интересно бы было его мнение по по данной теме :)) Всем, добра.
П.С. И кстати, я его (Старых Сергей Александрович (Tormozit, tormozit@mail.ru)) инструментами и пользовался, при анализе техножурнала. Спасибо Сергею за отличные инструменты разработчика.
П.С.С. Интересно бы было его мнение по по данной теме :)) Всем, добра.
Поимел у клиента аналогичную проблему (клиент-сервер, платформа 8.3.22.1709, раньше была 8.3.17.1989). Такого же детального анализа, как автор ветки, правда, не делал, но с виду все то же самое: долгий вход в систему, долгое формирование отчетов, много фоновых заданий, висящих подолгу, если не бесконечно.
Пробовал отключать фоновые задания - не помогло, чистил серверный кэш (удалял папку "srvinfo\reg_1541\snccntx*") - помогло только для старенькой БГУ1.0, в ЗГУ и БП эффект если и был, то ненадолго, понижал версию платформы до 8.3.20.2184 - тоже не помогло!
В результате пока что вернулся на старую версию платформы. Ищу ответы.
Если кто в курсе, что происходит и как это победить, пишите!
Пробовал отключать фоновые задания - не помогло, чистил серверный кэш (удалял папку "srvinfo\reg_1541\snccntx*") - помогло только для старенькой БГУ1.0, в ЗГУ и БП эффект если и был, то ненадолго, понижал версию платформы до 8.3.20.2184 - тоже не помогло!
В результате пока что вернулся на старую версию платформы. Ищу ответы.
Если кто в курсе, что происходит и как это победить, пишите!
(19)Добрый день. Проблема не в платформе. Версия конфигурации немного глюкнутая. Я с 8.3.22.1709 откатилась до 8.3.20.2184. Вернула старую конфигурацию до изменений и начала поэтапно обновлять конфигурации. На своем примере я нашла причину долгих зависаний в том, что перепрыгнула версию с 121 на 123 , минуя 122. Когда сделала поэтапно каждую версию, то обновление всех промежуточных конфигураций заняло не более 20 минут, и отчеты все формирует достаточно быстро и уже неделю все работает как часы.
Такая же беда. После платформы 8.3.20.1674 установила 8.3.22.1750. По минуте минимум открывались типовые документы, элементы справочников, долго формировались отчеты, запись и проведение вообще по минуты 2 проходило. Единственное фоновое задание было под вопросом " Регламентное задание. Отправка серверных оповещений клиентам", но оно есть уже давно, его отключение не меняло состояния работы, те же тормоза. Также у нас каждые 2 мин проходит синхронизация, но они тоже были всегда, отключать их или изменять таймаут - бред. Итогом: снесла и установила платформу 8.3.20.2184 и все нормализовалось, задержки в рамках обычной работы. Что за платформа 8.3.22, что в ней намудрили 1С-ники - на их совести. Франчайзеру нашему отправлю видео о работе. Посмотрим, может 1С отреагирует. А может уберут 8.3.22. ведь уже 8.3.23 готовят к выходу.
Сейчас поверила работу платформы на серверах, где развернуты наши рибы. Там все просто летает, там одна база на кластер. На центральном сервере развернуто у нас помимо рабочих двух баз еще копий штуки 3 и старые базы висят на всякий случай, в общей сложности 10 баз. На платформе 8.3.20.2184 хоть и меньше, но все равно тормозы по минуте-две при открытии и проведении документов и элементов справочников. Вот так. Похоже, чем меньше баз в кластере, тем быстрее работа... Бред вроде, но..
(28)
Итог у меня: дело было не в списке количестве баз или самой версии платформы, а в том, что у нас на виртуальном сервере есть выделенный сервер лицензирования, про который я постоянно забываю... надо же и на нем новую версию платформы устанавливать, причем точно такую же, как и на основном сервере. Если этого не сделать, то каждую минуту происходит опрос лицензий с подключенного сервера лицензирования в кластере, а к нему доступа нет, платформа новая не видит "старую". То же самое бывает, когда и просто нет интернета - доступ к вирт.серверу закрыт, и база начинает тормозить жутко. После установки такой же платформы с такой же разрядностью, все заработало на !ура!.
Итог у меня: дело было не в списке количестве баз или самой версии платформы, а в том, что у нас на виртуальном сервере есть выделенный сервер лицензирования, про который я постоянно забываю... надо же и на нем новую версию платформы устанавливать, причем точно такую же, как и на основном сервере. Если этого не сделать, то каждую минуту происходит опрос лицензий с подключенного сервера лицензирования в кластере, а к нему доступа нет, платформа новая не видит "старую". То же самое бывает, когда и просто нет интернета - доступ к вирт.серверу закрыт, и база начинает тормозить жутко. После установки такой же платформы с такой же разрядностью, все заработало на !ура!.
Столкнулся с тормозами с первым открытием форм, проведением и прочим... Кажется, помог * на 20ю с очисткой кэша... Это на моей локальной машине. А на сервере тоже тормозит. Причем, кажется, что это будто в какой-то день произошло...
Up-ну тему. Началось внезапно с 2-мя базами. Тоже промучился несколько часов, в порядке бреда в поисковике набрал "серверные оповещения и синхронизация зависает 1С" и наткнулся на эту ветку! У клиента базовая 1С Бухгалтерия, для фирмы добавилась ЗУП, все работало и на 8.3.22-х релизах, но стоило включить синхронизацию между Бух и новой ЗУП и началось "замерзание" базы, просто ничего не нажимается. При этом в конфигураторе смотрю, что пишутся события, что запускается регламентное задание "серверные оповещения". Выключил их, выключал синхронизацию - уже ничего не помогает. Причем именно с этими базами, просто виснут эти 2 базы. Другие базы без синхронизации работают норм. Как будто триггер какой-то сработал.
Решение такое же как написали выше - поставить 8.3.20.2184
Решение такое же как написали выше - поставить 8.3.20.2184
(30) Другие базы тоже будут виснуть, если будут фоновые задания с периодичностью запуска меньше, чем требуется на выполнение самого фонового задания, т.к. сам запуск его очень долгий и происходит повторный запуск фонового задания (например: "Отправка серверных оповещений клиентам", "Обновление ППП" и тому подобные).
П.С. такое ощущение, что повторный запуск происходит без проверки на то, что задание уже выполняется.
П.С. такое ощущение, что повторный запуск происходит без проверки на то, что задание уже выполняется.
После установки платформы 8.3.22.1709 появись тормоза при запуске фоновых заданий, например в отчетах, после обновления до 8.3.22.1750 ситуация не изменилась. Выполнение рег. операций 1с и SQL не помогло. При этом запрос без фонового задания выполняется быстро. Так же долгий вход в 1с до появления пользователя и после.
В моем случае проблема решилась корректировкой файла nethasp.ini на сервере 1с, отключил NH_USE_BROADCAST и установил NH_SERVER_NAME.
В моем случае проблема решилась корректировкой файла nethasp.ini на сервере 1с, отключил NH_USE_BROADCAST и установил NH_SERVER_NAME.
(39) гласят, что NH_USE_BROADCAST должен быть выключен и по умолчанию он выключен. Честно говоря во время проблемы у меня nethasp.ini был с настройками по умолчанию, т.к. у меня программные лицензии выдаёт сервер, но возможно проблема именно в этом нужно пробовать, но у меня сейчас 8.3.20.2290 полёт отличный, менять на другую платформу смысла не вижу, а так интересное наблюдение
(40)
А придется, причем довольно скоро.
менять на другую платформу смысла не вижу
А придется, причем довольно скоро.
Информация о планируемом релизе
Номер версии 3.0.142
Ориентировочная дата выхода Август 2023
Дата обновления плановых данных 06.04.23
Адаптация конфигурации к работе на платформе 8.3.22 в режиме совместимости только с 8.3.21
Номер версии 3.0.142
Ориентировочная дата выхода Август 2023
Дата обновления плановых данных 06.04.23
Адаптация конфигурации к работе на платформе 8.3.22 в режиме совместимости только с 8.3.21