Как посмотреть кто грузит сервер 1с
Недавно столкнулся с необычным случаем, у заказчика отвратительно работал сервер 1с, чтобы было понятно о чем идет речь, приведу такой пример — запуск толстого клиента мог занимать десяток минут. Когда измерили тестом Гилева, то результат был ниже худшего. Посмотрев ближайшие результаты замеров других пользователей, я понял, что это не единственный случай.
Речь не идет об оптимизации, когда надо поднять на 10-20% производительность, речь идет о поиске причин низкой производительности, и её устранению. Согласитесь это несколько разные вещи. На просторах интернета множество статей как раз о повышении производительности, которые ограничиваются только настройкой сервера 1с и (или) настройкой сервера баз данных. А вот статей, рассматривающих случаи низкой производительности, особенно если причин несколько, и эти причины находятся на разных уровнях, я не встречал.
Обычно администраторы бросаются смотреть результаты мониторинга. Тот случай, с которым я столкнулся, показывал практически нулевую загрузку процессора, наличие свободной ОЗУ, отсутствие очереди у сетевого интерфейса, и только очередь к диску показывала, что не все в порядке. Пришлось устроить проверку по полной программе, это, конечно, занимает много времени, требует исключения сервера из рабочего процесса, но зато дает результат. Возможно для кого-то подобный подход недопустим, более того, некоторые считают это непрофессиональным подходом, но им я ничем помочь не смогу.
Аппаратный уровень
Звучит банально, но именно с проверки работоспособности железа стоит начать. Дело в том, что можно только догадываться о проблемах с оборудованием, если смотреть на уровне операционной системы. В моем случае, не работал один из дисков в дисковом массиве. Как ни странно жесткий диск оказался исправным и, после водворения его на место, заработал, правда пришлось подождать некоторое время, пока не синхронизируются все данные (видать давно он был отключен). Если бы всё этим и закончилось, тогда бы и не было этой статьи. На всякий случай сервер подвергся аппаратному тестированию (стресс-тесты, тест памяти, физической проверки дисков и контроллеров), которые не выявили каких-либо проблем.
Уровень операционной системы
- привести в порядок файловую систему;
- отключить ненужные службы, удалить ненужные и, самое главное, вредоносные программы;
- проверить оптимальность настроек операционной системы.
- проверке логической структуры диска;
- удалении временных и ненужных файлов;
- дефрагментации файловой системы.
Уровень служб
В моем случае сервер 1с находился вместе с сервером баз данных MS SQL на одной машине, но аппаратная конфигурация сервера вполне обеспечивала их совместную деятельность, а вот настройки этих двух служб были совсем не оптимальными. Этим настройкам посвящено множество статей, например, эта, здесь мы сфокусируем внимание только на тех, что не требуют дополнительных вложений, например, приобретение жесткого диска.
Для сервера MS SQL в каждой базе были увеличены значения параметра авторасширения базы до 500 Мб, так как базы 1С являются быстрорастущими. Также был настроен ежедневный план обслуживания, в котором кроме создания дампа базы добавлено обновление статистики, очистка процедурного кэша и дефрагментация индексов. В моем случае, это заметно уменьшило количество операций записи. В качестве дополнительных мер можно порекомендовать еженедельно производить дефрагментацию базы и реорганизации индексов.
Для сервера 1С были изменены параметры «Количество ИБ на процесс» и «Количество соединений на процесс» рабочего сервера, первый получил значение 1, а второй 25. Подобные советы больше похожи на «танцы с бубном», но они дают результат. В рассматриваемом случае изменение этих параметров привело к значительному уменьшению операций чтения-записи на сервере, и он заработал в ожидаемом режиме. Тест Гилева также подтвердил прирост производительности.
Уровень баз
Сделав замеры под рабочей нагрузкой и после выхода пользователей, я столкнулся со странным результатом — под нагрузкой тест Гилева показывал лучшие результаты, чем при простое! Было также замечено огромное количество фоновых заданий выполняемых на тестовых базах. Тестовые базы использовались сисадминами для проведения различных тестовых задач. Я попросил удалить их — и все встало на свои места. Следует ли держать тестовые базы на рабочем сервере, решать конечно вам, но лучше для этого найти какое-то другое решение, например, использовать файловый вариант.
У одной из баз не удавалось уменьшить журнал транзакций, а у другой базы не пересоздавались индексы. Для обоих случаев есть одно простое и эффективное решение. Прежде чем его описать, следует уточнить, что здесь имеет место одинаковое наименование разных объектов: базы 1С и базы MS SQL, первые могут быть не базами MS SQL, а, например, базами PostgreSQL. В свою очередь вторые не обязательно будут базами для 1С. Исходя из этого резервные копии баз 1С (dt-файл) могут быть развернуты и на других СУБД, но ни кто не запрещает вам из этой же копии развернуть на MS SQL. Снимаем резервные копии баз 1С средствами 1С, после чего удалить 1С-базы из сервера 1С, а потом создать их вновь, залив содержимое из dt-файла.
Приведя все базы в порядок, мне уже не к чему было придраться: сервер работал ровно, дисковая подсистема работала в штатном режиме, пользователи радовались быстрой работе в 1с, администраторы удивлялись как теперь быстро проходят обновления.
Заключение
Если использовать только один уровень для поиска причин низкой производительности, то можно оставить без внимания причины, лежащие на других уровнях, то есть результат будет не достигнут. Приведенный пример наглядно показывает, что причин может быть несколько, и каждая из них может лежать на своем уровне. Надеюсь, что данный материал поможет кому-то побороть проблему низкой производительности 1С-сервера.
УТ 11. SQL экспресс.
На сервере крутится 2 базы, УТ 11 и БП.
БП вроде работает нормально. А вот УТ просто жутко тормозит.
Работает 5 пользователей.
Жуткие тормоза при создании и проведении документов.
В файловом варианте база летает.
Перезапуск агента сервера не помогает.
Временное облегчение приносит ТиИ базы.
Но это на сутки, а то и меньше.
(8) делать ТИИ ежедневно не вариант
(0) не настроены регламенты SQL, угадал ?
Так, совсем не понял.
Посмотрел сейчас в Скуль менеджере.
Там база весит 36 гигабайт о_0!
При этом работает. Хотя у экспресса же ограничение на 10 гигов.
Как такое возможно?
(12) Почему. Может и экспресс.
Просто у экспресса нет sql agent и регламенты надо выполнять снаружи, например батником по расписанию.
(11) Может это лог разросся.
(13) реиндексация, обновление статистики, очистка процедурного кэша.
(9) Мне казалось что у какого-то нового SQL Express есть Agent, я не уверен. Но sqlcmd есть в любом случае.
(10) Ну значит разбираться почему ТиИ помогает и делать это же но например средствами SQL.
(11) Что в данном случае называется словом база?
Сейчас вот сижу проверяю. И не понятные дела происходят.
То все тормозит жутко, то ни с того, ни с сего все начинает просто летать. Работает быстро как и должно быть.
Тормоза начинаются когда процесс sql отжирает полностью одно ядро. Как понять чем вызвано?
(15) в SQL менеджере, в свойствах "Размер" )))
(16) пиши тогда уже на какой операционке оно установлена и действительно ли там 64 бит у 1С-ного сервера. И где там устанавливают ограничения на число rphost
(17) Эххх
Я так сказать там пытаюсь разобраться за спасибо. По старой памяти.
так хочется по быстрому отделаться)))
SQL Server 2012 Express Edition — является бесплатной версией SQL Server, идеально подходящей для разработки и развёртывания в настольных системах, в веб и малых серверах приложений. Новой возможностью Express версии SQL Server 2012 является SQL Server Express LocalDB. Это облегченная версия Express, которая имеет все программные функции, запускается в пользовательском режиме, быстро устанавливается, не требует настройки и имеет низкие системные требования.
(2) Там стоит 0, процессы не перзапускаются, вообще на этой форме все по нулям и приоритет на производительности
(4) Не успел увидеть вопрос снят. Но мне когда-то админы утверждали, что частый ребут сервера - вреден. Даже раз в неделю не хотели делать.
(3) тогда другой вариант: кто-то запускает дикий жесткий внешний отчет (или встроенный отчет, но без отборов - за все года по всем аналитикам), который сжирает всю память в ноль.
(7) памяти 32 гига , 18 на SQL отдано, остальное рпхостам, в момент пиковой нагрузки было доступно еще 4 гига, проблем в нехватке памяти нет.
А по поводу перегрузки сервера каждый день, это было сделано для разгона юзеров, но не работало, после перегрузки сеансы снова восстанавливались, может еще здесь как то собака порылась. И остановка службы 1с батниками и запуск через час тоже не помогали. Я так и не понял почему такое происходит.
(10) Вот сейчас смотрю, бух записьвсего 1236794654 , спрашиваю что делала, говорит только платежки набивала.. и по памяти она рекордсмен 1989947775.
Врать не станет
ну это я уже смотрю сейчас всего (сеанс начать 3 часа назад), попробую в момент загрузки смотреть текущие значения, но уже смотрел не смог отловить кто и что причина.
"после перегрузки сеансы снова восстанавливались" - еслиуж перегружать, то перезагружать оба сервера (1С и SQL) Сервер SQL "восстанавливает" прерванные соединения. Имхо. У Вас действительно проблемы. не только с железом :)
(16) 8.3
(14) 1с и скл живут на одном сервере
И еще момент восстанавливали сеансы базы с толстыми клиентами, и сами базы в режиме совместимости с 8.2 8.1. Но это так отступление от темы, потому что это происходит и на другом сервере где проблем с пиковыми нагрузками нет.
Сейчас написана иб которая только и занимается тем что удаляет сеансы пользователей на кластерах, сейчас проблем с бэкапами нет. (И причина тоже не в ней, написана она была уже во время проблем с производительностью)
13. Стандартные платежки БП3
(18) Да, спс, я знаю - у Вас платформа 8.3.10.2639. У меня 8.3.11.3034 и сейчас сидят два десятка пользователей на одном(!) rphost-е сервера 1С - ЧЯДНТ?
Ну возможно просто проц. слабый, сервер такой себе в плане процессора. В среднем порядка 70 сеансов, проц XEON E3-1230 3.3 ГГЦ
Но блин иногда неделями же работает без проблем, и пиковая нагрузка проходит в течении 10-30 минут
(офф) Имхо, в 1С сложно угадать что не так пошло. Помню, было дело, поймал ошибку платформы, когда всю память сервер активно забивал в то время, когда в базе работали только рег.задания без активных пользователей.
(22) Там вообще по нулям, эта колонка мне знакома когда переводил с бп2 - бп3 там висели большие значения и сам перевод висел но сервер работал как надо.
Если у автора действительно rphostЫ, то по Диспетчеру задач на закладка "Подробности" можно подсмотреть идентификатор процесса, который грузит сервер, а в оснастке администрирования серверов 1С, в сеансах, можно посмотреть кто сидит на этом процессе, чем занят - журнал регистрации. Круг ссужается. Как вариант, имхо, интерес также вызывают те пользователи, которые грузят сервер, но в журнале регистрации действий не имеют записей в этот период - не исключено что они грузят сервер отчетами.
(27) Спасибо, буду пробовать.
Но вешает базу не один рпхост, нагрузка немного размазана по 2-3 процессам.
(32) тоже самое что и в (27) но уже доступно с учетки ИТС, спасибо
Сейчас посмотрел по "Время вызова общее" с утра максимальное значение 104.186 затем 84, 68, 24 (это с утра, примерно 4-5 часов).
В принципе узнал вещи которые не знал, попробую проанализировать.
(0) > под каждую базу создается свой рпхост
Зачем?
Этой фигнёй имеет смысл страдать в исключительных случаях в целях расследования проблем. Например, когда никак не удаётся вычислить, какая именно ИБ сбоит.
(4) > сервер перегружается каждую ночь
Зачем? Вам больше заняться нечем?
(8) > это было сделано для разгона юзеров
Зачем? Чем вам мешают работающие юзеры?
> остановка службы 1с батниками и запуск через час тоже не помогали
Это от того, что кому-то лень почитать документацию. Пример "правильного" батника от 1С (для 64-битного сервера, у которого папка кластера размещена по нетиповому пути "F:\srvinfo\reg_1541", а пользователь, от имени которого работает служба 1С называется Admin_1C):
set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-
64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
echo done stop %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
echo done clean temp %DATE% %TIME% >> %TEMP_PATH%\%LOG_FILE%
При необходимости в батник следует добавить еще остановку службы сервера хранилища и службу агента ЦКК.
Потом не забыть всё это хозяйство запустить. У 1С на ИТС есть соответствующий батничек для старта всех служб.
А вообще по сути дела.
Перестаньте маяться ерундой.
Настройте технологический журнал и счетчики производительности винды.
(35) Что дадут счетчики производительности винды, покажет что у меня проц на серваке загружен до 100%, я и так это знаю. Мои счетчики производительности в виде юзеров мне сразу сообщают об этом. Дальше то что?
Технологический журнал попробую включить посмотреть, но плохо себе представляю что там смотреть, пару раз всего пользовался когда искал ошибку.
А почему не создавать проц. под каждую иб, в этом есть что-то что может привести к проблемам?
(38) в (34) писал, это разве большие показатели для отсчета с утра. Да и база которая показывает масимум появилась уже после проблем с производительностью
Стандартный вызов при администрировании систем 1С – проблема отношений между процессором сервера (CPU) и рабочим процессом rphost.exe, который обслуживает клиентские обращения и взаимодействует с сервером базы данных. Нередко они становятся причиной перегрузок CPU, что приводит к замедлению и сбоям работы. Разбираемся, как выявлять такие случаи и что делать для их профилактики и устранения.
Начнём с того, что rphost представляет собой ключевое звено всей архитектуры 1С, забирая на себя большую аппаратную нагрузку. Процессов rphost может быть много по разным машинам внутри корпоративной системы 1C. При этом rphost.exe часто «съедает память» и перегружает процессор. К примеру, это может выглядеть так:
Дано
- сервер 1С: Wndows Server 2016 Standard, 32 Гб ОЗУ, 12-ядерный процессор 2.7 ГГц;
- платформа 1С — 8.3.15.1565 с настройками по умолчанию;
- 60 баз, лицензия платформы ПРОФ.
Проблема
Процессор загружен постоянно на 85-100% (и каждое ядро, и суммарно). Требуется выявить причину такой загрузки и разгрузить процессор.
Решение
Начинаем с самого простого и очевидного. Откроем диспетчер задач Windows, вкладку Details и отсортируем список процессов по колонке CPU.
Если видим один или несколько процессов rphost.exe в топе – значит, процессор загружен 1С. Если процессор загружен, значит какие-то задачи выполняются. А так как процессор загружен слишком часто, то задачи выполняются либо слишком долго, либо слишком быстро и часто.
Но что именно может суммарно выполняться настолько долго в 1С, что это становится проблемой? Находим топ суммарно длительных серверных вызовов. Для этого нам понадобится выполнить сбор технологического журнала (ТЖ). Это специальный механизм платформы 1С 8.3, который позволяет протоколировать все события, происходящие в системе, в том числе системные ошибки.
Настройка его сбора выглядит так:
Далее необходимо провести парсинг собранного для выявления возможных источников проблемы. В этом поможет следующий скрипт:
С помощью GitBash в директории ТЖ запускаем скрипт. Получаем следующий результат:
В топе оказались регламентные задания. Заходим в базы и проверяем периодичность каждого регламентного задания. Периодичность высокая.
1. Если в работе системы 1С компании есть период нерабочего времени, переносим время запуска на него.
2. В случае, когда нерабочего времени нет (система всегда работает), уточняем, пользуются ли пользователи полнотекстовым поиском. Если нет — отключаем регламентные задания. Если да — уточняем допустимый предел актуальности данных (например, на вчерашний день, двухчасовая актуальность). И меняем периодичность запуска соответственно.
3. Проблему это не решает, если пользователь отвечает, что порога актуальности быть не должно или он должен быть слишком мал, как в примере. Тогда полнотекстовый поиск требуется выполнять только по определённым таблицам, полям. В таком случае для остальных полей требуется отключить свойство использования полнотекстового поиска.
4. Наконец, самый сложный случай, когда полнотекстовый поиск требуется для всех полей, а данные меняются часто. Тогда для решения потребуется либо произвести увеличение количества ядер (и желательно их частоты), либо выполнить перенос сервиса полнотекстового поиска на отдельный сервер.
5. Также иногда проблему загрузки процессора решают довольно банальные шаги: перезагрузка сервера и обновление платформы. Работа с актуальными версиями платформы имеет смысл по многим причинам, одна из которых — постоянный поиск разработчиками путей по снижению системных требований для работы 1С.
Мы получим возможность отслеживать изменение параметров производительности сервера 1С в реальном масштабе времени с использованием сервиса RAS 1C, разбирать ситуации в прошлом, делать выводы и выполнять настройку. По факту мы можем анализировать эту информацию самостоятельно,а можем бонусом настроить бота-помощника Ларису, которая станет предупреждать об опасных и других критических ситуациях в различные мессенджеры. Видео-урок и ссылки ищите внизу статьи.
Сервис RAS может предоставлять информацию о состоянии производительности процессов, параметров работы пользователей (сеансы пользователей) и др. В качестве основных проблем выделим следующие задачи:
- Нагрузка, создаваемая пользователями относительно СУБД: "Время захвата СУБД" (db-proc-took) и "Очередь захвата СУБД" (количество сеансов пользователей, стоящих в очереди)
- Нагрузка, создаваемая пользователями относительно сервера 1С: "Время вызова текущее" (duration-current) и "Очередь пользователей по времени вызова" (количество сеансов пользователей, стоящих в очереди).
- Общее состояние серверов 1С и СУБД.
По данным 1C its выбранные в задаче параметры хорошо характеризуют "жизненные" показатели сервера, чуть более подробно про них расскажем в конце статьи. Обратите внимание, что интерпретация этих показателей зависит от конкретной ситуации, но в целом прослеживаются общие черты.
Подключим замеры счетчиков от сервиса RAS 1С!
Для выполнения данной процедуры мы должны использовать обработку подключения к службе RAS «МониторRAS_1C.epf», которую предварительно нужно скачать и загрузить в базу мониторинга (укажите размещение в разделе "Замеры").
1. Сначала создадим новый замер . Для этого перейдите в замеры и создайте замер под наименованием «Лариса наблюдает за RAS 1C» и укажите следующие параметры:
- глубина хранения 5-7 дней;
- тип замера - "произвольный";
- загрузка в реальном времени;
- обработка - «МониторRAS_1C.epf».
2. Настраиваем обработку замеров . Переходим в замеры, открываем дополнительные обработки и выбираем "Настройка 'Монитор RAS 1C'". Открываем форму настроек монитора и указываем следующие параметры и выполняем действия.
- замер - «Лариса наблюдает за RAS 1C»
- путь к серверу 1С и порт RAS сервера (если у вас не установлена служба RAS, то выполните ее установку прежде)
- выбираем кодировку файла (обычно "cp866")
- После настроек жмем кнопку получить список кластеров и в случае успеха у нас должны появиться данные, по крайней мере одна новая строка. Если у вас для кластера используется авторизация, тогда укажите имя пользователя и пароль.
- Далее устанавливаем флаг получать детальные записи (вкладка "Свойства/Корзина"). В рамках этого мы сможем получать историческую информацию о всех событиях. Если вам не нужны агрегирующие функции, но детальные записи списка хотите получать, то необходимо добавить в корзину любое свойство без выбора функции агрегации.
- Добавляем к агрегирующим функциям (вкладка "Свойства/Корзина") следующие параметры согласно таблице, ниже:
- Далее установим цветовую раскраску и граничные значения для показателей (вкладка "Цветовая индикация"), в рамках которых мы сможем просматривать на графике агрегации две дополнительные линии уровня и увидим раскраску в таблице данных соответствующую ситуациям находящимся в желтой и в красной зонах. Согласно таблице:
3. Выполняем тестовый замер . Для проверки выполнения замера нажимаем кнопку выполнить замер. В результате правильных настроек у нас с вами должны появиться записи в журнале событий замеров.
4. Подключаем в замере регламент .
- для регламентного задания обязательно указываем пользователя, у которого снят запрет на защиту опасных действий.
- время обновления рекомендуем установить в районе 60 секунд (120 секунд максимум)
5. Открываем обработку монитора и проверяем работу .
- Переходим в подсистему замеры и открываем дополнительные обработки;
- Находим "Монитор 1С" и запускаем;
- Выбираем замер и нажимаем обновить данные.
Отображение детальных записей монитора с цветовой индикацией и значениями агрегирующих функций.
Отображение на графике значений агрегирующих функций, с указанными уровнями ограничений желтый и красный.
Видео-урок.
Как это все использовать?
Приведем несколько примеров использования данной информации на практике, продолжаем:
а) Как узнать кто и что запускал? Какое фоновое задание крутилось или крутится сейчас?
В данном случае нам необходимо воспользоваться историей замера или текущей ситуацией монитора. Открываем список сеансов (sessions) и ищем "проблемного" пользователя и его номер сеанса:
Далее открываем рабочую базу, журнал регистрации и ставим отбор по номеру сеанса и отбор по периоду времени этого события
В результате у нас есть понятие что запускалось и какие действия выполнялись или выполняются сейчас.
б) Хорошо или плохо серверу? Кто у нас нагрузил сервер 1С? Кто у нас грузит сервер SQL?
Открываем монитор и начинаем анализировать данные. Можно сделать следующие выводы, что пользователь запустив какой-либо процесс (обработка/фоновое задание) может довольно серьезно снизить производительность базы 1С. На рисунке ниже показаны два графика загрузки процессора и роста счетчика "Захвачено СУБД", на которых прослеживается корреляция.
О чем говорят показатели:
"Захвачено СУБД" - содержит время соединение с СУБД с момента захвата в миллисекундах (у нас преобразовывается к секундам). Характеризует текущую нагрузку сервера СУБД. Чем больше значение и чем больше сумма по этому полю для всех пользователей (очередь захвачено СУБД), нагружен сервер и тем более ему становится хуже. К примеру, кто-то запустил сложный SQL запрос к базе данных.
"Время вызова (текущее)" - содержит интервал времени в миллисекундах (у нас преобразовывается к секундам), прошедший с момента начала обращения, в случае, если сеанс выполняет обращение к серверу 1С:Предприятия. Чем больше значение и чем больше сума по этому полю для всех пользователей (очередь время вызова), тем более нагружен сервер 1С и тем более ему становится хуже. К примеру, кто-то запустил пустой бесконечный цикл, серьезные вычисления.
Большой рост по обоим показателям (выше) - говорит о том, что сервер гарантированно идет на "посадку". К примеру, запускаем процедуру удаление помеченных объектов или замену дублей в рабочее время, посчитать себестоимость и т.п.
в) Оповещение через мессенджеры с помощью Ларисы и предсказание возможных проблем производительности .
Это тема отдельной статьи, но мы поясним основные моменты в кратком изложении.
- Зная значения счетчиков производительности 1С можно сделать некоторые логические выводы. К примеру, если "Захвачено СУБД" от 0 до 60 сек, это норма (low), если от 60 до 300 сек - уже желтый (medium) уровень, а вот если более 300 сек - совсем плохо (high).
- Обладая информацией о связанном поведении наборов можно сделать определенные логические суждения.
- Исходя из предыдущих суждений можно настроить оповещения при переходе из одного состояния в другое (FSM или HFSM). Т.е. если существует большое значение "Захвачено СУБД" и идет рост очереди пользователей, то значит ситуация усугубляется и пора бить в набад.
г) Анализ изменений параметров сервера или базы . Пример: Корректировка количества соединений на процесс. В начале рабочего дня в Москве у нас стали возникать проблемы производительности (недавно перешли на новую подверсию платформы), связанные с резким наплывом пользователей (+200 в течении 30-40 минут), которое потом через 1-2ч снижалось. В результате анализа графиков было установлено, что 1С с запаздыванием (20 минут) отрабатывало запуск новых процессов и в моменты запуска производительность достаточно сильно снижалась.
Графики количества запущенных процессов (rphost.exe) и очереди сеансов к серверу 1С Предприятие (день первый).
В результате было предложено уменьшить количество соединений на кластер на 30% (в совсем новой версии 1С уже появилась возможность заранее создавать резервные процессы). В результате нагрузки связанные с запуском хостов практически исчезли. Количество пользователей и интенсивность работы одинаковая в эти два дня.
Графики количества запущенных процессов (rphost.exe) и очереди сеансов к серверу 1С Предприятие (день второй после изменений настроек).
Читайте также: