Добрый день

Примерно раз в сутки, как правило с утра, при открытии формы списка документов ОткрытьФорму у всех отрабатывает от 20 до 40 секунд. Если рубануть самый большой по памяти rphost, то открытие начинает работать как положено, примерно за 2 секунды. И так будет работать целые сутки, пока на следующий день с утра опять не начнет открывать долго. Опять рубишь rphost и опять спокойно работаешь весь день.

Не могу понять в чем дело, подскажите кто сталкивался с подобным, что делать?

При этом по APDEX в этот же период в несколько раз проседает показатель "Общее время запуска приложения", т.е. обычный вход в 1с вместо 5-8 секунд, может длиться от 1 до 10 минут. Всякие проведения и записи документов практически не меняются.

Пробовал замерами через отладку смотреть, ничего такого нет, висит на ОткрытьФорму. Пробовал рубить долгий запуск 1С и смотреть ТЖ, так же нет никаких сообщений, кроме того, что сеанс убили. В чем может быть дело?

rphosts, в чём дело?

Настроить перезапуск rphost через 4 часа?
Надеюсь нет более долгих серверных вызовов

(2) это лечение симптомов
Его и так раз в сутки рубят, когда показатель падает или пользователи раньше замечают и начинают жаловаться

Хотелось бы понять в чем дело

(3) Например у кого то из юзеров на этой форме списка какие то дикие настройки с отборами
Но почему это влияет на других даже разработчики платформы сразу не ответят :)

(3) версию платформы озвучите? просто для статистики )

(3) память кончилась поди да ?

В этот момент в мониторе производительности посмотри картинку  с памятью, если она вся зарезервирована, то её считай и нет

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

(4) я бы понял, если дело было бы только в этой форме. Но время запуска в 1С так же в разы увеличивается. Да и другие формы не быстро открываются, но с ними меньше работают

(5) тут все печально, 8.3.12. Но проблема началась пару месяцев назад, до этого работало нормально

(6) как сказать. В этот момент памяти на сервере остается еще 40% - 50%. rphost съедает от 25 до 35Гб в это время. Но он и после перезапуска может съедать столько же или больше, но таких проблем нет. Места на диске полно. В целом все основные показатели оборудования по perfmon в норме

(9) ще 40% - 50% это тебе только так кажется, смотри монитор производительности
Ну и в 8.3.12, скорее всего, только перезапуском рпхост это лечится

(8) Памяти свободной много, как правило даже половину не забирает. По поводу долгого регламента тоже думал, мониторил сутками серверные вызовы CALL - ничего такого длительного нет. В течении дня больше нагрузки может быть.
Есть ночное обновление индексов полнотекстного поиска, он заканчивается ночью, за пару часов до того, как начинают все работать.

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

(11) чего проще то, обнови платформу, там есть уже в настройках кластера и количество памяти на безопасный вызов и всякие перезагрузки и прочее.

(12) В 8.3.12 еще не было настройки "Интервал перезапуска"?

(11) Зачем "полностью перезапускать службу 1С", речь о настройке несколько rphost и каждый будет перезапускаться по очереди

(12) быстро перейти на новую платформу не получается, большая база, много пользователей
(13) есть там все эти настройки, даже возможности КОРП с лицензией ПРОФ. Но это уже как крайний вариант

(0) "Интервал перезапуска" в свойствах "Локального кластера" стоит? Ну вот сеансовые данные и очищаются.

(13) что я вам, все константы помнить должен ? :)
Может и были, перезапуск, точно должен быть рабочих процессов

У меня был случай что копия базы БП из бэкапа прода не открывалась форма списка документов (чаще всего реализаций)
Совсем не открывалась - висла намертво под моим пользователем
Под другими пользователями (без настроек отбора сохраненных) открывалась

Оказалось странное - при бэкапе (PgSQL) часть данных нетути (фактически происходил разрыв связанных записей таблиц документов и справочников)
В итоге запрос ДС глючил с много условий

(15) Интервал перезапуска не стоит. Батником перезапускаю службу ночью, раз в сутки. Но такая настройка работает лет 5-6. А проблема с долгим запуском началась пару месяцев назад

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

(17)+ Можно было снять новый бэкап - и все с большой вероятностью будет ок
Фактически каждую ночь с базы прода средствам скуля сливался бэкап и автоматом восстанавливался в отдельную тест базу

(18) нафига?!

Щас еще выяснится, что журнал логов в скульлайте у товарища

(18) Ну так поставь Интервал перезапуска и сами rphost будут грохаться и заново запускаться
Передавая активных клиентов другому активному rphost
Понятно дело в этот момент долгим серверным вызовам не повезло если они на этом rphost, который рубится сам

(22)+ На одном сервере где на 100 юзеров было маловато оперативки пришлось Интервал перезапуска поставить 2 часа
Да было неудобно, что даже удаление помеченных с большой вероятностью падало ))
Но зато всю оперативку не сжирало

может тупо реусрсы выжираются на сервере? Блокировки, там, появляются

(20) Стандартный перезапуск службы 1с, чтобы рубануть все зависшие сеанты и соединения, если такие появятся

(21) старый формат ЖР

(22) Интервал перезапуска полечит симптомы, но не поможет найти причину зависаний

(24) Как понять каких ресурсов не хватает?
По счетчикам смотрю:
- Процессор(_Total)\% загруженности процессора (привил. и польз.режим)
- Система\Длина очереди процессора
- Transactions\Время выполнения самой длинной транзакции
- Locks(_Total)\Превышений времени ожидания блокировки в секунду
- Locks(_Total)\Среднее время ожидания (мс)
- Память\Доступно МБ
- Процесс(rphost)\Байт виртуальной памяти
- Отдельные счетчики на диск, запись, чтение, очереди т д.
- и другие счетчики оборудования и скуля

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

Вполне может оказаться, что какой-то счетчик важный я пропустил и зависимость от него не вижу

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

(26) вот тоже к этому склоняюсь, но не могу понять как диагностировать. Пробовал анализировать серверные вызовы CALL - нет ничего особенного. Все теже процессы, что днем работают. Каких то анамальных скачков Memory или MemoryPek нет. СУБД при этом нормально работает, т.е. дело только в сервере приложений

(27) показал бы что ле веселые картинки: монитор производительности по памяти, настройки кластера 1с..

Смысл в картинках?

Имхо проблема явно в "утро"
Утром заходит почти в одно время толпа юзеров в 1С, одновременно жмякает "открыть форму списка"
А они у них с кучей настроек/отборов
И привет...блокировочки родные

Отключить по утрам (пока пик захода юзеров) все регламентные, которые пишут в базу

(29) не обязательно, возможно например ночью идет очистка серверного (программного) кеша, и утром при старте он пытается заново его создать и в процессе что-то происходит.

(31) Вероятность что происходят блокировки для всех на чтение табличек (в которые в этот момент нечто пишут) намного выше

(32)+ Возможно ночью/утром некая автоматическая загрузка и создание документов происходит?

Или есть 1С:ЭДО включенный с регламентным?
И там статусы подтягиваются в форму списка документов

(0) замер производительности при открытии, уже пробывал смотреть?

такое ощущение, что все на 386-ых работают, ну максимум на 486DX75... А что может на неслабых таких компах с миллионами операций в секунду тормозить?

(18) Ищите что доработали с того месяца когда началась проблема.

дурдом закрываю