Дикие тормоза в sql-версии ЗУП #312509

Установили ЗУП 2.5.5.4, платформа 8.1.9.54. Загрузили данные, пробуем начислить зарплату. База на 800 сотрудников. В файловом варианте ЗУП документ "Начисление зарплаты" рассчитывается секунд 10, и столько же проводится. Но почему-то в sql-варианте рассчитывается около минуты, а проводится минут 30. При этом на sql-сервере под 100% загружены процессоры. Это баг или я что-то не так настроил? Если на почти пустой базе (одни справочники фактически) таки тормоза, то что будет дальше?

54 - кривой релиз. До вас еще олени эти "новости" не довозили?

Проверь даты действия начислений. Кто-нибудь ляпнул вместо 2007 года 2707-й

Мы только что купили коробку - в ней оно и было(54 релиз). ИТС еще не оформили.. То есть, есть мнение что из-за релиза?

Действительно, версия 2.5.5.4 очень тормознутая по сравнению с предыдущими. Кажется, это будет продолжаться дальше. Сам движок 8.1 и в , частности, 8.1.9.57 пошустрее, чем 8.0. Но все съедает безобразное кодирование разработчиков.

Я в трауре.. ЗУП оказалась гораздо хуже, чем казалась. Да и по сравнению с ранними версиями - тоже. ЗЫ Такое чувство что к работе над ЗУП привлекли разработчиков ЗиКи (ненавижу!!!)

Хм, какие были разработчики тех и взяли)) Не думаю что Боря Нуралиев для ЗуП отбирал отдельную команду

Какой ужас - физлицо создается автоматически при создании сотрудника.. Это ж сколько дублей будет :((((

С физлицами, действительно, сделали что то новое. А чем плохо то, что "физлицо создается автоматически при создании сотрудника"?

Вообще, очень плохо когда автоматически, без отображения формы списка и без осознанности действий оператора что-то добавляется.. Очень высока вероятность, что оператор поленится открывать форму списка на предмет уже введенного такого же элемента. И получаются дубли, с которыми потом очень трудно справится.. По-моему, оператор(кадровик, расчетчик) должен осознавать последствия своих действий, а такие механизмы как в 2.5 этому препятствуют, скрывая последствия и вызывая проблемы в связи с этим.

Не знаю. мне кажется, это не большая проблема. Более существенным является то, что скорость катастрофически упала.

Экспериментально установил, что особые тормоза начинаются когда количество сотрудников в одном документе начисления зарплаты превышает 300-400. Так и придется наверное делать - рассчитывать по частям..

Экспериментально установили. Расчет 1700 сотрудников на версии 2.1 около 3 часов. После перевода этой версии на платформу 8.1 стало считаться около 20 минут. После перевода на платформе 8.1 с конфигурации 2.1 на конфигурацию 2.5 только один цех из 300 человек, примерно, стал считаться 40 минут. Чего они туда напихали для тормозов? Блин, кремлевские мечтатели.

"Чего они туда напихали для тормозов?" Почти наверняка какой-нибудь хреново оптимизируемый запрос, какой-нибудь джойн по неиндексированным полям.. А вот интересно, если нужные индексы вручную в sql добавить - быстродействие увеличится? Надо будет попробовать..

Угу, многие говорят что медленно стало. Есть мнение, что оставшиеся по наследству от 2.1 измерения регистров (которые в 2.5 стали называться УдалитьХХХХ), усугубляют проблему, т.к. в индексы-то они входят, и сервер не может эффективно подобрать индекс для прохода. Но это не проверялось, это просто предположение.

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

Настройки сервера по умолчанию. Проверялось на нескольких серверах. Суть в том, что один запрос выполняется очень долго "а если лень читать или думать, когда работаешь, то это наверное уже проблемы не программы" Пользователи не идеальны, и могут совершать ошибки. И совершают.. В этом смысле ЗиКа - образец того, как НЕ НАДО писать расчетные программы, потому что в ней исправление ошибок - каторга.

Профайлером sql вычислил, что очень-очень долго выполняется запрос --- exec sp_executesql N'SELECT DISTINCT #V8TblAli1_Q_000_T_001._Fld513RRef AS _sf_1RRef, _Reference84._Fld995RRef AS f_1, #V8TblAli1_Q_000_T_001._ActionPeriod AS _sf_2, #V8TblAli1_Q_000_T_001._Period AS f_2, #V8TblAli1_Q_000_T_001._APDateFrom AS f_3, #V8TblAli1_Q_000_T_001._APDateTill AS f_4, #V8TblAli3_Q_000_T_003._Period AS f_5, #V8TblAli3_Q_000_T_003._APDateFrom AS f_6, #V8TblAli3_Q_000_T_003._APDateTill AS f_7 FROM ( SELECT _CalcReg512_MAIN._Period AS _Period, _CalcReg512_MAIN._ActionPeriod AS _ActionPeriod, CASE WHEN _CalcRegActPer544_MAINACTPER._APDateFrom IS NULL ELSE _CalcRegActPer544_MAINACTPER._APDateFrom END AS _APDateFrom, CASE WHEN _CalcRegActPer544_MAINACTPER._APDateTill IS NULL ELSE _CalcRegActPer544_MAINACTPER._APDateTill END AS _APDateTill, _CalcReg512_MAIN._Fld513RRef AS _Fld513RRef FROM _CalcReg512 _CalcReg512_MAIN WITH(SERIALIZABLE) LEFT OUTER JOIN _CalcRegActPer544 _CalcRegActPer544_MAINACTPER WITH(SERIALIZABLE) ON _CalcReg512_MAIN._RecorderTRef = _CalcRegActPer544_MAINACTPER._RecorderTRef AND _CalcReg512_MAIN._RecorderRRef = _CalcRegActPer544_MAINACTPER._RecorderRRef AND _CalcReg512_MAIN._LineNo = _CalcRegActPer544_MAINACTPER._LineNo WHERE (_CalcRegActPer544_MAINACTPER._APDateFrom <> @P1 OR _CalcRegActPer544_MAINACTPER._APDateFrom IS NULL) AND _CalcReg512_MAIN._CalcKindRRef IN (SELECT _CalcKind2_Q_003_T_001._IDRRef AS _Q_003_F_000RRef FROM _CalcKind2 _CalcKind2_Q_003_T_001 WITH(REPEATABLEREAD) WHERE _CalcKind2_Q_003_T_001._Fld350 = @P2 AND NOT _CalcKind2_Q_003_T_001._Fld362RRef IN (@P3,@P4)) AND _CalcReg512_MAIN._Fld513RRef IN (SELECT DISTINCT _CalcReg512_Q_004_T_001._Fld513RRef AS _Q_004_F_000RRef FROM _CalcReg512 _CalcReg512_Q_004_T_001 WITH(SERIALIZABLE) WHERE _CalcReg512_Q_004_T_001._RecorderTRef = @P5 AND _CalcReg512_Q_004_T_001._RecorderRRef = @P6) AND _CalcReg512_MAIN._ActionPeriod IN (@P7) SELECT DISTINCT _CalcReg512_Q_001_T_001._Fld513RRef AS _Q_001_F_000RRef, _CalcReg512_Q_001_T_001._ActionPeriod AS _Q_001_F_001 FROM _CalcReg512 _CalcReg512_Q_001_T_001 WITH(SERIALIZABLE) WHERE _CalcReg512_Q_001_T_001._RecorderTRef = @P5 AND _CalcReg512_Q_001_T_001._RecorderRRef = @P6 ) #V8TblAli2_Q_000_T_002 ON #V8TblAli2_Q_000_T_002._Q_001_F_000RRef = #V8TblAli1_Q_000_T_001._Fld513RRef AND #V8TblAli2_Q_000_T_002._Q_001_F_001 = #V8TblAli1_Q_000_T_001._ActionPeriod LEFT OUTER JOIN ( SELECT _CalcReg512_MAIN._Period AS _Period, _CalcReg512_MAIN._CalcKindRRef AS _CalcKindRRef, _CalcReg512_MAIN._ActionPeriod AS _ActionPeriod, CASE WHEN _CalcRegActPer544_MAINACTPER._APDateFrom IS NULL ELSE _CalcRegActPer544_MAINACTPER._APDateFrom END AS _APDateFrom, CASE WHEN _CalcRegActPer544_MAINACTPER._APDateTill IS NULL ELSE _CalcRegActPer544_MAINACTPER._APDateTill END AS _APDateTill, _CalcReg512_MAIN._Storno AS _Storno, _CalcReg512_MAIN._Fld513RRef AS _Fld513RRef FROM _CalcReg512 _CalcReg512_MAIN WITH(SERIALIZABLE) LEFT OUTER JOIN _CalcRegActPer544 _CalcRegActPer544_MAINACTPER WITH(SERIALIZABLE) ON _CalcReg512_MAIN._RecorderTRef = _CalcRegActPer544_MAINACTPER._RecorderTRef AND _CalcReg512_MAIN._RecorderRRef = _CalcRegActPer544_MAINACTPER._RecorderRRef AND _CalcReg512_MAIN._LineNo = _CalcRegActPer544_MAINACTPER._LineNo WHERE (_CalcRegActPer544_MAINACTPER._APDateFrom <> @P1 OR _CalcRegActPer544_MAINACTPER._APDateFrom IS NULL) AND NOT _CalcReg512_MAIN._Storno = @P2 AND _CalcReg512_MAIN._CalcKindRRef IN (SELECT _CalcKind2_Q_005_T_001._IDRRef AS _Q_005_F_000RRef FROM _CalcKind2 _CalcKind2_Q_005_T_001 WITH(REPEATABLEREAD) WHERE _CalcKind2_Q_005_T_001._Fld350 = @P2 AND NOT _CalcKind2_Q_005_T_001._Fld362RRef IN (@P3,@P4)) AND _CalcReg512_MAIN._Fld513RRef IN (SELECT DISTINCT _CalcReg512_Q_006_T_001._Fld513RRef AS _Q_006_F_000RRef FROM _CalcReg512 _CalcReg512_Q_006_T_001 WITH(SERIALIZABLE) WHERE _CalcReg512_Q_006_T_001._RecorderTRef = @P5 AND _CalcReg512_Q_006_T_001._RecorderRRef = @P6) AND _CalcReg512_MAIN._ActionPeriod IN (@P7) ) #V8TblAli3_Q_000_T_003 ON #V8TblAli1_Q_000_T_001._Fld513RRef = #V8TblAli3_Q_000_T_003._Fld513RRef AND #V8TblAli1_Q_000_T_001._Period <= #V8TblAli3_Q_000_T_003._Period AND #V8TblAli1_Q_000_T_001._ActionPeriod = #V8TblAli3_Q_000_T_003._ActionPeriod AND #V8TblAli3_Q_000_T_003._APDateFrom < #V8TblAli1_Q_000_T_001._APDateTill AND #V8TblAli3_Q_000_T_003._APDateTill > #V8TblAli1_Q_000_T_001._APDateFrom AND NOT #V8TblAli3_Q_000_T_003._Storno = 0x01 AND #V8TblAli3_Q_000_T_003._CalcKindRRef IN (SELECT _CalcKind2_Q_002_T_001._IDRRef AS _Q_002_F_000RRef FROM _CalcKind2 _CalcKind2_Q_002_T_001 WITH(REPEATABLEREAD) WHERE _CalcKind2_Q_002_T_001._Fld350 = @P2 AND NOT _CalcKind2_Q_002_T_001._Fld362RRef IN (@P3,@P4)) LEFT OUTER JOIN _Reference84 WITH(REPEATABLEREAD) ORDER BY _sf_1RRef, _sf_2', N'@P1 datetime,@P2 varbinary,@P3 varbinary,@P4 varbinary,@P5 varbinary,@P6 varbinary,@P7 datetime', {ts '1753-01-01 00:00:00'}, 0x01, 0x81669BC89C87DE99422F62D0EE0BF916, 0x9BFC1BAFCA22A0F24670D6118D626226, 0x0000008B, 0xB7930016E6DA4B7F11DCAA16808F9999, {ts '2007-12-01 00:00:00'} --- Однако, попытка выполнить этот же самый запрос изолированно в query analizer привела к интересному эффекту - запрос выполнился за секунду. Что бы это значило?

кеширование sql наверное.

Кэширование и накопление статистики исключается. Проверялось на свежесозданной базе и свежезапущенном сервере.

Есть! Причина тормозов была в неудачных попытках sql-сервера распараллелить запрос. Вылечилось отключением распараллеливания запросов установкой "number of processors to use for parallel execution" в "use 1 processor".

Это настолько древняя особенность и рекомендация 1С, что про неё уже все забыли..

А я первый раз про такое слышу:)

а в MS SQL 2005 эта опция где прячется?

у, подругому названа max degree of parallelism

Некоторые забыли даже, что слышали :) Вот тут описано:

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

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

А что говорит план выполнения этого запроса? А сразу после выгрузки-загрузки из "dt" не тормозит?

В том то и дело, что если я этот запрос запускаю в query analizer, то он выполняется за секунду, даже после загрузки информационной базы. Проблема не в самом запросе, а в том, как он запускается на выполнение сервером 1с-предприятия.

Всё равно попробуйте постороить план выполнения запроса, может он что-то и прояснит.. А Вы уверены, что именно этот запрос тормозит?

Судя по трейсу - тормозит именно он. Могу картинку кинуть

Вам лень построить план выполнения запроса или Вы не знаете что это?

Да видел я его. А на что там смотреть, если в QA план этого запроса _очевидно_ не соответствует плану выполнения запроса из 1с? Я же писал уже - из QA запрос выполняется ЗА СЕКУНДУ! А как посмотреть план выполнения запроса при трейсе реальной работы в 1с?

Скиньте сюда этот план, мы тоже посмотрим.

В виде картинки? Или как его можно в другой форме посмотреть?

количество READS нереальное. если оно одинаковое на обоих серваках, значит смотри винты. а вообще давай ка ты описание железяк на серваках ПОЛНОСТЬЮ.

Диски ни при чем. По системному монитору "Обращений чтения с диска" нет, да и через process explorer это видно - грузится исключительно и только процессор. Наверное, параметр READS отражает чтение из кэша страниц. Что касается железок - вряд ли это так важно.. Одна "железка" - 2-процессорный XEON c raid10, другая - обычный комп на core2 duo и с обычным sata диском. Вот иллюстрация, с графиком загрузки при выполнении проведения документа.

ксеон какой серии? 5хх?

Нет, Xeon-A(Prestonia) 2.2 ГГц.

ну вот ты на собственной шкуре увидел преимещество архитектуры CORE

и планы дай да? который тормозит и который не тормозит

С этим я и не спорю, но тормоза явно не процессорно-зависимые. Скорее всего, проявляющийся глюк оптимизатора sql. На core тормоза такие же, разве что чуть побыстрее всё выполняется. Опять вернулись к тому, как "дать план" который тормозит, если тормозит он только при запуске из 1с?

скопируй ВСЕ проведение в QA - тормозить будет?

эээ... а где план этот посмотреть? в 2005

в студии

.2 Профайлер это умеет.

а дальше?

Дайте хотя бы план, к-ый не тормозит

А как? Это огромная картинка, не умещается на экране. Нарезать кусочками?

в текстовом виде?

Вот план в текстовом виде, "который не тормозит".

На первый взгляд все плохо, куча Nested Loops, в парочке которых до кучи ещё и Table Scan.

Надо разбираться зачем и в каких таблицах он делает Table Scan.

Table Spool Тож быстроты недобавляет.

давай кусок модуля проведения где этот запрос

Ну и варнинги NO STATS. Сбор статистик пробовали перед проведением?

Это еще разобраться надо.. никогда раньше отладкой sql не занимался :(

Попробовал postgre-sql на той же задаче - та же самая фигня. На этом же самом месте грузит процессор и тормозит. Ну.. что тут сделаешь? Значит, такие запросы создает восьмерка..

postgre-sql вообще отдельная тема.. Вообще не исключено, что есть ещё какой-то фактор, который Вы упустили, потому что есть ведь организации, у который и на SQL отлично проводится документ начисления.

галка автообноления статистики стоит?

Может, они не пробовали проводить одним документом расчет 800 человек? Я же писал, проблема возникает только если в табличной части больше 300 строк..

Да конечно, по умолчанию. Даже вручную пробовал sp_updatestats запускать..

давай план если меньше 300 строк

Автообновление не рулит

Можно пошагово - как это сделать?

запускаешь профайлер. запускаешь проведение. копируешь в QA запрос из профайлера, делаешь план, выкладываешь его

Вот "хороший план". В табличной части ~300 строк. Попробовал отключить автообновление, запустил sp_createstats, запустил проведение документа из 300 строк, запустил sp_updatestats, запустил проведение документа из 800 строк - провелся без тормозов. Однако.. Но где гарантия что в следующий раз updatestats не мотнет в другую сторону?

Просто запускайте сбор статистик по шедулеру каждые два часа, например, после сбора можно ещё фрипроцкэш.

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

Всё равно это как-то неправильно.. Если оно на пустой базе так тормозит, то что будет потом? С семеркой было как-то проще - тормоза были стабильными, но весьма предсказуемыми, если использовать переборы.