Как увидеть "невидимое" (причины тормозов)
Коллеги, посоветуйте куда копать. Ситуация следующая. Есть сервер ERP на очень хорошем железе. Пашет чуть ли не на RAM диске (PCI SSD). Онлайн >300 пользователей.
В последнее время наблюдаются странные тормоза. Например:
- перед проверкой метаданных в конфигураторе. Жму F7 идет проверка минут 10. При этом все пользователи наглухо виснут, только мышка и двигается. После проверки метаданных, уже конфигуратор предлагает обновится динамически. После этого ситуация может развиваться следующим образом:
- Приемлемый сценарий: пользователи зависают пачками (кого-то может даже выкинуть), но все-таки периодически отвисают. В какой-то момент, через пол часа - час все приходит в норму.
- Не приемлемый сценарий: зависают все наглухо на час-два.
- бывает периодически зависания наглухо и без обновления конфигурации. Просто стихийно - все резко встали и все, ждем минут 30 - час.
- бывают паразитические зависания - работать можно, но трудно, видно что висит добрая половина. Отвисают, снова зависают. Может длиться сколь угодно долго. Пока не перезагрузят сервер.
Что делали:
- долго наблюдали в консоль администратора, чтобы найти виноватых. Находили - регламентные задания по обмену, отчеты, кривые руки пользователей, ошибки в конфигураторе. В какой-то момент что смогли исправили, что смогли - отключили. Виноватые пропали, зависания - нет.
- включили монитор ресурсов сервера, стали анализировать очереди ожидания дисков, сетевую пропускную способность, оперативную память - все внешне выглядит так, что с сервером вообще никто не работает. Ресурсов хватает на эмуляцию ядерного взрыва...
- добрались до Activity Monitor SQL Management Studio. Внешне выглядит как будто - активности нет.
- включили технологический журнал. Видимых ошибок типа "конфликт блокировок", "предоставление ожидания блокировки" и т.п. - нет вообще.
Вчера была кульминация - даже перезагрузка сервера не помогла:
- чтобы избавится от динамического обновления - выгнали всех. Запретили вход
- обновили конфигурацию
- запустили пользователей и все. Висеть они начали с самого первого пользователя. 300 пользователей зашли и все висят после авторизации. Ждали 40 минут. Решили перезагрузить сервер - полностью железку. Запустился и все повторилось заново...
Куда копать и зачем пользователи висят, если ресурсы доступны на 99%?
В последнее время наблюдаются странные тормоза. Например:
- перед проверкой метаданных в конфигураторе. Жму F7 идет проверка минут 10. При этом все пользователи наглухо виснут, только мышка и двигается. После проверки метаданных, уже конфигуратор предлагает обновится динамически. После этого ситуация может развиваться следующим образом:
- Приемлемый сценарий: пользователи зависают пачками (кого-то может даже выкинуть), но все-таки периодически отвисают. В какой-то момент, через пол часа - час все приходит в норму.
- Не приемлемый сценарий: зависают все наглухо на час-два.
- бывает периодически зависания наглухо и без обновления конфигурации. Просто стихийно - все резко встали и все, ждем минут 30 - час.
- бывают паразитические зависания - работать можно, но трудно, видно что висит добрая половина. Отвисают, снова зависают. Может длиться сколь угодно долго. Пока не перезагрузят сервер.
Что делали:
- долго наблюдали в консоль администратора, чтобы найти виноватых. Находили - регламентные задания по обмену, отчеты, кривые руки пользователей, ошибки в конфигураторе. В какой-то момент что смогли исправили, что смогли - отключили. Виноватые пропали, зависания - нет.
- включили монитор ресурсов сервера, стали анализировать очереди ожидания дисков, сетевую пропускную способность, оперативную память - все внешне выглядит так, что с сервером вообще никто не работает. Ресурсов хватает на эмуляцию ядерного взрыва...
- добрались до Activity Monitor SQL Management Studio. Внешне выглядит как будто - активности нет.
- включили технологический журнал. Видимых ошибок типа "конфликт блокировок", "предоставление ожидания блокировки" и т.п. - нет вообще.
Вчера была кульминация - даже перезагрузка сервера не помогла:
- чтобы избавится от динамического обновления - выгнали всех. Запретили вход
- обновили конфигурацию
- запустили пользователей и все. Висеть они начали с самого первого пользователя. 300 пользователей зашли и все висят после авторизации. Ждали 40 минут. Решили перезагрузить сервер - полностью железку. Запустился и все повторилось заново...
Куда копать и зачем пользователи висят, если ресурсы доступны на 99%?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(18)
ну с моей точки зрения вполне себе свежая :)
А у вас на сервере одна база или несколько? Когда тормозит основная база на её копии на том же сервере тормоза наблюдаются?
Хоть как-то отделить это проблема конкретной конфигурации или платформы и ОС...
2012 считается древней?
ну с моей точки зрения вполне себе свежая :)
А у вас на сервере одна база или несколько? Когда тормозит основная база на её копии на том же сервере тормоза наблюдаются?
Хоть как-то отделить это проблема конкретной конфигурации или платформы и ОС...
(19) Ряд проблем затрагивал весь сервер - но источником проблемы однозначно была эта база - потом по логам вытаскивали. И причем сильно нарастают проблемы именно тогда когда подключается более 50 пользователей.
То есть если бы к копии подключилось много пользователей - она возможно тоже начала бы себя так вести.
То есть если бы к копии подключилось много пользователей - она возможно тоже начала бы себя так вести.
(19)
Одна
(22)
Статистика на SQL сервере показывает, что в ТОПы попадают динамические запросы форм списков документов. Их выдает наличие "Top 40"/"Top 45".
Запросы типовые. К ним добавляется RLS + отборы с формы. Т.е., так называемая Pagination. Но, сервер при этом разгружен. То, что запросы часто "долбят" SQL сервер еще не означает, что это приводит к тормозам остальных.
И конечно отчеты. При закрытии месяца из-за них тормозят все жутко, но сервер при этом разгружен по всем мониторам ресурсов.
(23)
На сервере отключен. На пользовательских машинах никто не даст этого сделать. Да и не может быть дело в нем, т.к. подключались напрямую к серверу и на нем же запускали клиент 1С для отсекания проблем с сетью.
(24)
Вы про snccntx файлы?
А у вас на сервере одна база или несколько?
Одна
(22)
активно использовать поиски и отборы в различных списках. (почему и искали проблему в основном в области ППД)
Статистика на SQL сервере показывает, что в ТОПы попадают динамические запросы форм списков документов. Их выдает наличие "Top 40"/"Top 45".
Запросы типовые. К ним добавляется RLS + отборы с формы. Т.е., так называемая Pagination. Но, сервер при этом разгружен. То, что запросы часто "долбят" SQL сервер еще не означает, что это приводит к тормозам остальных.
И конечно отчеты. При закрытии месяца из-за них тормозят все жутко, но сервер при этом разгружен по всем мониторам ресурсов.
(23)
Антивирус не пробовали отключать и на сервере и на всех клиентских машинах хотя бы на час? (Может даже по этому поводу инет отключить и флешки на часик запретить чтобы без эксцессов )
На сервере отключен. На пользовательских машинах никто не даст этого сделать. Да и не может быть дело в нем, т.к. подключались напрямую к серверу и на нем же запускали клиент 1С для отсекания проблем с сетью.
(24)
Попробуй остановить службу сервера и почистить серверный кэш.
Вы про snccntx файлы?
(25)
ну так если добавить еще одну копию базы на сервер и посмотреть синхронно они тормозят или каждая в свое время?
Если тормоза одной базы не будут влиять на другую то возможно у какого то пользователя выполняются какие-то длительные транзакции?
Когда у вас после перезагрузки сервера база тормозит, не проверяли, сразу после перезагрузки в списке пользователей пусто или уже есть какое-то фоновое задание?
Одна
ну так если добавить еще одну копию базы на сервер и посмотреть синхронно они тормозят или каждая в свое время?
Если тормоза одной базы не будут влиять на другую то возможно у какого то пользователя выполняются какие-то длительные транзакции?
Когда у вас после перезагрузки сервера база тормозит, не проверяли, сразу после перезагрузки в списке пользователей пусто или уже есть какое-то фоновое задание?
(26)
Мысль возьму на заметку. Спасибо.
(26)
После перезагрузки старые сессии не "отвалились" (они и не отваливаются после перезагрузок операционной системы сервера), в том числе и фоновые задания. Но блокировка регламентных заданий стояла.
Т.е. картина такая: после обновления конфигурации сессий не было, открыл вход, 300 человек набежали, никто за 40 минут не прогрузился, ребутнули сервер без снятии сессий и установки блокировки на вход, поднялась операционная система, в консоли все сессии остались висеть, и продолжили висеть дальше еще около часа. В ТЖ видно, что сервер 1С запустился раньше SQL сервера, т.к. некоторые клиенты получали ошибки с невозможностью соединиться с SQL сервером. Даже когда SQL сервер поднялся (это тоже было видно в ТЖ, т.к. пошли запросы к таблице SystemSettings (ХранилищеОбщихНастроек)), все еще продолжали висеть после ввода логина и пароля.
ну так если добавить еще одну копию базы на сервер и посмотреть синхронно они тормозят или каждая в свое время?
Мысль возьму на заметку. Спасибо.
(26)
Когда у вас после перезагрузки сервера база тормозит, не проверяли, сразу после перезагрузки в списке пользователей пусто или уже есть какое-то фоновое задание?
После перезагрузки старые сессии не "отвалились" (они и не отваливаются после перезагрузок операционной системы сервера), в том числе и фоновые задания. Но блокировка регламентных заданий стояла.
Т.е. картина такая: после обновления конфигурации сессий не было, открыл вход, 300 человек набежали, никто за 40 минут не прогрузился, ребутнули сервер без снятии сессий и установки блокировки на вход, поднялась операционная система, в консоли все сессии остались висеть, и продолжили висеть дальше еще около часа. В ТЖ видно, что сервер 1С запустился раньше SQL сервера, т.к. некоторые клиенты получали ошибки с невозможностью соединиться с SQL сервером. Даже когда SQL сервер поднялся (это тоже было видно в ТЖ, т.к. пошли запросы к таблице SystemSettings (ХранилищеОбщихНастроек)), все еще продолжали висеть после ввода логина и пароля.
Пропробйте таки сделать ТИИ с реструктуризацией.
(25)
У нас в моменты полтергейста вообще ситуация странная была - начинаешь поиск - запускается фоновое на сервере 1С - а на SQL сервер запрос прилетает спустя какое то время и сразу после обработки отвисает в 1С.
В те моменты когда удавалось начать ловить эту ситуацию - такое ощущение что сам запрос для sql строился 1C очень долго. Поймать это тоже проблема - постепенно зависают все и даже конфигуратор. В большинстве случаев на момент этих полтергейстов ничего криминального в журнале не было - как будто бы там просто очередь и все обработаться не успевает. Зависания не всегда были для всех - а по рабочим процессам - начилась в одном все его соединения подвисают. При этом у соединений остальных процессов вроде все в порядке.(в данном случае не проверяли как прилетают запросы на sql). К моменту когда зависали все к SQL серверу запросы от 1с переставили прилетать.
На копии базы ни на этом, ни на свободном идентичном сервере моменты потергейсты повторить не удалось.
(25)
Но, сервер при этом разгружен. То, что запросы часто "долбят" SQL сервер еще не означает, что это приводит к тормозам остальных.
У нас в моменты полтергейста вообще ситуация странная была - начинаешь поиск - запускается фоновое на сервере 1С - а на SQL сервер запрос прилетает спустя какое то время и сразу после обработки отвисает в 1С.
В те моменты когда удавалось начать ловить эту ситуацию - такое ощущение что сам запрос для sql строился 1C очень долго. Поймать это тоже проблема - постепенно зависают все и даже конфигуратор. В большинстве случаев на момент этих полтергейстов ничего криминального в журнале не было - как будто бы там просто очередь и все обработаться не успевает. Зависания не всегда были для всех - а по рабочим процессам - начилась в одном все его соединения подвисают. При этом у соединений остальных процессов вроде все в порядке.(в данном случае не проверяли как прилетают запросы на sql). К моменту когда зависали все к SQL серверу запросы от 1с переставили прилетать.
На копии базы ни на этом, ни на свободном идентичном сервере моменты потергейсты повторить не удалось.
(3) над конфигурацией круглые сутки трудятся человек 5 через хранилище. Под доработки часто приходится исправлять отчеты и ошибки внесенные в прошлый раз. Спокойно, размеренно программировать с проверкой и бета-тестированием, обновлением раз в неделю - не дает ни руководство, ни 300 пользователей.
(2)
Программная лицензия раздается.
(2)
Если аппаратные ключи то в nethasp.ini отключить BROADCAST, оставить только tcpip и прописать адрес сервера где вставлен ключ, также проверить нагрузку на этом сервере.
Программная лицензия раздается.
А версия платформы какая?
У нас на 8.3.10 и уже несколько перебранных релизов постоянная проблема с обновлениями. Динамически в принципе давно не обновляем - но и монополное не панацея - на данный момент обновление это обновить и обязательно принудительно запустить реструктуризация таблиц ИБ.
Без реструктуризации - все непонятно подвисают, полнотекстовый поиск жутко висит везде - даже на маленьких справочниках. Появляются проблемы с подключением к базе. При этом ресурсы вообще не испольюзуются. Все висят но сервер свободен.
Сначала думали проблема в индексах ППД. Уже месяца три перебираем различные букеты проблем, случайным образом заметили про реструктуризацию - и вот уже 2 недели полет с обновлениями нормальный - и букет непонятных зависаний исчез.
У нас на 8.3.10 и уже несколько перебранных релизов постоянная проблема с обновлениями. Динамически в принципе давно не обновляем - но и монополное не панацея - на данный момент обновление это обновить и обязательно принудительно запустить реструктуризация таблиц ИБ.
Без реструктуризации - все непонятно подвисают, полнотекстовый поиск жутко висит везде - даже на маленьких справочниках. Появляются проблемы с подключением к базе. При этом ресурсы вообще не испольюзуются. Все висят но сервер свободен.
Сначала думали проблема в индексах ППД. Уже месяца три перебираем различные букеты проблем, случайным образом заметили про реструктуризацию - и вот уже 2 недели полет с обновлениями нормальный - и букет непонятных зависаний исчез.
Еще одно наблюдение - не просто много пользователей подключаются - а именно начинают очень активно использовать поиски и отборы в различных списках. (почему и искали проблему в основном в области ППД)
Но полная очистка и пересоздание индексов решить эту проблему не помогает. Мало того сервер пишет что индексы актуальны - но в произвольные моменты времени все вдруг начинает висеть при попытки поиска в дс
Но полная очистка и пересоздание индексов решить эту проблему не помогает. Мало того сервер пишет что индексы актуальны - но в произвольные моменты времени все вдруг начинает висеть при попытки поиска в дс
v1-- создать копию базы в sql , модель восстановления выбрать простая, журнал обнулится и проверить работу, насколько я понимаю тут 300 юзеров не нужно
v2-- на рабочей базе средствами sql , задачи-создать резервную копию, сначала полную, затем журнал транзакций, в параметрах отметить опцию "Усечь журнал транзакций". тогда жт в архиве будет, а в базе усечется, и ничто не потеряно.
v3-- попробуйте службу агента sql остановить (или Агент SQL сервер в Management Studio), может в sql задания плана обслуживания накосячены, если поможет тогда и разбирайтесь с заданиями.
v4 -- в журнале sql ничего странного нет? ошибок соединения?
v5 -- сервер 1с к sql по имени обращается (на одной машине оба сервера) попробуйте на ip адрес поменять , даже если localhost.
v6 -- зеркалирование sql сервера выполнено ?? проверьте связь с зеркалом (в зависимости от варианта)
v2-- на рабочей базе средствами sql , задачи-создать резервную копию, сначала полную, затем журнал транзакций, в параметрах отметить опцию "Усечь журнал транзакций". тогда жт в архиве будет, а в базе усечется, и ничто не потеряно.
v3-- попробуйте службу агента sql остановить (или Агент SQL сервер в Management Studio), может в sql задания плана обслуживания накосячены, если поможет тогда и разбирайтесь с заданиями.
v4 -- в журнале sql ничего странного нет? ошибок соединения?
v5 -- сервер 1с к sql по имени обращается (на одной машине оба сервера) попробуйте на ip адрес поменять , даже если localhost.
v6 -- зеркалирование sql сервера выполнено ?? проверьте связь с зеркалом (в зависимости от варианта)
1. Была похожая проблема - оказалась в ключах , как уже писали.
Административными инструментами проверить кто на каких ключах.
Вставить физ ключ у тестовых пользователей и пронаблюдать работу.
Купить USB ключи вместо программных.
2. Жр регламентом чистить
3. Проверить используются ли огромные транзакции при обмене.
4. Поставить PERFEXPERT (дорого !)
PS
Судя по : " что первые зашедшими в базу были пользователи с ограниченными правами и зависли они еще на этапе авторизации. "
ключи давно надо было проверить в первую очередь
Административными инструментами проверить кто на каких ключах.
Вставить физ ключ у тестовых пользователей и пронаблюдать работу.
Купить USB ключи вместо программных.
2. Жр регламентом чистить
3. Проверить используются ли огромные транзакции при обмене.
4. Поставить PERFEXPERT (дорого !)
PS
Судя по : " что первые зашедшими в базу были пользователи с ограниченными правами и зависли они еще на этапе авторизации. "
ключи давно надо было проверить в первую очередь
- чтобы избавится от динамического обновления - выгнали всех. Запретили вход
- обновили конфигурацию
- запустили пользователей и все. Висеть они начали с самого первого пользователя. 300 пользователей зашли и все висят после авторизации. Ждали 40 минут. Решили перезагрузить сервер - полностью железку. Запустился и все повторилось заново...
А чистили сеансы перед тем как сервер ребутнуть?
Если не чистили, то чистите. Это убережет от таких проблем в 99% случаев.
- обновили конфигурацию
- запустили пользователей и все. Висеть они начали с самого первого пользователя. 300 пользователей зашли и все висят после авторизации. Ждали 40 минут. Решили перезагрузить сервер - полностью железку. Запустился и все повторилось заново...
А чистили сеансы перед тем как сервер ребутнуть?
Если не чистили, то чистите. Это убережет от таких проблем в 99% случаев.
И мой вам совет, когда увеличите кол-во РП до кол-во ядер процессора:
1. Вводите ограничения памяти на процесс
2. Не обновляйтесь динамически при кол-ве памяти около 5Гб. Выгоняйте всех. Сбережете нервы себе и пользователям
1. Вводите ограничения памяти на процесс
2. Не обновляйтесь динамически при кол-ве памяти около 5Гб. Выгоняйте всех. Сбережете нервы себе и пользователям
(39)
Делали подобную настройку и вот к чему это привело:
- каждый из rphost'ов съедает минимум 2Гб ОЗУ даже при одном пользователе;
- на каждом из rphost'ов память растет по линейному сценарию, она может выделяться сотнями мегабайт, а освобождаться килобайтами;
- наша группа администрирования может запускать обработки и отчеты, которые единолично могут съесть и 10Гб ОЗУ;
- когда (не "если"!) происходит превышение ограничение по ОЗУ на один rphost - пользователи с него начинают отваливаться. Это происходит веерно, сначала на одном rphost'е, затем на втором, третьем и т.д. Т.е. нет никакого "прозрачного переключения сессии/соединения на новый rphost".
- при работе с одним rphost'ом он может съесть 50Гб ОЗУ, но все более менее работают;
Замкнутый круг...
И мой вам совет, когда увеличите кол-во РП до кол-во ядер процессора:
1. Вводите ограничения памяти на процесс
2. Не обновляйтесь динамически при кол-ве памяти около 5Гб. Выгоняйте всех. Сбережете нервы себе и пользователям
1. Вводите ограничения памяти на процесс
2. Не обновляйтесь динамически при кол-ве памяти около 5Гб. Выгоняйте всех. Сбережете нервы себе и пользователям
Делали подобную настройку и вот к чему это привело:
- каждый из rphost'ов съедает минимум 2Гб ОЗУ даже при одном пользователе;
- на каждом из rphost'ов память растет по линейному сценарию, она может выделяться сотнями мегабайт, а освобождаться килобайтами;
- наша группа администрирования может запускать обработки и отчеты, которые единолично могут съесть и 10Гб ОЗУ;
- когда (не "если"!) происходит превышение ограничение по ОЗУ на один rphost - пользователи с него начинают отваливаться. Это происходит веерно, сначала на одном rphost'е, затем на втором, третьем и т.д. Т.е. нет никакого "прозрачного переключения сессии/соединения на новый rphost".
- при работе с одним rphost'ом он может съесть 50Гб ОЗУ, но все более менее работают;
Замкнутый круг...
(40)
У вас тормоза именно из-за того, что 1 РП хост.
У вас ядра процессора как загружены? Равномерно или нет?
У меня в аналогичной ситуации была неравномерная загрузка ядер, из-за этого был большой отклик сервера.
Точнее сама 1С использовала только 1 процессор. Из чего я сделал вывод, что сервер 1С не умеет перекидывать потоки между ядрами процессора.
В результате мы тупо упираемся в производительность 1 ядра.
На остальные ядра загрузка минимальная, она создается MS SQL, который в свою очередь почти не потребляет ресурсов из-за того, что обращения к нему идут очень нечасто.
Нормальная картина, когда MS SQL загружает процессор на 20-25%, РП на 10-15%.
Для этого и нужно выставлять ограничение.
И обязательно отключайте отладку, она сильно увеличивает скорость роста расхода памяти
Странно, что подобные обработки запускаются в моменты пиковой активности пользователей.
На время таких обработок можно временно снимать ограничение
Вам нужно выбрать или поведение, которое у вас сейчас наблюдается либо тормоза и возможный разрыв сессии при миграции с одного на другой РП. Это выбор между скоростью отклика сервера и расходом ресурсов (оперативной памяти в большей степени).
Для того, чтобы не было веера завершения РП уменьшите время засыпания РП и его завершения в спящем рижиме (по умолчанию очень большое время, это делается в конфигураторе). При таких настройках вылет пользователей минимизируется. У нас на 150 пользователях 2 завершения РП проблемные (примерно). А в день их около 30.
Выделенная память на 1С порядка 64 Гб, 8 РП, ограничение 7,5 Гб
У нас абсолютно такая же ситуация как и у вас. Платформа 8.3.8. Выбрали второй вариант. Т.к. беды (вылет программы при миграции пользователей) 20 человек (а именно такое у нас тоит кол-во пользователей на процесс) не сравнимы с бедами оставшихся 130.
Очень ждем 8.4 и надеемся, что там сборщик мусора JVM снимет часть проблем.
+ мониторинг отклика РП и параметров сервера в Zabbix. Как только видим приближение нехватки памяти уведомляем пользователей проблемного РП и завершаем его. Это случается где-то 2 раза в неделю. В остальное время (если нет динамический обновлений) сводная память на севрере 15 Гб. Всего на сервере 128 Гб, 64 Гб отдано по MS SQL
Поставьте 8.3.10 и посмотрите циклические ссылки. Может у вас в этом проблема. У знакомого были в ERP. Мы у себя не смотрели (УТ11), платформа старая =(
Замкнутый круг...
У вас тормоза именно из-за того, что 1 РП хост.
У вас ядра процессора как загружены? Равномерно или нет?
У меня в аналогичной ситуации была неравномерная загрузка ядер, из-за этого был большой отклик сервера.
Точнее сама 1С использовала только 1 процессор. Из чего я сделал вывод, что сервер 1С не умеет перекидывать потоки между ядрами процессора.
В результате мы тупо упираемся в производительность 1 ядра.
На остальные ядра загрузка минимальная, она создается MS SQL, который в свою очередь почти не потребляет ресурсов из-за того, что обращения к нему идут очень нечасто.
Нормальная картина, когда MS SQL загружает процессор на 20-25%, РП на 10-15%.
на каждом из rphost'ов память растет по линейному сценарию, она может выделяться сотнями мегабайт, а освобождаться килобайтами
Для этого и нужно выставлять ограничение.
И обязательно отключайте отладку, она сильно увеличивает скорость роста расхода памяти
Наша группа администрирования может запускать обработки и отчеты, которые единолично могут съесть и 10Гб ОЗУ
Странно, что подобные обработки запускаются в моменты пиковой активности пользователей.
На время таких обработок можно временно снимать ограничение
происходит превышение ограничение по ОЗУ на один rphost - пользователи с него начинают отваливаться. Это происходит веерно, сначала на одном rphost'е, затем на втором, третьем и т.д. Т.е. нет никакого "прозрачного переключения сессии/соединения на новый rphost"
Вам нужно выбрать или поведение, которое у вас сейчас наблюдается либо тормоза и возможный разрыв сессии при миграции с одного на другой РП. Это выбор между скоростью отклика сервера и расходом ресурсов (оперативной памяти в большей степени).
Для того, чтобы не было веера завершения РП уменьшите время засыпания РП и его завершения в спящем рижиме (по умолчанию очень большое время, это делается в конфигураторе). При таких настройках вылет пользователей минимизируется. У нас на 150 пользователях 2 завершения РП проблемные (примерно). А в день их около 30.
Выделенная память на 1С порядка 64 Гб, 8 РП, ограничение 7,5 Гб
У нас абсолютно такая же ситуация как и у вас. Платформа 8.3.8. Выбрали второй вариант. Т.к. беды (вылет программы при миграции пользователей) 20 человек (а именно такое у нас тоит кол-во пользователей на процесс) не сравнимы с бедами оставшихся 130.
Очень ждем 8.4 и надеемся, что там сборщик мусора JVM снимет часть проблем.
+ мониторинг отклика РП и параметров сервера в Zabbix. Как только видим приближение нехватки памяти уведомляем пользователей проблемного РП и завершаем его. Это случается где-то 2 раза в неделю. В остальное время (если нет динамический обновлений) сводная память на севрере 15 Гб. Всего на сервере 128 Гб, 64 Гб отдано по MS SQL
Поставьте 8.3.10 и посмотрите циклические ссылки. Может у вас в этом проблема. У знакомого были в ERP. Мы у себя не смотрели (УТ11), платформа старая =(
(44)
Потому что он должен их есть
Почему он не ест ресурсов? Потому что он медленно выполняет работу.
Если картина по загрузке ядер совпадает с той, которую я описал, то тогда мое предположение "сервер 1С не умеет перекидывать потоки между ядрами процессора" верно
Потому что он должен их есть
Почему он не ест ресурсов? Потому что он медленно выполняет работу.
Если картина по загрузке ядер совпадает с той, которую я описал, то тогда мое предположение "сервер 1С не умеет перекидывать потоки между ядрами процессора" верно
Всё выглядит так,
на действие Выпонить у вас ресурсов достаточно, а вот с какими то периферийными процессами или правами на запись файла или доступ к tmp файлам, или журнала, проблема (тем более что вы все регламенты отмели, так что остаются, права - файлы журналы, порты, у USR1CV8 все впорядке с tmp и пространством ??).
проверьте размер 1Cv8.lgd в reg_1641 (reg_xxxx), судя по вашим параметрам он должен быть гигов 70 не менее , попробуйте просто переместить/переименовать файл, встречается проблема записи в большой журнал. Или у вас в 1с журнал регистрации отключен?
И надеюсь безопасный расход памяти за один вызов в настройках сервера у вас не установлен?
Отключите все ограничения сервера 1С по памяти (если установлены). Режим распределения нагрузки - Приоритет по производительности ? иначе сервер начинает жадничать по ОЗУ. У вас кластер серверов 1с с балансировкой ? подключитесь к каждому из них проверьте поведение. Также в случае балансировки возникает проблема, что у клиента настроено соединение только к одному серверу, а сервер для балансировки перекидывает на второй и все висит ...
на действие Выпонить у вас ресурсов достаточно, а вот с какими то периферийными процессами или правами на запись файла или доступ к tmp файлам, или журнала, проблема (тем более что вы все регламенты отмели, так что остаются, права - файлы журналы, порты, у USR1CV8 все впорядке с tmp и пространством ??).
проверьте размер 1Cv8.lgd в reg_1641 (reg_xxxx), судя по вашим параметрам он должен быть гигов 70 не менее , попробуйте просто переместить/переименовать файл, встречается проблема записи в большой журнал. Или у вас в 1с журнал регистрации отключен?
И надеюсь безопасный расход памяти за один вызов в настройках сервера у вас не установлен?
Отключите все ограничения сервера 1С по памяти (если установлены). Режим распределения нагрузки - Приоритет по производительности ? иначе сервер начинает жадничать по ОЗУ. У вас кластер серверов 1с с балансировкой ? подключитесь к каждому из них проверьте поведение. Также в случае балансировки возникает проблема, что у клиента настроено соединение только к одному серверу, а сервер для балансировки перекидывает на второй и все висит ...
Ситуация сегодня. Пол дня все работали нормально, затем резко зависла половина пользователей.
"Замер производительности" с включенной отладкой на сервере показал, что все висят в этой функции (ERP):
Эта функция общего модуля вызывается через периодические проверки раз в 20 минут, а также при входе пользователя в программу. Функция может вызываться больше 200 раз пока клиент висит. УстановитьБезопасныйРежимРазделенияДанных - что конкретно она делает на уровне базы данных/железа и т.д., кто-нибудь знает?
"Замер производительности" с включенной отладкой на сервере показал, что все висят в этой функции (ERP):
Функция ВычислитьВБезопасномРежиме(Знач Выражение, Знач Параметры = Неопределено) Экспорт
УстановитьБезопасныйРежим(Истина);
МассивРазделителей = ОбщегоНазначенияПовтИсп.РазделителиКонфигурации();
Для Каждого ИмяРазделителя Из МассивРазделителей Цикл
УстановитьБезопасныйРежимРазделенияДанных(ИмяРазделителя, Истина); // ТУТ ВСЕ ВИСЯТ
КонецЦикла;
Возврат Вычислить(Выражение);
КонецФункции
ПоказатьЭта функция общего модуля вызывается через периодические проверки раз в 20 минут, а также при входе пользователя в программу. Функция может вызываться больше 200 раз пока клиент висит. УстановитьБезопасныйРежимРазделенияДанных - что конкретно она делает на уровне базы данных/железа и т.д., кто-нибудь знает?
(46)
(46)
Эта функция общего модуля вызывается через периодические проверки раз в 20 минут...Функция может вызываться больше 200 раз пока клиент висит.
У вас по трое суток пользователи висят?
(46)
УстановитьБезопасныйРежимРазделенияДанных - что конкретно она делает на уровне базы данных
Очевидно устанавливает безопасный режим разделения данных.
(47)
Они у нас начинают висеть каждый день - стабильно, даже без обновления конфигурации. Могут висеть час и более.
(47)
Но что конкретно скрывается под этой фразой? Алгоритм какой? Какие блокировки и на что ставятся, что проверяется, какие таймауты, какие действия можно сделать в этот момент, какие нельзя (помимо описанных в справочнике)?
(48)
У нас никаких разделений не используется впринципе (в параметрах подключения к базе у всех основная область, ничего лишнего, пустая строка, никакой работы в модели сервиса и т.п.)
(50)
Размер ЖР в пределах разумного, до 100Гб, старый вариант - не тормозящий никого наглухо в отличие от SQLITE варианта.
На каком из дисков? Системном, sql базы данных или под кэш сервера (где ЖР лежит)? У нас 3 разных. Там SSD стоят, но место есть. Сервер не падает из-за нехватки места на диске, пользователи сообщений никаких не получают, очередь диска нулевая. Система полностью разгружена по всем показателям.
У вас по трое суток пользователи висят?
Они у нас начинают висеть каждый день - стабильно, даже без обновления конфигурации. Могут висеть час и более.
(47)
Очевидно устанавливает безопасный режим разделения данных.
Но что конкретно скрывается под этой фразой? Алгоритм какой? Какие блокировки и на что ставятся, что проверяется, какие таймауты, какие действия можно сделать в этот момент, какие нельзя (помимо описанных в справочнике)?
(48)
а разделение настроено? может криво настроили?
У нас никаких разделений не используется впринципе (в параметрах подключения к базе у всех основная область, ничего лишнего, пустая строка, никакой работы в модели сервиса и т.п.)
(50)
(46)проверьте размер журнала 1С (при большом размере, начинаются жуткие тормоза), в момент зависания пользователей проверьте свободное место на жестком диске.
Размер ЖР в пределах разумного, до 100Гб, старый вариант - не тормозящий никого наглухо в отличие от SQLITE варианта.
На каком из дисков? Системном, sql базы данных или под кэш сервера (где ЖР лежит)? У нас 3 разных. Там SSD стоят, но место есть. Сервер не падает из-за нехватки места на диске, пользователи сообщений никаких не получают, очередь диска нулевая. Система полностью разгружена по всем показателям.
(53)
Не везде, но используются. Причем интересно то, что когда пользователь использует формы с динамическими списками и работает RLS - SQL сервер практически не загружен, но прокрутка списка продолжает тормозить...
(53)
Обычно 300 пользователей её используют с 6 до 18, после этого идет запуск регламентных заданий, которые бы "убили" возможность нормально работать. Но при этом часов до 00:00 еще пользуются базой человек 10. Дальше снова регламентные задания и бэкапы.
Разработка конфигурации не прекращается ни на день. В следствии этого появляются "косяки", которые нужно устранять оперативно.
Вчера специально не обновляли ничего целый день, но в какой-то момент половина пользователей зависла на ровном месте, пришлось удалять их через консоль администрирования...
А ограничение доступа на уровне записей у вас используется ?
Не везде, но используются. Причем интересно то, что когда пользователь использует формы с динамическими списками и работает RLS - SQL сервер практически не загружен, но прокрутка списка продолжает тормозить...
(53)
В чем такая нужда обновлять динамически, база круглосуточно используется ?
Обычно 300 пользователей её используют с 6 до 18, после этого идет запуск регламентных заданий, которые бы "убили" возможность нормально работать. Но при этом часов до 00:00 еще пользуются базой человек 10. Дальше снова регламентные задания и бэкапы.
Разработка конфигурации не прекращается ни на день. В следствии этого появляются "косяки", которые нужно устранять оперативно.
Вчера специально не обновляли ничего целый день, но в какой-то момент половина пользователей зависла на ровном месте, пришлось удалять их через консоль администрирования...
(54) "Не везде, но используются. Причем интересно то, что когда пользователь использует формы с динамическими списками и работает RLS - SQL сервер практически не загружен, но прокрутка списка продолжает тормозить... "
Было такое. Очень сильно тормозили списки и открытие формы списка могла длится минут 5.
Там в шаблонах ограничений используется слишком много полей "Организации, подразделения, группыдоступапартнеров" и т.п. А нам по факту нужно было ограничивать только по подразделениям.
Решил вопрос написанием своих ролей в которых проверялся доступ только по подразделению - работа с документами и формами увеличилась в десятки раз.
Было такое. Очень сильно тормозили списки и открытие формы списка могла длится минут 5.
Там в шаблонах ограничений используется слишком много полей "Организации, подразделения, группыдоступапартнеров" и т.п. А нам по факту нужно было ограничивать только по подразделениям.
Решил вопрос написанием своих ролей в которых проверялся доступ только по подразделению - работа с документами и формами увеличилась в десятки раз.
(57) Прикольно. Никаких ожиданий на блокировках в Management Studio не видно? Сервер БД и приложений на одной железке/виртуалке (в том смысле, что данные мониторинга выше по очередям диска касались обоих)?
Из "быстрых заплаток" приходит в голову только закомментировать установку безопасного режима по разделителям, если разделение данных у вас не используется. Как минимум, станет понятно, причина это или следствие (начнет виснуть на чем-то другом) и появится новая инфа для размышлений.
Еще как вариант, внимательно пройтись по правилам разделения по разделителям (кнопка "состав" в свойствах разделителя). Может, что-то намудрили для новых/измененных объектов метаданных и платформа тупит на анализе правил разделения. Но первым делом проверить блокировки СУБД.
Из "быстрых заплаток" приходит в голову только закомментировать установку безопасного режима по разделителям, если разделение данных у вас не используется. Как минимум, станет понятно, причина это или следствие (начнет виснуть на чем-то другом) и появится новая инфа для размышлений.
Еще как вариант, внимательно пройтись по правилам разделения по разделителям (кнопка "состав" в свойствах разделителя). Может, что-то намудрили для новых/измененных объектов метаданных и платформа тупит на анализе правил разделения. Но первым делом проверить блокировки СУБД.
(59) К этому времени, в плане оптимизации и настроек, было сделано очень многое. Где-то пришлось принять факт поведения платформы и попытаться минимизировать вызов вещей приводящих к этому. Но остались явления, которые не поддаются анализу со стороны программиста 1С имеющего ограниченный доступ к физическому серверу. Лечатся пока полной перезагрузкой сервера. Перезагружаем его практически каждый день, когда "наступает момент тормозов".
Сегодня, например, я увидел как один из пользователей нарвался на управляемую блокировку регламентного задания по удалению помеченных объектов. Deadlock для него оказался фатальным, т.к. заблокировал документ, который остался заблокированным даже после того, как он прибил процесс клиента, сессия то осталась висеть. К слову это регламентное задание выполняется уже третьи сутки, судя по журналу что-то делает. Останавливать я его не хочу т.к. праздники единственное время, когда более менее можно провести какие-то долгие операции. А типовое удаление помеченных сделано достаточно топорно и при перезапуске будет пытаться искать ссылки на одни и те же объекты, заново снова неделю. Если бы был регистр с уже проверенными объектами и была возможность их перенести в самый конец обработки, то это бы упростило задачу...
Сегодня, например, я увидел как один из пользователей нарвался на управляемую блокировку регламентного задания по удалению помеченных объектов. Deadlock для него оказался фатальным, т.к. заблокировал документ, который остался заблокированным даже после того, как он прибил процесс клиента, сессия то осталась висеть. К слову это регламентное задание выполняется уже третьи сутки, судя по журналу что-то делает. Останавливать я его не хочу т.к. праздники единственное время, когда более менее можно провести какие-то долгие операции. А типовое удаление помеченных сделано достаточно топорно и при перезапуске будет пытаться искать ссылки на одни и те же объекты, заново снова неделю. Если бы был регистр с уже проверенными объектами и была возможность их перенести в самый конец обработки, то это бы упростило задачу...
(62) пробовал мониторить через ТЖ, но смысла в этом не много, т.к. подвисшую сессию легко вычислить через консоль администрирования, особенно, когда в колонке "Заблокировано упр" есть номер соединения которое выставило блокировку.
P.S.: анализ ТЖ за несколько месяцев показал, что явление взаимоблокировок - достаточно редкое. Всего несколько случаев.
P.S.: анализ ТЖ за несколько месяцев показал, что явление взаимоблокировок - достаточно редкое. Всего несколько случаев.
(60) Спасибо. Любопытная статья. Мы уже перестали без крайней необходимости делать динамические обновления, т.к. пришли к выводу, что этот механизм приводит к очень непредсказуемым последствиям, начиная от произвольного отключения пользователей, удалением у них пунктов навигации, невозможностью зайти в 1С вообще, и заканчивая дикими тормозами системы.
Кстати когда начал анализировать долгое получение констант в одной из них, связанной с динамическим обновлением наткнулся на список номеров сессий, которых в массиве было около 11000 штук. После её чистки, скорость её получения упала с 6 секунд до нескольких сотен миллисекунд. Сколько еще мусора может лежать в константах или пользовательских настройках одному Богу известно. И кстати чистка всех пользовательских настроек через механизм БСП в пользовательском режиме, к моему величайшему сожалению, не чистит все настройки. Приходится запускать "Инструменты Разработчика" и удалять настройки форм, отборы, параметры вариантов отчета, параметры печати - вручную. Я изучал код ERP, чтобы понять почему она не чистит все настройки пользователя, когда её просят об этом. Из логики там четко видно, что она удаляет только то о чем знает, и судя по всему, она даже не все собственные настройки знает.
Кстати когда начал анализировать долгое получение констант в одной из них, связанной с динамическим обновлением наткнулся на список номеров сессий, которых в массиве было около 11000 штук. После её чистки, скорость её получения упала с 6 секунд до нескольких сотен миллисекунд. Сколько еще мусора может лежать в константах или пользовательских настройках одному Богу известно. И кстати чистка всех пользовательских настроек через механизм БСП в пользовательском режиме, к моему величайшему сожалению, не чистит все настройки. Приходится запускать "Инструменты Разработчика" и удалять настройки форм, отборы, параметры вариантов отчета, параметры печати - вручную. Я изучал код ERP, чтобы понять почему она не чистит все настройки пользователя, когда её просят об этом. Из логики там четко видно, что она удаляет только то о чем знает, и судя по всему, она даже не все собственные настройки знает.
(63)
О каких сессиях в каком массиве речь? Чего чистили? Что-то я потерялся совсем.
А пользовательские настройки - да, в БСП с ними печаль. Неуниверсальненько. Тоже сталкивался. Или ИР или спец-обработки, которые на инфостарте встречаются.
(64) ""Заблокировано упр" - оооо! Как-то я эту колонку проморгал. Спасибо.
...список номеров сессий, которых в массиве было...
О каких сессиях в каком массиве речь? Чего чистили? Что-то я потерялся совсем.
А пользовательские настройки - да, в БСП с ними печаль. Неуниверсальненько. Тоже сталкивался. Или ИР или спец-обработки, которые на инфостарте встречаются.
(64) ""Заблокировано упр" - оооо! Как-то я эту колонку проморгал. Спасибо.
Коллеги, не вижу сообщения о решении проблемы, поэтому оставлю свои "пять копеек", надеюсь поможет.
У нас были похожие проблемы:
1. Проверить сеть нужно обязательно, а именно до сервера AD. Как раз момент входа в базу. Замена патчкорда внезапно решила проблему. При том отследить практически нереально, доступ есть, при обращении к доменному серверу ответ получает.
2. ssd не панацея, т.к. интерфейс sata (а у вас наверняка SATA, sas ssd уж больно дорогие) накладывает некоторые ограничения на количество одновременных потоков. Можно попробовать перевести на рейд из sas hdd.
3. Куча эко-режимов в биос включено по дефолту, при том у каждого вендора они свои. Выше обращали внимание на это но мало-ли.
У нас были похожие проблемы:
1. Проверить сеть нужно обязательно, а именно до сервера AD. Как раз момент входа в базу. Замена патчкорда внезапно решила проблему. При том отследить практически нереально, доступ есть, при обращении к доменному серверу ответ получает.
2. ssd не панацея, т.к. интерфейс sata (а у вас наверняка SATA, sas ssd уж больно дорогие) накладывает некоторые ограничения на количество одновременных потоков. Можно попробовать перевести на рейд из sas hdd.
3. Куча эко-режимов в биос включено по дефолту, при том у каждого вендора они свои. Выше обращали внимание на это но мало-ли.
(68) Проблема именно невидимых тормозов разрешилась сама, когда переехали на новый сервер, где нет PCI-E SSD. Думаю он и был причиной неадекватного поведения 1С.
Из побочных эффектов - работа с хранилищем конфигурации, динамическое обновление стало в 2-3 раза медленнее.
Кроме этого, где смогли, оптимизировали запросы, код проведения. В некоторых местах пришлось просто заблокировать элементы стандартных форм в ERP, чтобы пользователь не смог вызывать команды, которые приводят к плачевным последствиям, т.к. код ERP не был рассчитан на такое огромное количество данных.
И, конечно, добавили ОЗУ. Оказалось, что серверу 1С в наших условиях для комфортной работы нужно не менее: 100Гб RAM под 1С и 300Гб RAM под MSSQL. Плюс перезапуск агента 1С каждую ночь, утечек памяти много, подвисшие соединения, подвисшие блокировки и т.п частенько..
Сейчас основной проблемой стало отражение документов в рег.учете. Сплошные конфликты блокировок.
А вот с ЖР работать практически невозможно, несмотря на то, что мы его давно перевели в старый формат. Если попробовать отобрать именно по ссылке на объект, даже в пределах одного дня - фоновая задача виснет наглухо, так, что если даже удаляешь сессию в консоли администрирования, остается соединение, которое при удалении каждый раз появляется заново. Помогает только убийство rphost'ов...
Из побочных эффектов - работа с хранилищем конфигурации, динамическое обновление стало в 2-3 раза медленнее.
Кроме этого, где смогли, оптимизировали запросы, код проведения. В некоторых местах пришлось просто заблокировать элементы стандартных форм в ERP, чтобы пользователь не смог вызывать команды, которые приводят к плачевным последствиям, т.к. код ERP не был рассчитан на такое огромное количество данных.
И, конечно, добавили ОЗУ. Оказалось, что серверу 1С в наших условиях для комфортной работы нужно не менее: 100Гб RAM под 1С и 300Гб RAM под MSSQL. Плюс перезапуск агента 1С каждую ночь, утечек памяти много, подвисшие соединения, подвисшие блокировки и т.п частенько..
Сейчас основной проблемой стало отражение документов в рег.учете. Сплошные конфликты блокировок.
А вот с ЖР работать практически невозможно, несмотря на то, что мы его давно перевели в старый формат. Если попробовать отобрать именно по ссылке на объект, даже в пределах одного дня - фоновая задача виснет наглухо, так, что если даже удаляешь сессию в консоли администрирования, остается соединение, которое при удалении каждый раз появляется заново. Помогает только убийство rphost'ов...
"300 пользователей зашли и все висят после авторизации. Ждали 40 минут."
Была такая проблема из-за сервера лицензирования. Вообще программные лицензии зло, когда вставлен физический USB ключ, таких проблем не бывает.
Была такая проблема из-за сервера лицензирования. Вообще программные лицензии зло, когда вставлен физический USB ключ, таких проблем не бывает.
Наблюдал такую же проблему - всё висит, а ресурсы сервера не задействованы. По всем симптомам - проблема с диском, но диск вообще не загружен. Грешил на драйвер SSD гипервизора, но в итоге ничего не помогало, или помогало временно. Тоже решилось переездом на другой сервер, все проблемы как рукой сняло.
(73) Дело скорее не в самом диске, а как работаем с ним операционка. Для параллельной многопользовательской записи на диск существует понятие диспетчера очереди i/o, но в случае самых быстрых дисков типа nvme которые не относятся к классу enterprise эта самая очередь переключается на самую примитивную очередь типа fifo: там нет арбитража по приоритетам и объемам, диск по сути однопользовательский. В линуксе это можно перенастроить, правда в результате какой-нибудь CrystallDiskMark покажет снижение скорости записи раза в 1.5-2, но зато заработает в многопоточном режиме без фризов.
(74) Спасибо за полезную инфу, буду знать.
В моём случае система была на энтерпрайз-SSD, без рейда, на базе ESXi. Т.е. вряд ли это та самая проблема с десктопными SSD.
Немного помогло отключение vmw_ahci, т.е. вы правы, проблема скорее всего лежала не в дисках, а в гипервизоре.
Но полностью решилось после переезда на сервер с корпоративными nvme, которые (именно эта модель) с ESXi видимо работают более гладко. И переходу на ESXi 7, где работа с дисками была заметно улучшена, судя по тому, что и на другой машине совсем другой конфигурации на ESXi 7 тоже решило проблему с тормозами на SSD.
В моём случае система была на энтерпрайз-SSD, без рейда, на базе ESXi. Т.е. вряд ли это та самая проблема с десктопными SSD.
Немного помогло отключение vmw_ahci, т.е. вы правы, проблема скорее всего лежала не в дисках, а в гипервизоре.
Но полностью решилось после переезда на сервер с корпоративными nvme, которые (именно эта модель) с ESXi видимо работают более гладко. И переходу на ESXi 7, где работа с дисками была заметно улучшена, судя по тому, что и на другой машине совсем другой конфигурации на ESXi 7 тоже решило проблему с тормозами на SSD.
(76) ESXi он тоже на ядре линукса работает. Утверждать не берусь, но гипервизоры младше семерки они же довольно старые уже, проблема с драйверами новых моделей дисков у вас была налицо. Тем более что у ESXi для каждой версии свой список поддерживаемого оборудования, возможно для шестерки вашего диска просто не было.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот