Конфликт блокировок при выполнении транзакции. #734302

Участилась проблема с блокировками. База большая УПП 1.3, пользователей около 70. Главбух постоянно предъявляет претензии. Описал ей, что причина либо в кривом запросе, либо нагрузке на сеть, либо в мощности сервера, либо в настройках SQL. Ко всему этому не имею доступа, т.к. есть админы и сопровожденец конфы. В мою задачу входит только работа с пользователями и дописание всего внешнего. Вопрос такой, подскажите, пожалуйста, я ничего не упустил? Я так понимаю, что прежде чем задавать такие вопросы мне, мне нужно как минимум передать права на администрирование SQL-сервера, чтобы начать с трассировок. Я прав?

Участилась проблема с блокировками. База большая УПП 1.3, пользователей около 70. Главбух постоянно предъявляет претензии. Описал ей, что причина либо в кривом запросе, либо нагрузке на сеть, либо в мощности сервера, либо в настройках SQL. Ко всему этому не имею доступа, т.к. есть админы и сопровожденец конфы. В мою задачу входит только работа с пользователями и дописание всего внешнего. Вопрос такой, подскажите, пожалуйста, я ничего не упустил? Я так понимаю, что прежде чем задавать такие вопросы мне, мне нужно как минимум передать права на администрирование SQL-сервера, чтобы начать с трассировок. Я прав?

+ передай ссылку админам и пусть они тебе результат отдадут...

Спасибо большое, подумал еще, что может проблему создавать то, что сервер на виртуалке.

вполне может, тогда тебе нужны счетчики гипервизора... особенно очередь к дискам... закажи у админов... зы права не обязательно просить, по тому как вместе с правами ты получишь и зону ответсвенности, а сейчас ты смело все валишь на админов и пусть они разгребают...

Спасибо, просто считается если 1С тормозит - это ко мне ))

РАУЗ, я надеюсь, включен?

Нет, партионка

А, ну тогда понятно... Или вы расчет себестоимости по ночам делаете?

Я не определял расчет себестоимости, есть более продвинутый человек, который занимался внедрением и занимается поддержкой. Я бухам и говорю - делайте в выходные ))

не правильно поставил себя в компании.... смело говори "тормозит не 1с а сервер и сеть, все вопросы к админам...", проси разделения зон ответствености... разделением должно стать четко описаные критерии того что тебе выделяют админы, например 1. на SQL сервере не менее 32 гиг физической (не выгружаемой гипервизором) памяти для SQL сервера 2. на SQL сервере очередь к дискам не более 0.1 сек и так далее... тогда лего определить чья эта проблемма...

"Его нужно выполнить в Мастерс" написано в , имеется ввиду БД Master?

Ветка мракобесия, занятно читать.

В той базе, о которой вчера говорили (15 активных пользователей) после перехода на РАУЗ забыли, что бывают блокировки. Перешли 4 года назад. Новые сотрудники вообще блокировки в глаза не видели и когда у кого-нибудь раз в год выскакивает - звонят мне с испугом "Это что такое?" :)

да

Спасибо!

результат запроса.

нормально это когда упирается в запись данных и лога, нормальные величины для этих операций от 5 до 10 %, у тебя их и в помине не видно, значит никакие танцы с дисками тебе ничего не ускорят.... идещь на и читаешь, оптимизируй настройки сети и сервера пока запись данных и лога хотя бы до 5% не дойдут...

главное вопрос: может ли кто-то кроме одинэсника (а у меня сомнения и в них) - проконтролировать ПРАВИЛЬНОСТь конечных цифр (именно правильность, а не правдоподобность)

Причем тут сеть и сервер? проблема явно в коде это же дедлоки, а не таймауты

Где написано про дедлоки? Через некоторое время вдруг окажется, что база на автоблокировках.. Регламенты на субд выполняются? Я бы посмотрел сначала: 2)недостающие/неиспользуемые индексы 3)рассчитаны ли итоги вообще (бывает и такое) 4)режим разделения итогов 3)полный пересчет итогов

Какой релиз УПП? ПолучитьДеревоПартий обновлена?

Спасибо, но это не показания сервера, это я у себя на машине сервер развернул и пробовал, прежде чем на сервере что-то запускать. Просто хочу ориентироваться немного в результатах тестирований.

1С:Управление строительной организацией, редакция 1.3 (1.3.61.3) "ПолучитьДеревоПартий обновлена?" - как узнать?

1) Выясняю, вернее пытаюсь )) 2) Пытаюсь выяснить. 3) Уверен, что рассчитаны. 4) Не в курсе. 5) Не имею права. Сначала хочу выяснить проблемы сети, сервера и SQL, потому, как думаю это проще пока, потом копать дальше.

если не имеете прав, почему тогда вообще этим занимаетесь?

Разделение идет, опытный программист сопровождает из франчи, а я на фикси - на подхвате.

Меряйте железо, если оно в порядке, то смотрите долгие запросы.

Ох, пытаюсь :)

нафига это нужно на локалке???? это нужно ТОЛЬКО на боевом сервере!!! при активно работающих пользователях!!!

Боязно запускать сходу запрос на сервере )

Читаю Вашу статью и вот еще нарыл

не сцы, я тыщу раз так делал! (наша раша) :)

:) Сегодня запущу на сервере, завтра скину результаты, спасибо!

Кстати, в воскресенье перенес tempdb на другой диск, отвел память на 9Гигов под SQL, параллелизм в 1 поставил(было 0), в базе авторасширение поставил 200 и 50 Мб. Вроде побыстрее стало, по отзывам.

в вопросах оптимизации НИКОГДА не ориентируйся на отзывы, только на конкретные цифры... это САМОЕ ГЛАВНОЕ В ОПТИМИЗАЦИИ!!!

Я понял, надо было что-то быстрее предпринимать. Сейчас по анализам запроса буду пока ориентироваться.

Садись два, вы явно не вкурсе

+ Отзыввы крайне важны, так как оптимизация делается не для мифических цифр, а для удовлетворения потребности Заказчика

это Вы не в курсе, что у людей "быстрее" зависит не от фактов а например от ПМ, или от того сколько времени до сдачи баланса и еще от миллиона причин. Любая оптимизация начинается с вопросов - что тормозит? - ОСВ за год - Сколько сейчас? - 10 мин - Сколько будет хорошо? - 30 сек при достижении результата в 30 сек оптимазацию следует прекратить не смотря на то, что жалобы останутся...

Давайте договоримся так, что все хорошо, если цифры статистики подтверждают мнение пользователей :)

нет ты не понял, пользователи будут орать при любых скоростях... (реже или чаще, но будут) почитай про SLA...

Сейчас они довольны, хотя я понимаю, что аппетиты растут и это не надолго. Спасибо, почитаю, прямыча читакой становлюсь :)

если кому-то интересно...

Результат запроса на сервере

+ XE_DISPATCHER_WAIT = 64,5% - означает, что много фоновых заданий?

"Происходит, если фоновый поток, который используется для сеансов расширенных событий, ожидает обработки буферов событий." я-бы подумал, что регламент статистистики на сервере скуля давно отвалился, то есть банально план запроса строится слишком неоптимально... или распаралеливание криво работает... посмотри для начала 1. когда обновлялась статистика? 2. часом скуль не на виртуалке?

может переиндексация или еще чего... короче показывай весь скулевский регламент...

1. Регламент по статистике делается ежедневно сейчас (Админ говорил, надо проверить). 2. Сервер SQL (только он) на виртуалке.

Сейчас попробую.

Не, не смогу сегодня, пароля нет на доступ и админ уехал. Завтра посмотрю, выложу.

>>>Сервер SQL (только он) на виртуалке. это очень серьезный момент, грамотно настроить можно, но я такого почти не встречал.... скуль собирает статистику и на основании этого строит план запросов и его распаралеливает, по идее все куски одного запроса при адекватной статистики не ждут друг друга а исполняются "к сроку". Если происходят внешние события (например гипервизор включает что-то и начинает один камень делить с другой виртуалкой) то весь запрос начинает ждать те кусочки запроса которые пришлись на этот камень.... там много заморочек и с памятью и с диском и с камнями...

опять начали про память на сервере, когда проблема блокировок?

Отложенное проведение спасет отца русской демократии.

Если диск с базой невиртуальный то нормально все

отложеное проведение - путь к минусам... путь конечно возможный, но больно много на нем кочек...

единственно возможный пусть с упп 1.3

ну или покупать промышленные ссд, чтоб кардинально сократить время записи

по сабжу, да и картина в целом похожа... автору советую списатся с автором указаного топа о результатах перехода на железный сервер...

При чем тут время записи, у автора XE_DISPATCHER_WAIT - 64.5%

Спасибо, с самого начала по отзывам говорил админам, что виртуалка - зло. Трудно будет перенести на обычный сервер?

Скорость увеличу - взаимоблокировок поменьше будет, так думаю. виртуальный сколько стоит такой SSD, примерно? И насколько увеличит скорость, если все же tempdb на него положить?

Спасибо, почитаю, если автор не будет против - спишусь.

при установке SSD резко увелится скорость фулскана, а поиска по индексу увеличится мало, по этому SSD рулит только для логов (при условии правильных индексов в 1с)

+ то есть SSD сделает кривые руки программиста 1с не такими видными народу... для нормальных баз SSD офигенного прироста не дает...

У нас УПП вся паханная перепаханная. Плюс строительный модуль от Раруса. SSD по 8 тысяч - это не то? Просто никогда не интересовался железом.

у меня были отрицательные опыты с SSD я конечно понимаю, что будущее за ними, но я не слежу за ними... придет эра массового внедрения SSD - въеду в тему :)

Там в 21 посте "на железной машине (а не на виртуалки) длину очереди к диску, если более 0.5с - то мало, если 5-10с - то афигительно мало" - как узнать длину очереди к диску? У меня память под SQL 9Гигов всего, а крутится Документооборот и УПП.

Вы про Апдекс, тогда тут вопросов нет, абсолютно согласен.

