Поиск узкого места при проведении по партиям
Добрый день
Внезапно заметно (2-3 раза) снизилось проведение партионного учёта в УПП. За квартал с прошлого проведения ничего в оборудовании сервера или настройках сервера 1с/SQL не менялось. Индексы реорганизовал, статистику обновил, процедурный кеш очистил, сервер ребутнул - без изменений. Ок, ищу каких ресурсов не хватает - очередь диска и с базой и с темпдб в районе 0,1, процессор даже при одновременно проведении и работе пользователей одно ядро не всегда на 100% загружено, остальные на уровне 10-20%. Т.е. вроде как и ресурсов достаточно и обслуживание базы сделано а производительность сильно пала.
Направьте пожалуйста что я упускаю, явно же есть какая то очевидная причина но я её в упор не замечаю.
Внезапно заметно (2-3 раза) снизилось проведение партионного учёта в УПП. За квартал с прошлого проведения ничего в оборудовании сервера или настройках сервера 1с/SQL не менялось. Индексы реорганизовал, статистику обновил, процедурный кеш очистил, сервер ребутнул - без изменений. Ок, ищу каких ресурсов не хватает - очередь диска и с базой и с темпдб в районе 0,1, процессор даже при одновременно проведении и работе пользователей одно ядро не всегда на 100% загружено, остальные на уровне 10-20%. Т.е. вроде как и ресурсов достаточно и обслуживание базы сделано а производительность сильно пала.
Направьте пожалуйста что я упускаю, явно же есть какая то очевидная причина но я её в упор не замечаю.
По теме из базы знаний
- Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3
- Средство поиска "узких мест" при проведении документов
- Методика оптимизации программного кода 1С: проведение документов
- Как кропотливая работа оказалась эффективнее энергичной атаки
- Распространенные ошибки разработчиков, приводящие к проблемам производительности
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Один важный вопрос: меняется ли время проведения в зависимости от общей нагрузки на СУБД?
Если меняется(в менее загруженное время скорость проведения увеличивается), то стоит настроить сбор ТЖ на события DBMSSQL и TLOCK, TTIMOUT) Готов помочь с настройкой ТЖ. По результатам сбора найти самые долгие запросы и ожидания на блокировках.
Если не меняется, то замером производительности посмотреть что в ТОПе, и точечно локализовать проблему. Может кто кто конфу поменял и после этого проблемы начались.
Если меняется(в менее загруженное время скорость проведения увеличивается), то стоит настроить сбор ТЖ на события DBMSSQL и TLOCK, TTIMOUT) Готов помочь с настройкой ТЖ. По результатам сбора найти самые долгие запросы и ожидания на блокировках.
Если не меняется, то замером производительности посмотреть что в ТОПе, и точечно локализовать проблему. Может кто кто конфу поменял и после этого проблемы начались.
(15) Нет, активность других пользователей значительно не влияет.
Как только допроведу месяцы сделаю замер и буду ловить топ времени.
Меня очень смущает что даже при работе пользователей SQL не хочет грузить больше одного ядра процессора. Это то одно то другое ядро но всё же на 100% загружено бывает только одно, другие в этот момент на уровне 2-3%. Не уверен на 100% но кажется даже проведение партионки параллелилось нагрузкой на несколько ядер.
Как только допроведу месяцы сделаю замер и буду ловить топ времени.
Меня очень смущает что даже при работе пользователей SQL не хочет грузить больше одного ядра процессора. Это то одно то другое ядро но всё же на 100% загружено бывает только одно, другие в этот момент на уровне 2-3%. Не уверен на 100% но кажется даже проведение партионки параллелилось нагрузкой на несколько ядер.
(17)Если организация одна, то сложно распараллелить партионку. Более того при распараллеливание наоборот могут возникнуть ожидания на блокировках. Напишите в личку, можем вместе посмотреть, ТЖ сразу настроить. Может еще конечно кто то с параметром max degree of parallelism поигрался, было например 0, а стало 1 и все тяжелые запросы на одном ядре, от сюда и разница. Правда одинес наоборот рекомендует по умолчанию 1 ставить. А если увеличивать параллельность то и порог распараллеливания повысить необходимо, но чувствую тут все проще должно быть. В параметрах информационной базы Время ожидания блокировки 20 сек. стоит?
(18) Партионка ок, согласен. От распараллеливания только проблемы можно получить. Но почему другие то пользователи прилипли на то же ядро ? Я ожидал что +- будет примерно так: партионка на одном ядре текущая работа пользователей на другом. max degree of parallelism всегда 1 по рекомендации с ITS стояло и стоит, но это же как я понимаю влияет на то будет ли параллелиться каждый отдельный конкретный запрос а не то что вообще весь поток запросов будет идти только последовательно. Время ожидания блокировки - да, 20.
За предложение посмотреть вместе большое спасибо. Попробую ещё запустить сервер в режиме отладки, пощупаю замер производительности и попробую вникнуть в SQL Profiler и планы запросов, если ничего не смогу найти - побеспокою вас. Я всё ещё уверен что это что то совсем на поверхности но я просто в упор не замечаю этого.
За предложение посмотреть вместе большое спасибо. Попробую ещё запустить сервер в режиме отладки, пощупаю замер производительности и попробую вникнуть в SQL Profiler и планы запросов, если ничего не смогу найти - побеспокою вас. Я всё ещё уверен что это что то совсем на поверхности но я просто в упор не замечаю этого.
(2) Так в том и дело что нет. я уже даже двинул последовательность и для пробы провёл один из старых месяцев. Раньше на месяц уходило 7-8 часов сейчас еле за сутки успевает. Понятно что база растёт но лавинообразного роста не было, прирост в пределах как и росла раньше.
(4) конфигурация значительно не менялась - пара печатных форм и то не факт, обновлений не ставилось, платформа та же.
Замер производительности не придумал как применить - прошлых данных у меня нет, покажет он мне что долго выполняется а что быстро но сравнить с тем как было и не стало ли долго то что раньше было мгновенно возможности же нет - прошлые месяца сейчас так же медленно проводятся
Замер производительности не придумал как применить - прошлых данных у меня нет, покажет он мне что долго выполняется а что быстро но сравнить с тем как было и не стало ли долго то что раньше было мгновенно возможности же нет - прошлые месяца сейчас так же медленно проводятся
(16) может перестали данные в память влезать. Пересчитайте итоги в ТиИ, актуализируйте их. Посмотрите ограничение памяти на скуле, добавьте ему памяти, проверьте.
Все эти аномалии типа вчера работало супер, а сегодня в два-три раза медленнее - они от преодоления какого-то рубежа: память, схема питания, изменение логики. Проц и диск тут мало влияют. Может появилась доп.нагрузка на сервере, может ребуилд и сжатие индекса нужно.
Все эти аномалии типа вчера работало супер, а сегодня в два-три раза медленнее - они от преодоления какого-то рубежа: память, схема питания, изменение логики. Проц и диск тут мало влияют. Может появилась доп.нагрузка на сервере, может ребуилд и сжатие индекса нужно.
(20) Памяти уже докинул скулю + 20%, изменения нет. Опять же если бы памяти не хватило он же бы начал свопить активно и я бы это увидел как активное чтение/запись на диск, так ведь ?
Полный ребилд индексов запланирован на ненагруженное время - выходные.
Понимаю что видимо перешагнул какой-то рубеж и не заметил сразу. а вот какой не понимаю.
Полный ребилд индексов запланирован на ненагруженное время - выходные.
Понимаю что видимо перешагнул какой-то рубеж и не заметил сразу. а вот какой не понимаю.
(22)
Обычно, рекомендации по установке границы использования памяти для SQL где-то в районе 1/3 и более от размера базы. Тут, как говорится, кашу маслом не испортишь (скул памятью). При этом должно остаться и для сервера 1С памяти хотя бы по 256 мегабайт на клиента (если клиентов очень мало - по 512 + 2048 метров на "всяк-чё").
Также может быть ситуация, когда копия базы гоняет какие-нить регламентные задания, что тоже может отъесть память на ненужные данные этой копии.
Вообще, в SQL Менеджер Студио есть мониторинг, в котором можно поглядеть выполняющиеся запросы. В профайлере можно собрать данные по длительным запросам - тоже достаточно просто делается (отбор по дюрейшн больше секунды, например), а дальше просто выбрать оттуда самые часто встречающиеся запросы, отсортировав по сумме времени и сгруппировав по первым 1024 символам текста запроса.
В общем, у 1С есть технология поиска подобных проблем, которой учат экспертов по тех.вопросам.
Опять же если бы памяти не хватило он же бы начал свопить активно и я бы это увидел как активное чтение/запись на диск, так ведь ?
Не так. В SQL память расходуется вся, которая доступна системе, если в настройках не прописано иное. Свопилась бы 1С, а SQL - он просто удалял бы из памяти те страницы, которые были прочитаны максимально давно, при этом он не лез бы в своп - в него лезла бы 1С.
Обычно, рекомендации по установке границы использования памяти для SQL где-то в районе 1/3 и более от размера базы. Тут, как говорится, кашу маслом не испортишь (скул памятью). При этом должно остаться и для сервера 1С памяти хотя бы по 256 мегабайт на клиента (если клиентов очень мало - по 512 + 2048 метров на "всяк-чё").
Также может быть ситуация, когда копия базы гоняет какие-нить регламентные задания, что тоже может отъесть память на ненужные данные этой копии.
Вообще, в SQL Менеджер Студио есть мониторинг, в котором можно поглядеть выполняющиеся запросы. В профайлере можно собрать данные по длительным запросам - тоже достаточно просто делается (отбор по дюрейшн больше секунды, например), а дальше просто выбрать оттуда самые часто встречающиеся запросы, отсортировав по сумме времени и сгруппировав по первым 1024 символам текста запроса.
В общем, у 1С есть технология поиска подобных проблем, которой учат экспертов по тех.вопросам.
(24) Тогда нехватка памяти звучит вполне похоже - не хватает что бы удержать все нужные для операции страницы и вынужден постоянно их читать из базы/темпдб. Это же не обязательно должно проявиться в очень активном общении с диском и в итоге упереться в очередь к дискам ? Даже если диски вполне справляются всё равно чтение с них будет на порядки медленнее чем если страницы уже в памяти. А есть какие-то варианты это подтвердить/опровергнуть ? ну например узнать что постоянно одни и те же страницы читаются из за того что не удалось их удержать в памяти ? Или как то ещё ?
Копии баз уже думал, всё вынес с сервера 1с, регламентные задания на боевой временно придушил.
Я уже понял что видимо путь лежит к профайлеру и анализа планов но пока на это не хватает знаний и понимания. Буду вникать и смотреть.
Копии баз уже думал, всё вынес с сервера 1с, регламентные задания на боевой временно придушил.
Я уже понял что видимо путь лежит к профайлеру и анализа планов но пока на это не хватает знаний и понимания. Буду вникать и смотреть.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот