Виснет 1C каждый день в +- 14.00 и до момента пока не позакрываю все сеансы насильно и не перезагружаю комп.
Платформа 8.3.14.1565
На пк 16Гб оперативы, проц i7-8700, тест Гилева показывает, что рекомендуемое число пользователей 77, у меня максимум 9 человек пользуются 1с. 3 базы. Из них активно используется лишь одна база - 1C-Документооборот (2.1.11.10).
Юзеры по RDP, но когда виснет - виснет и при нахождении на локальном серваке. Соответственно тормоза скорости в сети отметаем.
sql и rphost едят много памяти (около +-3000 мб на sql и около+-2000мб на rphost)
Эксперименты с количеством устанавливаемой памяти под rphost и sql пока плодов особо не приносят..
Читая рекомендации по оптимизации 1с - часть ненужных регламентных в базе либо отключила, либо уменьшала частоту выполнения.
Появляется в сеансах много фоновых DefUser, которые не сказать что много едят, но когда их отключаешь - серверу становится легче и пока эти DefUser снова не появятся - ничего не виснет.
Может есть какие идеи, предложения? Как побороть эти лаги. Юзеры грустят :(
https://yadi.sk/i/ziSrHpbdg4HSfQ
(2) В типовых есть обработка "регламентные задания", нажмите "еще - показать все". На 2й вкладке смотрим "фоновые задания" ждем 14:00 - видим кто именно выполняется.
Или даже проще - смотрим по ЖР кто выполнялся в 14:00.
Еще вариант - раз у вас sql - обслуживание индексов или что-то такое в sql.
2.
user633533_encantado
1113.02.20 09:44 Сейчас в теме
DefUser - запускается какое-то фоновое задание, об этом же говорит и четкое время появления проблемы. Нужно вычислить что за регламентное задание его создает и уже там разбираться с проблемой.
(2) Тоже так предполагаю, что какое-то фоновое. Но в самой 1с прошлась по списку выполняемых регламентных/фоновых задач - все либо в ночное время ставила, либо те, которые в течении дня, но там бы и с утра оно висело бы, а не только после обеда...Из списка нет ни одного задания, которое начинает выполняться именно в это время. А по списку фоновых задач - все выполняются очень быстро и систему грузить не должны.
К тому же многие выполняются через юзера админ, а тут defuser, который ещё и размножается в сеансах..
(6)читала, но там решения проблемы так и нет. Регламентные все убрать нет возможности так как процессы обновляться не будут. А по тем, что отображаются в списке регламентных - видно, что тормоза не они прибавляют. Но и памяти на серваке достаточно как по мне. Иначе результаты теста гилева были бы намного хуже...хмм.
Да и меня пугает периодичность появления. Почему именно в определенное время. Даже если юзеров нет и сеанс ни у кого не открыт.
Зато копия базы, тестовая, без этих левых сеансов...хмм
(7) попробуйте отключить все таки регламентные задания в включать их по одному в разное время. Возможно пересечение двух трех регламентных заданий дает такой результат.
Если при установке 1с задания сразу не отключили и не подключали по мере необходимости - обычно тормозит.
Это так работает документооборот, встроенный в бухгалтерию?
(2) В типовых есть обработка "регламентные задания", нажмите "еще - показать все". На 2й вкладке смотрим "фоновые задания" ждем 14:00 - видим кто именно выполняется.
Или даже проще - смотрим по ЖР кто выполнялся в 14:00.
Еще вариант - раз у вас sql - обслуживание индексов или что-то такое в sql.
(10) Вот скорее всего в индексах что-то будет на самом sql...Буду тестировать..Вроде как и тормозить начинает, когда начинают либо поиском пользоваться, либо таблицы открывать часто..Но почему это происходит в +- одно и тоже время - для меня пока загадка...
(13) Не совсем понятно. Если "дефрагментация с реиндексацией помогла" - значит, БД была не обслужена и, наверное, какое-то регламентное в ИБ тормозило? Какое?
да в том то и дело, что не регламентное. я их уже полностью пробовала отключать, а им пофиг. Оно именно на таблицах висеть начинало. Я конечно может не до конца понимаю как оно устроено, но по моей логике дело было так. Только мы пытаемся открывать сложные таблицы - как начинаются запросы идти к базе, в связи с большими объемами информации и сложными запросами - поиск по колонкам, которые у обычных смертных используется не так часто - плохо оптимизирован, и индексы на данных полях в SQL отсутствовали. Соответственно отсюда зависания.
(14) правда не знаю теперь как эту бд обслуживать правильно, в экспрессе нет плана обслуживания, а вручную запросы каждый раз писать тоже не лучшая идея...
(3) Нет, там всё проверено. Планировщик полностью чист, кроме легких ночных обнов некоторых программ.
Да и сервер сам не виснет. Серв сам летает, несмотря на скачок загруженности проца.
Только 1с зависает