Ночи доброй.
Пока не забыл - впилил удаление движений документов при перепроведении (которые как ни странно занимают почти 50% времени) в Фоновых задачах (в 4 фоновых пока)

Время с фоновыми (холодное/горячее) 79 886/19 148 мсек
Время без фоновых(холодное/горячее) 67 154/20 676 мсек

mssql2008r2 32x сервер 1С 8.2.15
КА немного попиленная, все регламенты выполнены, тачанка норм, но не серверная, документ - РТИУ в 520 строк, партионный учет включен.

Бида...

(37) во втором ожидание должно быть, а не дедлок

Просто немного не понял (26)...
Поделил на 4 части с балансировкой (собрал статистику в отдельный РС), получилось (31).

Получилось при одном пользователе.
Может при толпе пользователей будет другой результат?

(39) ну так это и тормозить будет. В итоге прибыли никакой.

Странно что вариант 1 тормознее.

(38) тогда подчиненность регистратору поеет
(39) хоть горшком назови

(40) не будет.

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

только вот если скуль загружен чрезмерно - эффекта не будет

(44) Откуда?

(45) Все упирается в диск.

(44) ну, там удаление, УБ от этого в большой степени спасают
(46)  может

(44) Не путай, тут другое

(46) если в фоновое задание закинуть регистры в неправильном порядке и там все в одной транзакции пишется

(48) УБ для другого.

(50) Там УДАЛЕНИЕ записей в регистрах. Какая разница, какой порядок?

(52) +100500

(53) + И транзакция другая , надеюсь )))

(54) транзакция в каждом задании своя же

Сегодня еще потестю, посмотрю профайлером какие там запросы тяжелые.

(55) Именно, тогда влияния порядка нет.

(56) Имхо решается настройкой скуля.

(52) а какая разница, запись или удаление? все равно ставится блокировка на отбор. Я вообще не люблю диспуты по поводу дедлоков, уж больно дохера ньюансов

(57) речь про транзакцию фонового задания в котором несколько регистров пишутся

Кстати, стоп, насчет транзакций...

Хотя нет, мы же ждем их завершения, все нормально.

(61) Только не говори, что она у тебя одна на все)))

(60) На каждый регистр должна быть своя транзакция. Имхо.

откат транзакции проведения откатит очистку? я чот сомневаюсь

Мне непонятно, откуда у Fragster-а выигрыш при параллельном проведении.
Я то думал, что тупит сервер 1С ну скажем 25% времени хотя бы и в несколько потоков он это быстрее разрулит, а оказалось, что он и не при чем.
Надо смотреть duration всех запросов в Скуле и сравнивать с временем выполнения (28).

(65) Очистка и запись должны быть в одной транзакции.

если загрузка сервера на 100%, то общее время выполнения увеличится на накладные расходы. У меня на фоновое задание с Процедура Тест() Экспорт
   А=1;
КонецПроцедуры
уходит 2-3 секунды (8.1, в 8.2 может быть быстрее).
если же загрузка сервера меньше 100%, то фоновыми заданиями мы сможем выжать загрузку больше, чем в 1 поток, вот за счет чего выигрыш происходит

(0) какая версия платформы?

(68) Сервер имеется в виду МС Скуль?

(69) Писатель )))

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

(68) У меня SQL уперся в диск. Процессора ему хватает.

(70) любой разделяемый ресурс, скажем так. диск скуля, проц, любой, во что упирается - если 100%, то фоновые прироста не дадут

Сегодня попробую свой любимый RAM, если хватить.
Все попробую !

(74) Ну это аксимо не требующая оглашения )))). И так понятно что если железо напряглось до предела, то не получишь ощутимого роста.

(74)+ если без фоновых загрузка 50%, то с фоновыми больше чем в 2 раза быстрее не получится (реально 1,5-1,7 из-за накладных расходов). если же время накладных расходов сопоставимо со временем выполнения - то смысла вообще мало

(66) Снимай активность у набор записей, а фоновым удаляй такие наборы записей.

(78) Что это даст?

на самом деле при перепроведении я уходил от двойной записи движений

(79) ничего

(80)+ просто при контроле остатков вычитал текущие движения

(79) Ничего. Так как запись новых "записей" надо сделать.

(82) в перспективе же надо делать как в УТ 11 - запись, а потом смотреть "не нафигачили ли чего"

(80) И это правильно. Оперативное проведение?

(84)+но в том спагетти, которое мне досталось - слишком много переделывать

(85) не всегда

(84) Вопрос (85) к этому и ведет )))

(87) Вообще самым нормальным решением вообще не проверять остатки, как Рауз частенько делает. А потом в конце месяца их вывести.

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

ну чего, какие выводы/действия у (0)? интересно же

(91) Буду мерить.

Посмотрю запросы в SQL, посмотрю их duration, перенесу базу в RAM, гляну, перенесу tempDB обратно на диск, померяю.

Принесу базу на работу, померяю на 15000 дисках.

Буду тупо тестить, тут нечего думать!

Простая эмпирика, аналитика облажалась.

(93) а убрать запись пустых наборов при перепроведении?

(94) в "пустых" - в смысле очистка из БД наборов, которые потом повторно записываются

Старики (например Епрст) смотрят и смеются ))) - "Все реализовано"

(94) Я счаст нубство скажу - а зачем 1С это сделала?

3 варианта было, так

1) вариант - давно, у дока стояло свойство "Удалять движения автоматически" и все делалось автоматом.
2) вариант - теперишный, у дока стоит свойство "Не удалять движение автоматически" - имеем текущую ситуацию
3) вариант - у дока стоит свойство "Не удалять движение автоматически", но движения предварительно не удаляются, а остатки считаются за минусом движений текущего перепроводимого документа - вариант УТ11

Поправьте меня, если не прав, и почему 1С остановилась на 2 варианте, перейдя на него с 1-ого и не доведя до 3-его?

(97) Ут 11 по другому работает.

А вопрос так и не понял tt

(98) Значит я ошибся.

100 (100)

Провокатор

(97) в УТ - движения не удаляются, записываются новые, потом контроль остатков. твой вариант (3) - это в моем наследстве.

(102)+ фиговый вариант непрозрачный. но распрямить пока не доходят руки

(102) Ну немного ошибся я :-)

Почему 1С отошла от варианта 1 и пришла к 2 в УПП и КА ?

(105) Блокировки.

(106) + Где то даже на партнерском форуме была темка, но давно.

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

ЕМНИП

(109) Мне кажется с нами разговаривает другой H A D G E H O G s, старого и умного кто то испугал и он ушел !)

(108) да вроде при записи пустого набора должны блокироваться записи по измерениям в удаляемых записях

+(111) в управляемых блокировках до субд может не дойти даже дело

(110) Я всегда таким был.

Просто притворялся умным.

(97)
а) если стоит удалять автоматически движения, то по всем регистрам где документ является регистратором делается запись пустого набора.
Если же вдруг документ по какому то регистру движения не имел, то из за отсутвия индекса (или чего там) блокируется вся таблица
в УПП 1.2 это херню исправли стащив решение у ИТРПов ,
теперь предварительно проверяется наличие движений в регистре и если их там нет, то движений не делается

б) третий вариант возник из за того, что франчи доколебали разработчиков в связи с чем в УПП 1.2 появилась галочка в параметрах учета, не очищать регистры при записи :) со списком исключающих документов...
т.е. что бы не делать
запись пустого набора (очистка движений) + запись нового набора (проведение)
теперь делается сразу проведение (т.е. новые движения замещают старые) + пишется пустой набор если движения были, а теперь их нет

но такой алгоритм возможнен, только когда документ не смотрит остатки(!) поэтому в конфе прописан список исключений
в связи с чем возник вариант
(в)

(114) у тебя просто иголки молодые и короткие :)

(111) ставиться отбор по регистратору..
а в регистре такого индекса нет... неожиданно да? :)

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

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

(120) в УТ11 регистр блокируется в момент записи и остается заблокированным до окончания проведения, контроль остатков смотрит ТОЛЬКО на наличие ОТРИЦАТЕЛЬНЫХ остатков, при перепроведении учитываются ТОЛЬКО ИЗМЕНЕННЫЕ записи.

(121) таки это я и написал

вообще это старый баян, обсуждалось лет 5 назад на партнерском форуме

(122) как то этого я у тебя не увидел...

(97) [почему 1С остановилась на 2 варианте, ]
чтобы не перепахивать УПП 1.3 и заставить мигрировать на УП 2.0

(124) это нормально

(125) так если перепахать 1.3 один фиг получиться УП 2.0 :)

Все понял. Спасибо.

Вернемся.
Как раз пятница...

Запулил базу на RAM :-)
Было
Время с фоновыми (холодное/горячее) 79 886/19 148 мсек
Время без фоновых(холодное/горячее) 67 154/20 676 мсек

Стало

Время с фоновыми (холодное/горячее) 35 194/16 698 мсек
Время без фоновых(холодное/горячее) 23 003/18 508 мсек

Счаст буду искать узкое место.

Видно, кстати, что SQL-ю пофиг RAM при горячем - у него свой кэш.

Такое ощущение, что у меня опять все упирается в диск - RAM дает смешные 86 Мегабайс в секунду. Чем можно диск потестить?

маньячина, выходные же

Запустил
CrystalDiskMark
Для жесткого показал
60/50 Мб. чтения/записи
Для RAM
6000/7000 мб. чтения/записи.

Чето я где то не прав.

блин, я бы выдал еще пару мыслей, но я вговно

а темпДБ на раме?

(136) Да.

(137) база, темпдб, файлы сервера 1с все на раме и тормозит?
а че счетчики кажут?