Сервер 1С часто работает очень медленно по непонятным причинам
Здравствуйте. Имеется Сервер 1С 8.3.11.3034, СУБД MS SQL Server 2016 Standard, OS Windows 10 Prof 64 bit. На сервере имеются различные БД 1С в конфигурациях Бухгалтерия для Казахстана 3.0, Торговля для Казахстана 3.0. Проблема: периодически все БД на Сервере 1С начинают работать медленно: медленное открытие базы, конфигуратора, проведение документов, выполнение любых задач.
При возникновении проблемы нагрузки на компьютере нет: нагрузка на процессор не более 10 %, свободный объем оперативной памяти 10,5 GB из 24 GB, нагрузка на дисковую систему незначительная – скорость чтения/записи на диски с базами не превышает 8 Мбайт/сек – нагрузка пиковая. При возникновении данной проблемы на данный момент найдено только 1 решение: перезапуск служб Сервера 1С, Сервера SQL
Был проведен такой эксперимент: в момент проблемы был установлен на этот же компьютер второй экземпляр службы Сервера 1С Предприятия, БД 1С работающая медленно, была удалена из проблемного экземпляра Сервера 1С и подключена на втором экземпляре. После этого БД 1С начала работать быстро, после «возврата» БД 1С на предыдущий экземпляр Сервера 1С проблема вновь появилась. Все эти действия выполнялись в рамках 1 экземпляра Сервера SQL, без его перезапуска, на сервере SQL никакие манипуляции не проводились, БД 1С не отсоединялась. Данный эксперимент дает понятие что проблема именно в ПО 1С.
Данная проблема диагностируется на различных версиях платформы 1С. Что пробовали делать:
1. Удалять с сервера антивирус
2. Полностью удалять 1С, папку srvinfo, выполнять повторную установку
3. Менять формат файлов журнала регистрации баз с lgd на lgf
При возникновении проблемы нагрузки на компьютере нет: нагрузка на процессор не более 10 %, свободный объем оперативной памяти 10,5 GB из 24 GB, нагрузка на дисковую систему незначительная – скорость чтения/записи на диски с базами не превышает 8 Мбайт/сек – нагрузка пиковая. При возникновении данной проблемы на данный момент найдено только 1 решение: перезапуск служб Сервера 1С, Сервера SQL
Был проведен такой эксперимент: в момент проблемы был установлен на этот же компьютер второй экземпляр службы Сервера 1С Предприятия, БД 1С работающая медленно, была удалена из проблемного экземпляра Сервера 1С и подключена на втором экземпляре. После этого БД 1С начала работать быстро, после «возврата» БД 1С на предыдущий экземпляр Сервера 1С проблема вновь появилась. Все эти действия выполнялись в рамках 1 экземпляра Сервера SQL, без его перезапуска, на сервере SQL никакие манипуляции не проводились, БД 1С не отсоединялась. Данный эксперимент дает понятие что проблема именно в ПО 1С.
Данная проблема диагностируется на различных версиях платформы 1С. Что пробовали делать:
1. Удалять с сервера антивирус
2. Полностью удалять 1С, папку srvinfo, выполнять повторную установку
3. Менять формат файлов журнала регистрации баз с lgd на lgf
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2)
- размер логов чего - 1С или SQL ? Если SQL - то в базе режим восстановления указан "Простой", при этом в момент проблемы медленно работают абсолютно все базы, включая обычные демо-базы, которые просто "болтаются" на сервере для демонстрации - т.е. логи у них не больше 400 МБ, да и не в SQL проблема, т.к, как писал выше, если в пределах SQL Server'а перенести базу с проблемного Сервера 1С на другой экземпляр, то все ОК
- Или вы писали про размер логов сервера 1С ?
Просьба уточнить
проверьте размер лого
- размер логов чего - 1С или SQL ? Если SQL - то в базе режим восстановления указан "Простой", при этом в момент проблемы медленно работают абсолютно все базы, включая обычные демо-базы, которые просто "болтаются" на сервере для демонстрации - т.е. логи у них не больше 400 МБ, да и не в SQL проблема, т.к, как писал выше, если в пределах SQL Server'а перенести базу с проблемного Сервера 1С на другой экземпляр, то все ОК
- Или вы писали про размер логов сервера 1С ?
Просьба уточнить
если в кластере более 1-го рабочего сервера, то настройки кластера можно установить таким образом, чтобы при возникновении подобного рода проблем рабочие процессы "перескакивали" с "загруженного" сервера на не "загруженный"
"загруженный" - значит тормозит, а не показатели загрузки.
как-то так у нас решили такую задачу, подробностей у меня нет - админкой кластера рулят другие спецы.
"загруженный" - значит тормозит, а не показатели загрузки.
как-то так у нас решили такую задачу, подробностей у меня нет - админкой кластера рулят другие спецы.
(3)
- В кластере 1 рабочий сервер. Пока пробую решить проблему в рамках 1 кластера, 1 экземпляра службы Сервера 1С, без усложения структуры кластером.
если в кластере более 1-го рабочего сервера, то настройки кластера можно установить таким образом, чтобы при возникновении подобного рода проблем рабочие процессы "перескакивали" с "загруженного" сервера на не "загруженный"
- В кластере 1 рабочий сервер. Пока пробую решить проблему в рамках 1 кластера, 1 экземпляра службы Сервера 1С, без усложения структуры кластером.
При большой очереди к дискам на сервере приложений начинают тупить абсолютно все операции, а сервер БД может простаивать.
Если диски - узкое место, то достаточно чтобы наложилось несколько тяжелых операций. И все - вы сваливаетесь во всеобщие тормоза.
Если диски - узкое место, то достаточно чтобы наложилось несколько тяжелых операций. И все - вы сваливаетесь во всеобщие тормоза.
Эксперимент с переподключением БД может говорить о том, что проблема может быть в индексе полнотекстового поиска (регламентные задания по его обновлению запускаются ежеминутно и при проблемах с ним могут создавать лишнюю дисковую нагрузку). Можно попробовать его очистить и полностью пересчитать.
Нагрузку на процессор, память (доступность свободной памяти), дисковую систему проверял в первую очередь, и проблема не в них, т.к. в момент проблемы:
1. Процессор бывает абсолютно не загружен: нагрузка до 5 %
2. Свободной оперативной памяти 7 GB из- 24 имеющихся
3. Нагрузка на дисковую подсистему почти отсутствует: чтение или запись 500 Кбайт/сек, процент времени бездействия 90, % активности протиовлоложен - до 10, средняя длина очереди диска меньше 0,5
- т.е. "железную" причину как нехватку ресурсов можно отмести.
Сан Саныч, вы пишете о причине полнотекстового поиска. На этом сервере работает до 30 баз, при этом базы часто удаляются, создаются новые - программисты на этом сервере делают ТЗ для клиентов. Как в таком случае определить полнотекстовый поиск является причиной или нет ?
1. Процессор бывает абсолютно не загружен: нагрузка до 5 %
2. Свободной оперативной памяти 7 GB из- 24 имеющихся
3. Нагрузка на дисковую подсистему почти отсутствует: чтение или запись 500 Кбайт/сек, процент времени бездействия 90, % активности протиовлоложен - до 10, средняя длина очереди диска меньше 0,5
- т.е. "железную" причину как нехватку ресурсов можно отмести.
Сан Саныч, вы пишете о причине полнотекстового поиска. На этом сервере работает до 30 баз, при этом базы часто удаляются, создаются новые - программисты на этом сервере делают ТЗ для клиентов. Как в таком случае определить полнотекстовый поиск является причиной или нет ?
Так же проводил такой эксперимент: в момент проблемы в Администрирование Серверов 1С Предприятия в сеансах по очереди удалял все сеансы к БД, пытаясь таким образом найти "проблемный" сеанс или БД - но ничего не вышло. При удалении всех сеансов, Сервер 1С все работает медленно. Такое ощущение что что-то периодически создает на нем какой-то глюк, приводящий к медленной работе, и в момент возникновения глюка удаление сеансов, отключение БД, которые подозреваешь, уже не помогает.
Anton Palshin
(13)
- Сейчас настольные ОС располагают достаточными возможностями для расположения на них некоторых серверных ролей. Скажу больше:
1. на данном сервере расположено 2 основных экземпляра Сервера SQl и 1C - базы 1С для ТЗ - где происходит проблема, и рабочие базы бухгалтерии. Для каждых баз свой экземпляр 1С и SQL, свои диски, приоритеты по процессорам. На экземплярах с рабочими базами проблем не наблюдается - т.е. эта проблема не влияет на работоспособность других экземпляров в пределах этого же сервера
2. Варианты с установкой сервера 1С и SQL на настольной ОС Prof-версии. Уже реализованы мной как минимум в 20 компаниях. Нареканий, проблем нет. Сейчас, когда лицензии на серверное ПО стоят очень дорого, а нужно реализовать серверную структуру, не нарушая при этом лицензионность - вариант с настольными ОС часто оказывается "рабочей лошадкой".
Платформу менял, эта проблема началась когда еще была 8.3.9, смена платформы ничего не дает.
(13)
Win 10 в качестве сервера 1С для 30 баз - хм... надо попробовать.
- Сейчас настольные ОС располагают достаточными возможностями для расположения на них некоторых серверных ролей. Скажу больше:
1. на данном сервере расположено 2 основных экземпляра Сервера SQl и 1C - базы 1С для ТЗ - где происходит проблема, и рабочие базы бухгалтерии. Для каждых баз свой экземпляр 1С и SQL, свои диски, приоритеты по процессорам. На экземплярах с рабочими базами проблем не наблюдается - т.е. эта проблема не влияет на работоспособность других экземпляров в пределах этого же сервера
2. Варианты с установкой сервера 1С и SQL на настольной ОС Prof-версии. Уже реализованы мной как минимум в 20 компаниях. Нареканий, проблем нет. Сейчас, когда лицензии на серверное ПО стоят очень дорого, а нужно реализовать серверную структуру, не нарушая при этом лицензионность - вариант с настольными ОС часто оказывается "рабочей лошадкой".
Платформу менял, эта проблема началась когда еще была 8.3.9, смена платформы ничего не дает.
В копиях баз : первым делом советую отключить Регламентные задания, и Журнал регистрации;
Тормоза также могут быть из-за огромного размера файла журнала регистрации;
Модель восстановления всех баз в SQL - простая (Вы писали уже)
... уже не помню деталей, но читал что тормоза могут быть из-за слишком большой/слишком маленькой даты в Регистрах бухгалтерии типа 01/01/0018
Тормоза также могут быть из-за огромного размера файла журнала регистрации;
Модель восстановления всех баз в SQL - простая (Вы писали уже)
... уже не помню деталей, но читал что тормоза могут быть из-за слишком большой/слишком маленькой даты в Регистрах бухгалтерии типа 01/01/0018
Если сервер - виртуальная машина, то проблема скорее всего в настройках этой самой машины. Главное - вся её память должна быть настоящей - не шариться с другими машинами. В противном случае вы столкнётесь с ситуацией, когда гостевая ОС считает, что памяти достаточно и нет почти никакого внутреннего свопа, но ферма виртуализации постоянно этот своп гоняет снаружи. Это справедливо как к серверу платформы 1С, так и БД.
сервер 1с и сервер SQL разнесены на разные сервера. Проблема та же, база начинает работать очень медленно, хотя нагрузки на серваках нет, что на 1с что на SQL. Достаточно перезагрузить сервер 1с и тормоза уходят. (следовательно проблема в сервере 1с) Конфа ERP. Перезагрузка требуется примерно каждый 1 или 2 дня. Есть также УТ 11.4, работает на отдельных серверах 1с и SQL (для ERP И УТ у меня разные железные сервера), перезагрузку делаю раз в месяц, а то и реже. Заметил разницу, что ERP начинает тормозить когда rphost более 20гб, хотя на сервере еще очень много свободной ОЗУ. 1с УТ 11.4 спокойно работает когда rphost занимает 20 гб. Понять проблему не могу. Настройки серверов идентичные, размеры баз и кол-во работающих пользователей примерно одинаковы +-.
Добрый день. Аналогичная проблема. У кого-то получилось ее решить? У себя заметил, что тормоза начинаются после какой-то тяжелой операции (перепроведение док-тов за 1 день или даже после формирования отчета по продажам за большой период времени - 1 год). Операция завершается, а сервер продолжает работать медленно даже после закрытия сеансов.
(21)
Ранее был вопрос
Очень просто: отключаете регламентное задание во всех базах (на один день) и смотрите осталась ли проблема. Потом по одной базе включаете.
Чисто теоретически можно посмотреть размеры каталогов полнотекстового поиска у баз, и если есть какая то база с аномально большим размером - очистить индекс в ней и пересоздать.
При проблемах с индексом есть смысл при смене релиза платформы очищать и пересоздавать индекс во всех базах.
Еще в целях диагностики в настройках кластера можно выставить "1 база на рабочий процесс" (требуется лицензия КОРП).
А также смотреть на показатель "производительность" в свойствах рабочих процессов в консоли администрирования, чтобы выявить проблемный процесс, и обслуживаемую им базу.
Дополнительно посмотрите запуск регламентных в момент возникновения проблем (может и раньше, например, закрытие месяца может работать несколько часов, из них проблемную нагрузку создавать только на 2й-3й час).
Ранее был вопрос
Как в таком случае определить полнотекстовый поиск является причиной или нет ?
Очень просто: отключаете регламентное задание во всех базах (на один день) и смотрите осталась ли проблема. Потом по одной базе включаете.
Чисто теоретически можно посмотреть размеры каталогов полнотекстового поиска у баз, и если есть какая то база с аномально большим размером - очистить индекс в ней и пересоздать.
При проблемах с индексом есть смысл при смене релиза платформы очищать и пересоздавать индекс во всех базах.
Еще в целях диагностики в настройках кластера можно выставить "1 база на рабочий процесс" (требуется лицензия КОРП).
А также смотреть на показатель "производительность" в свойствах рабочих процессов в консоли администрирования, чтобы выявить проблемный процесс, и обслуживаемую им базу.
Дополнительно посмотрите запуск регламентных в момент возникновения проблем (может и раньше, например, закрытие месяца может работать несколько часов, из них проблемную нагрузку создавать только на 2й-3й час).
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот