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

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

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

Бида...

Че сказать то хотел - на момент обработки фоновых - сервер 1С грузит всего то одно ядрышко, ну что за печаль?

Я бросил все попытки ускорения. Очень дорого обходится. Жду УПП 2. Бросай и ты.

(1) рпхостов надеюсь не один ?

Нет, все нормально, как оказалось

МассивФоновыхЗаданий=Новый Массив;
   Для i=1 по 4 цикл
       НовоеФоновоеЗадание=ФоновыеЗадания.Выполнить("ПроведениеДокументовНаСервере.Тест");
       МассивФоновыхЗаданий.Добавить(НовоеФоновоеЗадание);
   КонецЦикла;
   ФоновыеЗадания.ОжидатьЗавершения(МассивФоновыхЗаданий);

Процедура Тест() Экспорт
   Пока истина Цикл
       КонецЦикла;
КонецПроцедуры

Вот это загрузит 4 ядра. Тоесть создаст 4 рабочих потока у rphost-а. Либо по 2 потока у 2-х rphost-ов...

Нагрузка балансируется норм.

спать по ночам надо

Таким образом в моем случае, сервер 1С отрабатывает мгновенно и не влияет на быстродействие практически; тормоза в сервере SQL, и время работы одинаково (практически), что при последовательном, что при параллельном удалении записей в регистрах. Бида.

Будет ли какой выигрыщ при толпе юзверей?

Собственно жду @Fragster-а, прошу поделится историей успеха.

2(9) не понял.. например у тебя есть 100 объектов для удаления.
нет разницы будешь ли ты удалять паралельно 4-мя заданиями по 25 объектов или одним заданием 100 объектов?

(9) как бы позиция разработчиков УПП - что если документы надо перепроводить, то это неправльная организация учета :)

(11) Я думал - есть какие-то мощные нагрузки на сервер 1С.

(13) откуда они там возьмутся?
выпили вообще предварительное удаление движений

Fragster, где же ты?

йа тут, читаю, думаю чуть-чуть

(16) У тебя выигрыш отчего случился?

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

(18) Нет, я про то - чем выгоднее использования ФОновыхЗаданий вместо неиспользования?

была мысль сделать внешний балансировщик одной очереди, но руки не дошли. с внутренним балансировщиком (одна очередь 2-4 фоновых берут из РС задания) выигрыш все равно есть

(19) в смысле, чем? тем, что параллельное удаление быстрее работает

(21) Мммм, у меня - медленнее.
Что я не так делаю?

Я не наезжаю, просто интересно.

(20) Если не пересекаются, а так ждут друг друга.

(22) Видимо по ключам совпадают записи.

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

(22) я не вижу, как ты делаешь

МассивФоновыхЗаданий=Новый Массив;
   Для Каждого ЭлементМассива Из МассивПотоков Цикл
       МассивПараметров=Новый Массив;
       МассивПараметров.Добавить(ЭлементМассива);
       МассивПараметров.Добавить(ДокументСсылка);
       
       НовоеФоновоеЗадание=ФоновыеЗадания.Выполнить("ПроведениеДокументовНаСервере.ВыполнитьРаспределенныеДвиженияПоРегистрамВПотоке",МассивПараметров);
       МассивФоновыхЗаданий.Добавить(НовоеФоновоеЗадание);
   КонецЦикла;
   ФоновыеЗадания.ОжидатьЗавершения(МассивФоновыхЗаданий);

(26) Так, походу я дятелъ

Надо делить не по регистрам, а в разрезе НабораЗаписей

Тоесть, есть 400 записей регистра, именно их надо разделить на 4 фоновых задания, так?

Вернусь немного в прошлое:
Просто вот когда отрабатывается код (28) - совсем чуть чуть загружен сервер 1С и полностью загружен SQL

(30) не понял...

(28) Интересно. Ты проводишь документы пораллельно по регистрам. Мое имхо должны работать быстрее.

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

(32) Ты делишь как?
В 1 фоновое отнесем РБ.Хозрасчетный, РН.Продажи
В 2 фоновое отнесем РЮ.Налоговый, РН.ПродажиСебестоимость....

ИЛИ

В 1 фоновое отнесем 100 1-ых записей РБ.Хозрасчетный...
В 2 фоновое отнесем 100 2-ых записей РБ.Хозрасчетный....

(35) вариант 1

(36)+ вариант 2 - взаимоблокировка

(37) Ну в общем да, но можно разбить по наборам в разрезе измерений.

(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с все на раме и тормозит?
а че счетчики кажут?