не путай, память на сервере скуль видит то, что ему отдано гипервизором, а гипервизор может имеет всего 1 гиг памяти а остально своп :) "железная машина" - это гипервизор, все замеры счетчиков винды нужно делать на нем а не на вируальной машине где стоит скуль

Своп - это на Линуксе? У меня Win Сервер 2008

Спасибо! Осталось разобраться с монитором производительности показания снимать.

Регламентные задания настроены, но как оказалось не выполнялись, т.к. был отключен SQL Agent.

бинго!!! ну давай теперь после выполнения рег заданий повторяй тест.... уверен результат будет совсем иным... статистику обновляй не реже чем раз в два часа... только лучше подождать пару дней, что-бы планы запросов оптимизировались в несколько итераций, а потом уже тест повторяй... да и про виртуализацию то-же не забывай :)

и все-же регламентные задания распиши какие и как настроены :)

Спасибо, буду пробовать. Какой интервал в замерах лучше ставить? И результаты за 8 минут, которые у меня, насколько показательны?

>>>>Разделение идет, опытный программист сопровождает из франчи, а я на фикси - на подхвате. теперь ты понимаешь какой это "опытный программист" ???

сейчас ничего не делай, дай время скулю несколько раз обновить свою статистику регламентыми заданиями, уверен после этого скорость увелится примерно в 2 раза... то есть мы нашли явную проблемму, нужно ее устранить и только потом смотреть дальше, это нужно, что-бы проблеммы не наслаивались друг на друга...

Раз в день обновление статистики и чистка кэша, раз в неделю дефрагментация индексов и раз в неделю реиндексация таблиц. Но я перенастрою, статистику и кэш на раз в два часа, дефрагментацию раз в сутки и реиндексацию раз в неделю. Не-не, он администрированием не занимается, ставил SQL наш генеральный директор и админ.

может лучше на ночь перенести

Понятно, спасибо, сегодня вечером настроим регламентные задания. Что на ночь перенести, какое задание?

все.

обновление статистики поставьте раз в час или два, не бойтесь тормозов не будет. дефрагментацию индексов ставь раз день, что-бы ночью шло. реиндексацию можно так оставить... в понедельник запусти опять мой скрипт.... больше ничего не делай пока ибо надо посмотреть результат...

Ок. Регламент по статистике и кэшу на работу системы почти не влияют, я читал рекомендации делать их почаще.

а и параллелизм сейчас поставь = 0, а то ты его в 1 вроде ставил?

Да, везде вроде рекомендуют, а был в 0. Еще вопрос перед реиндексацией таблиц желательно делать бэкап?

Я верну в ноль, но что это значит?

рекомендую ставить 1 для 7.7 (или для тех кто не умеет настраивать регламент скуля), для 8.х лучше ставить 0... реиндексация и бекап не как не связаны, даже если реиндексация завершится крахом и после краха сделаем бекап, он будет валидным... бекап связан со шринком, но ты шринк не делаешь в регламенте...

это значит, что скуль сам определяет степень палалелизма на основании статистики и плана запроса

еще совет - перегрузите сервер, для проверки что агент работает, а то опять отвалится поле апдейта очередного.... но это уже к админу :)

Хорошо, все сделаю, протестирую в понедельник и отпишусь.

скулю отдано 9 гигов? а объемы баз какие? если базы большие, то посмотрите счетчики SQL, может ему памяти мало

Две базы, скульные копии размером больше 100 Гигов.

Еще вопрос возник, а на какие базы регламент применять?

В смысле только на рабочие или на системные тоже?

на все... даже на тестовые, хуже не будет :) про память - разумеется мало (и наверняка она в своп у гипервизора уходит), но это будет видно чуть позже, по моим прикидкам у автора в понедельник будет в 2...3 раза быстрее все работать... а это уже не мало ....

Хотелось бы )) Кстати по блокировкам, может кому понадобится нашел такой скрипт [1C] SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED DECLARE @dbid AS smallint; use [test]; SET @dbid=DB_ID; /*кто кого*/ SELECT DB_NAME(pr1.dbid) AS 'DB'       ,pr1.spid AS 'ID жертвы'       ,RTRIM(pr1.loginame) AS 'Login жертвы'       ,pr2.spid AS 'ID виновника'       ,RTRIM(pr2.loginame) AS 'Login виновника'       ,pr1.program_name AS 'программа жертвы'       ,pr2.program_name AS 'программа виновника'       ,txt.[text] AS 'Запрос виновника' FROM   MASTER.dbo.sysprocesses pr1(NOLOCK)        JOIN MASTER.dbo.sysprocesses pr2(NOLOCK)             ON  (pr2.spid = pr1.blocked)        OUTER APPLY sys.[dm_exec_sql_text](pr2.[sql_handle]) AS txt WHERE  pr1.blocked <> 0 [1C] Теперь если появляются блокировки, смотрю кто блочит, звоню, спрашиваю, прошу приостановить работу по приоритету. Пока хоть так.

см. "Конфликт блокировок при выполнении транзакции" = Дедлок В данном случае повышение производительности не решит проблему, а только сделает вероятность ее возникновения меньше. Т.е. только отложит проблему на будщее