Как организовать параллельное проведение... #107514

ТиС 7.7, на MS SQL! Моя проблемма в скорости проведения больших документов (900 и более строк), такой документ проводится 10- 15 минут, в это время остальные пользователи получают сообщения "Ожидание блокировки таблицы "Журналы" или "Время ожидания транзакции истекло"". Посоветуйте, как можно оптимизировать проведение доков?

такая же хреньвсе ждут пока один проведетьсяа перед этим истошный крик по офису - "НЕ проводить!!!" или "КАКАЯ ПРОВОДИТСЯ"

2. Настроить SQL3. Разбивать большие документы на несколько4. http://openconf.itland.ru/vk/prior/prior.zip

Сеть вроди настроена, разбивать доки на несколько, неудобно, время ожидания поставить в "0" щас попробую., Дайте несколько советов по настройке SQL, плиз ?

Тут почитай: http://1csql.ru/materials/articles.html

И еще сдесь: http://www.sql.ru/articles/mssql/Seminars/tgsem06/index.shtml

ок, спасибо

+ создай периферию и перепроводи в ней

Немного о технологии "гибких" блокировок.http://www.softpoint.ru/article.php?id=1

сталкивался с такой же проблемой при проведении в бухии документов "Формирование записей в книгу покупок" и "Начисление амортизации". Решил простым путем - скопировал процедуру проведения в модуль форм, и все расчеты делаются там, после чего передаю ТЗ с реквизитами проводок в модуль документа - там просто создаются проводки. Время блокировки уменьшилось с 40 минут до 30-50 секунд.

а если документ перепроводить не интерактивно, а из обработки?

Ужас!:) 9-ый пост пример того как люди вообще не понимают назначение блокировок. (хотя конечно если начисление начисление амортизации выполняет один человек и закрытия месяца и т.п. нет то тогда как частный случай нможно применять, но я думаю вряд ли автор брал это в расчет)Вообщем можно вообще все подготавливать заранее и потом только записывать данные тратя при этом секунды в модулях проведения. Проблемы ожидания транзакции в 1С не будет зато появится другая более серьезная проблема - проблема согласованности данных, проблема грязного чтения.

Марк, специально для ТиС существует готовое решение--http://www.1csql.ru/advert.html?id=142--цены--http://www.1csql.ru/action/products/info/buy.html?id=222&code=/modules/buy_tradesql--кроме того можно оптимизировать проведение документов и подбор номенклатуры. есть бесплатные оптимизированные отчеты для ТиС.--также есть специальное описание как самому реализовать параллельное проведение для оперативного и бухгалтерского учета.http://www.1csql.ru/materials/files/toysql/doc/block.zipно только для пользователей библиотеки ToySQL.--контакты на support на 1csql.ru, ICQ 169296011

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

То 12.Самому реализовать паралельное движение:) А потом от бухов или от менеджеров слушать упреки почему остатки не сходятся,почему задвоенные движения по документам,что за деадлоки идут и почему документы не проводятся и т.д и т.п.Подобные технологии требуют определенного уровня подготовки и если в ТиС еще можно более менее что то реализовать то в бухгалтерии смерти подобно с ее проводками по одинм счетам на основании остаков по другим счетам.Вообщем утверждение что обычный 1С-ик разбалыванный упрощениями в программировании от 1С сможет наладить самостоятельно блокировочный механизм(корректно) - миф. Не говоря уже об эффективности этого алгоритма - деадлоках , уровне параллельности и т.п. Спроси сейчас любого про алгоритмы и протоколы блокировок - ответят единицы.

- пойдет...Ибо это в общем то регламентный док, и создает его один ответственный....Для обычных доков типа РН - нельзя использовать такой подход......

Можеть быть в вашем мире это миф, в моем - это реальность. Я не отказываю обычному 1С-нику стать необычным. Самое главное - есть потенциальная возможность стать таковым. Дальше все зависит от человека. Действительно для оперучета сделать легче, чем для бухгалтерии. Заметим, что в топике как раз речь об оперучете.

То 16. А предупреждаешь ли ты о потенциальных проблемах в данных к которым может привести такой подход? Может стоит о них поговорить?Одно дело тренироватся на тестовой базе а совсем другое на реальной. Причем что подобные ошибки могут быть обнаружены не сразу а со временем.

Тока что нарыл афигенную статью о блокировках. сижу прусь, в голове начинает проясняться: http://www.cybersecurity.ru/manuals/data/mssql/1924.html

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

на rsdn.ru еще есть неплохие статьи. и эта там тоже по-моему есть.

(19-20)Что не получается втюхать Марку :-)?

10-15 мин. на 900 строк даже для штатных механизмов 1С - это уж слишком. Ради прикола запустил проведение документа на 610 строк (больше не нашел сходу) - 2 мин 52 сек. При этом документ проверяет остатки, резервы и двигает остатки ипартии по двум типам учета и по ходу формирует проводки по одному плану счетов. Да и еще проводится "задним числом".Если документ без всех этих наворотов, да и на ТА, то скорость на порядок будет выше.Может рано о блокировках говорить?

Саша, следите за своим лексиконом. Не втюхать, а продать. Наше дело (читаем работа) предложить. Право Марка принять предложение или отказаться.Не понимаю вашей иронии и улыбки. Очевидно вас как-то задело наше предложение? Предлагаю обратиться вам к психологу.

То 19. Проблемы описаны не все...Хотя вообщем то я еще раз хочу сказать что 1С приняла чрезвычайно правильное решение и сделала блокировки "узкими" через фактически один семафор. Это существенно упростило написание конфигураций а также сняло определнный пласт проблем в которых обвиняли бы нерадивые программисты естественно "глючную" 1С а не себя лично. Данное решение конечно сильно ударило по масштабируемости системы. Но как говорится степ бай степ. Кому нужно решения по увеличению масштабируемости системы то это можно уже решать после внедрения системы и отлаживания бизнес логики. http://www.softpoint.ru/products.php?id=2http://www.softpoint.ru/products.php?id=3

все известные мне проблемы это очевидно не все проблемы. стоит только учесть, что зачастую достаточно знать об этих проблемах. зачастую - это значит, что для конкретных баз 100%.Саша, пошутите тоже про МуМу что ли для справедливости.

Если в процедуре ОбработкаПроведения выполняются запросы к регистрам остатков и т.д. , то лучше их переписать с помощью прямых запросов к базе (1c++,ToySQL, ADO ), но не выносить их в модуль формы, как советует . Т.к. запрос к остаткам должен идти в момент транзакции. Иначе при массовом проведении документов могут появиться "красные остатки".После замены запросов 1с на прямые запросы, скорость проведения может увеличиться на порядок. Если это не поможет, тогда можно пробовать "параллельное" проведение документов.

То 25.Ну для затравки - например как решается проблема дупликат кеев?Простейший пример массовая запись новых эллемнтов справочников в двух документах.Но это просто пример в технической реализации. А это лишь малая часть того что должно быть сделано. Для правильной растановки блокировок должна быть собрана статистика, проанализирована. Должен быть проведен серьезный анализ конфигурации. Потом на основании этого должен быть выбран правильный протокол и потом расставлятся блокировки как в коде 1С так и в T-SQL. Насколько я знаю как раз по этой части пркатически ничего не указано. А ведь это самое главное. Ну не представляю я например как без описания и опыта 1С -ик будет решать проблему деадлоков...Вообщем мое мнение что этим должны заниматся профессионалы. Иначе последствия могут быть плохие.Удивляет меня кстати отсутствие какой либо документации по блокирочым механизмам в 8-ке. Но 8-ка это отдельная тема для разговора.

проблема дупликат кеев решается модификацией нужной ХП. то как анализировать конфигурацию и как выбрать протокол описано в книге. не до самых "низов" конечно, но вполне достаточно для начала. кроме того всегда можно рассчитывать на наши БЕСПЛАТНЫЕ консультации в этих вопросах.

Да нет не задело меня Ваше предложение... просто автор ветки давно пропал, а Вы еще надеетесь и ждете :-)

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

просто люди общаются. кстати довольно познавательно.

Саша, Ваше предположение насчет наших надежд ошибочно. Предлагаю не подставлять себя, если Вы не читаете мысли на расстоянии :)

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

То 28. "Не до самых низов" - я бы сказал скорее по верхам.Мне просто не нравится что некоторые преподносят что это мол все очень просто и легко .(прям доступно и всерьез:)) Статья моя собственно говоря и появилась лишь после того как я увидел пару раз примеры того как горе оптимизаторы пытаются внедрять подобные технологии и к чему это приводит.(хотя саму технологию я внедрял еще задолго до этой статьи)Раньше то вообще считалось что достаточно убрать блокировки 1С и все залетает-заработает.В других системах кстати проблема блокировок считается одной из самых важных и сложных для больших MSSQL систем. Например на той же самой аксапте у меня есть примеры сколько копий поломали.То 33. Полностью поддерживаю. Если система небольшая то эти проблема ожидания транзакции говорит о неэффектинвости реализации в конкретной конфигурации. Вот только и стандартную оптимизацию к сожалению готовить немногие умеют.

Очкарик , как ты определил индексацию в регистрах (штатно)?

резюмируем МуМу. неча суваться куда не следует. уступи дорогу профессионалам.

А на чем же начинающим учится?

почему вопрос ко мне? Саша, задайте этот вопрос МуМу :)

Если сам не будешь никуда соваться никогда не поднимешь свой проф. уровень.

истина

То 37. Тренироватся как говорится лучше на кошках:) Тренировки на реальных БД в живую ни к чему хорошему не приводят.

35, Смотри свойства регистров, такие как:Отбор движений.Отбор итогов.Еще есть Быстрая обработка движений. Она несколько иная по сути....-------------------------------Почитай об этом, и прими решение о применении.

To: , А можно более подробно про "стандартную оптимизацию"Сколько раз слышал, а однофигственно не проходит эта фишка, приходится мучится с нестандартными решениями....Если вопрос покажется глупым, не надо отсылать на RTFM, а просто еще раз подумать. И _аргументированно_ ответить, ну или ссылку на статейку какунить :)

Очкарик , извини неуклюжего чайника, - а какое твоё было решение ? - нуно лиделать настройки непосредственно в database SQL сервера ?

оптимизация проведения + проведение построчно = все довольны

То 43. А я слышал, что на Марсе живут маленькие зеленые человечки и что Билл Гейт - негр.Если программер не умеет штатными средствами выжать из системы все, что можно, то нештатными он только загубит систему.

оптимизация проведения + (что ты имеешь ввиду?) = все довольны

Марк, але! Почитай по моей ссылке. Мы можем решить вашу проблему. Данные документы будут проводится в 10-15 раз быстрее. Я понимаю что речь идет об отчетах ККМ? Может быть на самом деле настраивать параллельное проведение не нужно будет. Кроме того установка указанных тут галок мало чем поможет.

44, Поскольку в моем случае, при проведении документа, нужно было получать итоги, я установил галку "ОтборИтогов=Да", (следует заметить, что размер базы увеличился, что некритично)После этого было явное ускорение процесса проведения.Номенклатуры 25 тасяч.Далее в модуле проведения стал выгружать итоги в таблицуЗначений, особое внимание уделил наложению фильтров на регистр перед выгрузкой.---В моем случае, реч идет о позаказном производстве, где менеджеры "тусуют" заказы между клиентами.------------------------------------------------------------------SQL сервер, пользую штатные настройки.

То 43. Смотри http://www.softpoint.ru/article.php там есть ряд статей.А также на www.sql.ru найдешь много статей по стандартным методам отпимизации.Завтра кстати будет выложена статья по тонкой отимизации запросов на уровне хинтов для MSSQL.

toypaul аська у тебя в оффлайне, а ссылки требуют авторизации...

пиши свою. сейчас я в он-лайн

To 46На Марсе действительно живут (постоянно у космозондов колеса отламывают)Что имеется ввиду под "штатными средствами"?Если у меня база под 2,5гб,(сикуль), в день примерно 1200 - 1500 доков, около 30% доков под 2000 строк. И как боротся "штатными средствами"???

107463232

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

2 построчное проведение. проводим не всё сразу, а например по 10,20 или 50 строк (зависит от скорости).Так проведение открывает транзакцию проводиться док должен из обработки, т.е. проведение запускает обработку, а та по параметрам проводит док по несколько строк отслеживая как он проводится. Примерно так:0. Документ должен быть настроен на не"Автоматическое удаление движений"1. ОбработкаПроведения смотрит есть ли переданный параметр. Нет? Чистим движения, запускаем обработку и выходим из модуля Иначе проводим от указанной строки N строк.2. Обработка считывает кол-во строк и запускает Док.Провести( , Парам ), где Парам вначале = 1, потом N* номерИтерации3. Проверка как проводится док. Если проблемы - останавливаемся и выходим. Если все строки провелись, выходим.

Интересно, а что это за документы с 2000 строк.Неужели их нельзя разбить на несколько доков.

приглашаю вас пообщаться в аське. и вам тоже поможем :)

То 53. В такие цифры слабо верится :)Рабочий день имеет ограничение. Скорость работы операторов тоже. Чтобы набить такое количество информации их должно быть сотни полторы :)

To:Оптовка канцелярскими товарами, около 25,000 наименований.Разбивать доки на несколько, это согласен, поможет, но как быть с клентом если ему приспичило срочно поменять колво чеголибо? Искать среди общей кучи доков, или делать отбор по клиенту, или смотреть номер заказа и по нему искать.... вариантов множество, но всетки "политика партии - один заказ - один док! (желание руководства, пробовал изменить, не получается)"Реклама двигатель торговли! Но спасибо, в данный момент рассматривается вариант перехода на в8 :)Операторы забивают товар по артам(артикулам), плюс опер выбирая в подборе товар (тобищь например базовый комплект руководителя, получает в доке разбивку этого комплекта, после чего может поменять комплектуху) :)

То 60.Да не вопрос. Подобные объемы это не предел для 7-ки. Есть опыт успешных внедрений и на более больших базах.

Кстати, как актуален этот вопрос в 8-ке ?

То 62. Для 8-ки он более чем актуален. Только вот в 8-ке есть штатные методы управления блокировками.(т.е. явных ограничений со стороны движка значительно меньше чем в 1С 7.7.) А сама технология от этого не меняется. К сожалению многие даже не подозревают о наличии блокировочных механизмов как таковых и естественно потом удивляются низкой масштабируемости системы. Правда справедливости ради стоит сказать что на данном этапе типовые от 1С далеки от совершенства в этом смысле. Видимо сейчас основные силы брошены на реализацию логики а также на снятие багов.

Вопрос риторический: почему БД сделана ввиде таблиц, а не ввиде записей?Если из-за скорости - то это ясно, но может другая причина?Ведь если сделать ввиде записей и блокировать одну запись, а не всю таблицу то можно все блокировки свести на НЕТ!

2 нужно чтобы остаток не менялся пока документ не проведётся. Какие записи ты заблокируешь?

Остаток - это итоги, виртуальная таблица.Генерируется перебором всех записей.

+ Можно сделать опциональным блокировку всех записей

2 Гыы :) Ну ты LOL!Именно ВСЕХ записей.

Так это о выбору: хочешь блокируешь или нет. Как в 8-ке в запросе.

2 Извини, но ты не понимаешь сути, ИМХО.