Захвачено субд 1с что это
Сегодня обнаружился непонятный "косяк" в документе, который несколько лет нормально функционирует (просто раньше внимания никто на это не обращал, т.к. проблем не было). Документ самописный, у него имеется три табличных части, в двух из которых ссылки на номенклатуру (конфигурация Управление торговлей 8.1), а в третьей ссылки на документы комплектации. Так вот, просто при открытии документа у пользователя, который открыл, в консоли сервера 1С в графе "Захвачено СУБД" начинают появляться цифры, и не просто появляться а увеличиваться с течением времени до тех пор, пока этот документ не будет закрыт (доводил в копии до 1,5 тыс.). Захваченные СУБД не очень полезны, т.к. естественным образом продуцируют блокировки транзакций (база на SQL), что приводит к ухудшению настроения пользователей и далее моего. Но никак понять не могу, как просто открытый документ способен на такое, не могут же быть причиной ссылки на др. документы в табл. части, да и почему число постоянно растет, непонятно. Может кто подсказать что по этому поводу?
запусти замер производительности, увидишь исполняемый в процессе код. Подвесили какую-нить гадость на обновление отображения, или обработчик ожидания и т.д.
1) Я же не китаец сидящий на берегу реки и ждущий труп врага. По делу желательно, потрындеть я и сам могу.
"Захвачено СУБД" - это просто продолжительность сессии на СУБД. К блокировкам никакого отношения не имеет. Обычно такое бывает из-за переменных формы/объекта типа МенеджерВТ.
т.е. судя по ты не знаешь, что колонка "Захвачено СУБД" означает, однако, уверен, что "именно что захватила сессия (что заблокировано ею)"? Ну, вот что в документации дословно указано: Захвачено СУБД длительность обращения к серверу баз данных на момент открытия диалога свойств. Отображается в том случае, если в момент открытия диалога свойств соединение выполняет обращение к базе данных.
я на практике просто заметил, что например при здоровенных обменах там значения зашкаливают и естественно блокировки. в какой документации кстати? не нашёл что-то. В любом случае - это не есть хорошо, и открытый документ не должен пораждать такое в ИБ
Понятно, что длительная обработка может на всё время работы держать открытым соединение с БД и если при этом она активно изменяет данные, то может порождать и блокировки. Но если просто держать соединение с БД (а для этого достаточно иметь живую переменную с типом МенеджерВТ), то никаких блокировок не будет. Т.е. если дело действительно в переменной МенеджерВТ, то можно забить на это.
Количество пользователей нашей основной базы данных активно увеличивается за счет слияния второстепенных баз. Динамика примерно такая: 2020 – 150, 2021 – 300, 2022 – 500 (план). Поэтому оптимизация и быстродействие для нас важны: при увеличении числа пользователей проблемы растут нелинейно. Одно время даже хотели заключить договор ЦКТП, но пока справляемся своими силами.
Был один случай..
.. участились ошибки блокировки СУБД.
Анализ типов блокировок на сервере СУБД (за пол-дня). Ожидания LCK _ M _ X , LCK _ M _ U занимают доминирующие позиции.
Что делать ?
3-4 Поиск блокировок по dmv
4-5 Причина блокировок - отсутствует подходящий индекс
5-8 План запроса, поиск запроса в 1С, используя logcfg
10-12 Заключение, контакты
Решил посмотреть в СУБД. В ован запрос
представление sys.dm_exec_requests п оказывает выполняемые запросы в реальном времени, оно содержит поле blocking_session_id которое указывает на блокирующую сессию. (Доступна
Как я уже говорил, у нас большая компания с развитой инфраструктурой. Физически невозможно иметь доступ ко всем серверам компании. Получение информации с сервера целевой СУБД — через системного администратора. Поэтому просматривать состояние базы данных в реальном времени с помощью динамических представлений было неудобно. Мы не знали - в какой момент происходит блокировка. Договорились, что системный администратор соберет extended events по описанию (Спасибо, Юрий Пермитин) но напрямую задачу решить не удалось — события блокировок в СУБД происходят настолько часто, что производительность сервера упала. Составил более подробное описание, с фильтрами по длительности.
События lock_timeout, фрагменты sql_text
1. DELETE FROM T1 FROM dbo._InfoRg18447 T1 WHERE (T1._Fld18454RRef = @P1) AND (T1._Fld1420 = @P2)
С помощью функции ПолучитьСтруктуруБазыДанных() нашел имя регистра и имя поля. Как вы догадываетесь, индекс поля отсутствует. Очень похоже на ситуацию из видео на минуте 7. Для поля поставил значение «индексировать», флаг «ведущее» использовать не стал: могут быть пустые значения. Кстати, до добавления индекса события lock_deadlock на таблице dbo._InfoRg18447 тоже происходили. Причина блокировок СУБД подробно описана в видео: отсутствует индекс, происходит сканирование (с захватом) всей таблицы в режиме исключительной блокировки. При этом управляемые блокировки не учитывают план запроса, блокируют по значениям конкретных полей, конфликта между ними не происходит.
2. UPDATE T1 SET _Description = @P1, …. FROM dbo._ScheduledJobs31390 T1 WHERE T1._ID = @P15 AND T1._Version = @P16
3. Было несколько ошибок блокировок, связанных с шиной обмена Datareon . При зависании службы шины, отслеживаемые события в 1С не записывались, создавали lock_timeout. Эта ситуация была исправлена без моего участия.
События lock_escalation
Иногда происходит эскалация при работе с ценами по регистру «Цены номенклатуры» и табличной части документа «Установка цен». Документы больше 5000 строк табличной части, решение этой проблемы лежит в области организации процессов.
Итоги работы
Стало заметно лучше. Ниже анализ ожиданий на сервере СУБД за неделю, суммарная длительность ожиданий LCK _ M _ X , LCK _ M _ U составляет 18 минут, до начала работ суммарная длительность ожиданий могла быть до 2 часов в день.
P.S. Чтобы счастье было полным
настроил технологический журнал для dbmslocks (важно, что события собираются без отборов).
Просто нужно использовать внешний поиск, например в строке Яндекса пишем site:https://its.1c.ru/ "dbmslocks"
lka=‘1’ поток является источником блокировки.
lkp=‘1’ поток является жертвой блокировки.
lkpid номер запроса к СУБД, «кто кого заблокировал» (только для потока-жертвы блокировки).
lkaid список номеров запросов к СУБД, «кто кого заблокировал» (только для потока-источника блокировки).
lksrc номер соединения источника блокировки, если поток является жертвой.
lkpto время в секундах, прошедшее с момента обнаружения, что поток является жертвой.
lkato время в секундах, прошедшее с момента обнаружения, что поток является источником блокировок.
Файлы по часам получились более 6 Гб, поэтому для выделения информации использовал bash:
Для строчек, содержащих lkaid / lkpid выбрать 20 строк сверху и снизу, поместить в файл. Ниже пример: два источника, одна жертва. Ожидание длилось 0,84 секунды, прежде чем команда ПланыОбмена.ЗарегистрироватьИзменения() дождалась освобождения ресурса и установила блокировку.
По предварительной оценке, на подобных ожиданиях мы теряем 1 секунду в час. Эта информация интересная, вернусь к ней позже.
Приведем ответы на частые вопросы, связанные с производительностью «1С:Документооборота».
Вопрос 1
Есть ли в «1С:Документообороте» оценка производительности?
В «1С:Документообороте» версии КОРП и ДГУ есть встроенная оценка производительности. Рекомендуется включить ее перед началом работы пользователей в программе: Настройка и администрирование — Настройка программы — Общие настройки — Выполнять замеры производительности.
После этого программа автоматически будет замерять время выполнения ключевых операций: создание документа, запуск процесса, открытие и создание файла, выполнение задачи и другие. Эталонное время ключевых операций приведено здесь. На основе полученных данных удобно вовремя обнаружить снижение производительности программы и провести первичный анализ.
Чтобы увидеть средние показатели за определенный период, выполните команду Время выполнения ключевых операций в меню раздела Настройка и администрирование.
Анализ и контроль производительности можно также вести по методике APDEX — команда Оценка производительности в меню раздела Настройка и администрирование.
Вопрос 2
С чего начать проверку при замедлении работы программы?
При замедлении работы программы рекомендуется проверить формат журнала регистрации. Также эту проверку рекомендуется проводить после обновления платформы «1С:Предприятия» на версию 8.3.7 или после создания информационной базы с нуля.
Если в каталоге 1Cv8Log есть файл 1Cv8.lgd, то нужно изменить формат журнала регистрации. Порядок замены:
- остановите сервер «1С:Предприятия»;
- удалите все файлы в каталоге 1Cv8Log. По умолчанию каталог расположен C:\Users\USR1CV8\AppData\Local\1C\1Cv82\reg_1541\;
- создайте в папке 1Cv8Log пустой файл 1Cv8.lgf;
- снова запустите сервер «1С:Предприятия».
Вопрос 3
Что делать, если у рядовых пользователей ключевые операции выполняются более 15 секунд? По прошествии этого времени операции выполняются без ошибок. При входе в программу под Администратором задержек нет. Все рекомендованные настройки СУБД и сервера «1С:Предприятие» выполнены.
Во-первых, проверьте версию конфигурации. Если установлена версия 1.4.xx, необходимо перейти на версию 2.0, куда включено много доработок по быстродействию.
- Запустите сервер «1С:Предприятия» с ключом debug. Обратите внимание: при этом работа сервера значительно замедлится, поэтому такой запуск рекомендуется проводить только в нерабочее время.
- В конфигураторе включите замер производительности.
- Выполните операцию под тем пользователем, у которого зафиксирована проблема.
- В замерах производительности посмотрите, на что ушло основное время;
- Сохраните замер в файл .pff и пришлите его на линию тех поддержки «Фирмы 1С».
Дополнительно к данным, которые запрашивает тех поддержка «Фирмы 1С», необходимо прислать подробное описание проблемной ситуации и информацию о том, типовая ли конфигурация или доработанная. Например, «16 марта 2016 года с 12:00 у пользователя Иванов И.И. карточка внутреннего документа открывается 30 секунд. Конфигурация на поддержке».
Если проблема воспроизводится не в 100% случаев:
- Настройте технологический журнал на сервере «1С:Предприятие» (скачать готовые настройки logcfg.xml).
Если технологический журнал уже настроен, то к уже имеющимся настройкам нужно добавить новые из скачанного файла. Файл logcfg.xml обычно распроложен тут: C:\Program Files (x86)\1cv8\conf (для 32-битного сервера «1С:Предприятие»); C:\Program Files\1cv8\conf (для 64-битного сервера «1С:Предприятие»). - Дождитесь повторного воспроизведения проблемы.
- Пришлите данные технологического журнала на линию тех поддержки «Фирмы 1С».
Дополнительно к запрашиваемым данным нужно подробно описать один! конкретный случай воспроизведения с точным временем: Например, «У пользователя Петров И.В. карточка внутреннего документа открывалась 30 секунд. Время: 16 марта 2016 г. в 14:45:50.
Вопрос 4
Что делать, если зафиксированы периодические замедления работы, например, раз в минуту?
Проверьте версию конфигурации. Если это версия 2.0.9 — 2.0.13 включительно, то обновитесь на более свежую или отключите автоматическую проверку контрагентов по ЕГРН (Настройка и администрирование — Настройки программы — Контрагенты — Автоматически проверять контрагентов по ЕГРН).
Вопрос 5
Что делать, если операция длится более 20 секунд, после чего выдает ошибку «Превышено максимальное время ожидания предоставления блокировки»? Как правило, ошибка проявляется у всех пользователей.
- В консоли администратора откройте список Сеансы. Установите сортировку по колонке Захвачено СУБД.
- Самый большой показатель будет на первом месте. Если он превышает значение 20 секунд, запишите номер сеанса из соответствующей колонки. Это понадобится для дальнейшего анализа.
- Отключите проблемный сеанс с помощью команды контекстного меню Del.
- Найдите в журнале регистрации первую запись, соответствующую этому сеансу. Если это регламентное задание, запишите его название. Оно потребуется для отправки на линию технической поддержки при регулярном воспроизведении проблемы.
(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С «Центр управления производительностью» (ЦУП) — инструмент мониторинга и анализа производительности клиент-серверных информационных систем на платформе «1С:Предприятие 8». ЦУП предназначен для оценки производительности системы, сбора подробной технической информации об
имеющихся «узких местах» и анализа этой информации с целью дальнейшей оптимизации.
В отличие от "Тест-центра" ЦУП не встраивается в исследуемую базу, а представляет собой самостоятельную конфигурацию которую нужно развернуть как отдельную информационную базу. И, само собой, с помощью ЦУПа можно мониторить и анализировать неограниченное число баз. Сразу упомяну и о минусах ЦУПа: кроме немалой стоимости продукта могут быть сложности с его настройкой. Как правило сложности связаны с отсутствием необходимых прав. И в некоторых тяжелых случаях согласование назначения необходимых прав может растянутся на длительное время. Вообще редких ошибок при работе с ЦУП довольно много подробнее тут (они даже собраны в отдельную методичку), но зато в ЦУПе есть отличная инструкция по настройке и пошаговый мастер настройки. И если на каком-то этапе мастера возникла ошибка, то необходимо внимательно прочитать соответсвующий пункт инструкции и внести необходимые изменения.
Как уже говорилось ЦУП -это инструмент для мониторинга и анализа производительности, но естественно сам ЦУП ни коим образом не исправляет выявленные ошибки.
Оперативные показатели можно анализировать в режиме онлайн. К ним относятся например (Количество выполняемых запросов, Суммарное время выполняемых запросов, Максимальное время выполнения запросов, Суммарное время ожидания на блокировках СУБД и 1С, Количество взаимоблокировок, количество таймаутов и т.д).
Аналитических показателей всего 3 (Анализ запросов, анализ взаимоблокировок и анализ ожиданий на блокировках). Для анализа аналитических показателей предназначен сценарий "Просмотр".
1) Полноценная работа с ЦУП возможна только с MS SQL в других случаях он будет бесполезен. Учтите это при покупке).
3) Если конфигурация исследуемая конфигурация работает в автоматическом режиме, то ЦУП не всегда может определить гранулярность и режим блокировки.
4) Оперативные показатели ЦУП собирает путем опрашивания консоли кластера с заданным промежутком времени(по умолчанию раз в 15 сек) и это не оказывает существенной нагрузки на сервер, поэтому включенными они могут быть сколь угодно. Иначе дело обстоит с аналитическими показателями. Информация получается считыванием логов технологического журнала и оказывает серьезную нагрузку на сервер, поэтому рекомендуется включать сбор информации примерно на 15 минут в период пиковой нагрузки.Чем дольше данные собираются тем дольше они затем будут анализироваться. Одна из ошибок почему аналитические данные не анализируются это то что в папке conf уже находится файл logcfg.xml. Решение элементарное -удалить или перенести файл в другое место.
5) При анализе аналитических показателей ЦУП не всегда может точно определить виновника блокировки, в таком случае будет надпись "Предположение", если ЦУП уверен то надпись "Точные данные".
7) Показатели "Количество таймаутов" и количество взаимоблокировок" распространяются не на исследуемую базу а на весь SQL сервер. Таким образом если у Вас на сервере несколько работающих баз, то обнаружив что показатель "Количество таймаутов" стал >0 не считайте что это 100% таймаут исследуемой базы.
Читайте также: