Имеется достаточно много документов с табличной частью в несколько тысяч строк (ОКС). При проведении какого из них больше ничего провести низзя. Клиент - 2-х головый Xeon 2.8 4RAM, сервер (два в одном по бедности) такой же, только РАМы 2 гектара. Вынь 2003 везде, полные апгрейды всего ПО (вкл.MS и 1С).
Мож, кто поделится опытом, чего делать-то? Размер mdf 5 гиг, модель лога Simple, три проца под СКЛ, один (0) под остальные приложения. Доки проводятся (партии тож) порядка 10 минут. NIC слиты попарно, т.е. сумма траффика 200 (проверял, не перегружается). На серве критична нагрузка на диски (SCSI RAID 5). Места пока достаточно.

Затрахало, в общем... или настроение сегодня такое?

варпос - а что за документы в тысячи строк?..
и кто их набивает?

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

ОКС - отчеты кассовых смен. Набивает их понятно, фискальное ободудование. Короче, жо... с тремя П в конце. Сворачивание таблиц (ТЧ) при проведении (в транзакции) занимает максимальное время. Нашел в процах проведения по партиям процу, поддерживающую актуальность таблиц-образов партионных регистров (в рус.УПП 2-й этой процы уже нет), так с ней доки вообще проводились часами. Заремарил - поехало быстрее. Но один фиг.

Ща смоделирую и вывешу сообщение СКЛя..

{ВнешняяОбработка.ЗагрузкаДокументовИзПериферийныхБаз(473)}: Ошибка при вызове метода контекста (Записать): Ошибка при выполнении обработчика - '{ОбщийМодуль.УправлениеЗапасамиПартионныйУчет(845)}: Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции:
Microsoft OLE DB Provider for SQL Server: Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
HRESULT=80004005, SQLSTATE=40001, native=1205
'
       Иначе    Объект.Записать(РежимЗаписиДокумента.Проведение);
по причине:
Ошибка при выполнении обработчика - '{ОбщийМодуль.УправлениеЗапасамиПартионныйУчет(845)}: Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции:
Microsoft OLE DB Provider for SQL Server: Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
HRESULT=80004005, SQLSTATE=40001, native=1205
'
по причине:
{ОбщийМодуль.УправлениеЗапасамиПартионныйУчет(845)}: Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции:
Microsoft OLE DB Provider for SQL Server: Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
HRESULT=80004005, SQLSTATE=40001, native=1205

       Иначе    Объект.Записать(РежимЗаписиДокумента.Проведение);
по причине:
Конфликт блокировок при выполнении транзакции:
Microsoft OLE DB Provider for SQL Server: Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
HRESULT=80004005, SQLSTATE=40001, native=1205

по причине:
Microsoft OLE DB Provider for SQL Server: Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
HRESULT=80004005, SQLSTATE=40001, native=1205

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

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

поставьте Full и не делайте автогров для лога - задайте достаточно большой размер для лога.
Если стоит Автогров - в процессе проведения СКЛ начинает увеличивать размер лога - соответственно, не отвечает на запросы приложений..
надеюсь, поможет это.

Ага... спасибо, Франц, ща попробую.

ых... та же хрень, только в профиль. Транзакшн-логу ноги раздвинул ширше mdf... и те же приятные сообщения.

Вижу написано "ВнешняяОбработка.ЗагрузкаДокументовИзПериферийныхБаз", так, ты записывай без проведения. Загрузиш все, начинай проводить.. может так прокатить..

Кстати, как сильно лог вырос?

1

некуевый пример быстроты 8-ки...

очень даже примечательный пример.

Да, тоже парюсь с УПП. Сервер - 2 Xeon 3Ггц, ОЗУ 4Гб, SCSI Raid, Win2003, SQL 2000 SP4. Клиент P-4 1.8, 1G памяти. Документ "Требование накладная" с 4 строчками проводится секунд 30! :( Как с этим бороться? Если одновременно с 3 машин проводить разные документы "Требование накладная" с различными ТМЦ в табличной части, то вылетает на ошибке блокировки при выполнении транзакции. Более тормознутой фигни не видел еще. Даешь восьмерку! Млин её ити. Как на ней работать будет народ (около 35 рабочих мест надо)...

Платформа 12, УПП 1.1.4.4.

(16)Бред какой то. При таких ресурсах и такое. Хотелось бы, чтоб вы докопались до сути. Неужто станрдартные напряги v8 ? Буду читать ветку.

Это УПП видимо. Поставил торговлю - летает, но блокировки тоже есть :( При проведении реализации с 3 мест с разной номенклатурой в табл. частях сыпятся ошибки транзакции :( Млин его ити...

Пробовал ставить сервер 1С и SQL на разных тачалах - эффекта не заметил. Такая же ж.па! Как же с этим бороться то?

Приветик всем. Вижу, поднял актуальную тему... ;)
По поводу размеров: mdf = 6300Mb, ldf 6144Mb (фикс.размер).
Выяснил точно, что тормозит - Таблица.Свернуть(), .Сортировать и т.п. Релиз 12. Посему сказать, что это тормозит только УПП, нельзя. Траблы моторчика налицо. При достаточно "крепких" серверах сворачивание, скажем, 2 тысяч строк длится несколько минут (зависит, вероятно, от ключей сворачивания/сортировки). А, поскольку все это в ОбработкаПроведения, то транзакция однозначно не случается.

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

Что-то Волшебник на этот раз неоперативен. :)

(23) ...
Да я и на хотлайн писал... у меня нет подтверждения подписки на ИТС (два месяца назад куплена УПП, подписка дефолтом идет - я им "плачу" уже в нескольких письмах) - ответ понятен. Валится, кстати, платформа на 2003 в непредсказуемых случаях... в логах выневых сообщается, что ошибки в библиотеках типа core.dll, frntdll.dll, dsgnfrm.dll, frame.dll и т.п. Нечасто, но юзерам я не знаю, что и сказать. Замечу, что все сплошь лицензионное... разве что winrar или чтонить типа этого без лицензий.

(22) запись и проведение не будет происходить в одной сессии, и может быть, это хоть как то скажется на производительности.

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

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

Что еще стоит на сервере кроме 1с?

Сервер приложений и сервер БД - два в одном. В остальном сервер "выделенный" - никого и ничего. Я понимаю, что 2в1 критично... но не настолько же!? Тем более есть сообщение в (20). Опять же, соображения роста ИБ... за 18 дней августа 6 гиг! Но это разумный размер, исходя из роста "бывшей" ИБ на 77 - при 5 регистрах и 10 доках рост .5 гига в месяц. Т.е. по наполнению соразмерно... но пугает.

Все так да не так, при больших объемах как у тебя, необходимость разнесения всей этой байды может быть критичной. Попробуй оставить скл серверу только один физический процессор или вообще только один из гипертрейдинговых и посмотри его загрузку (ха, а она будет небольшой)
+ положи базу на зеркало из двух 36 гб 15000 об/мин чтобы шустрее записывало, тут вообще совершенству нет предела - чем быстрее тем лучше.

+рост иб у тебя совершенно нездоровый! конечно с таким объемом на 8.0 надо как минимум втрое (а лучше в раз 10) более мощные сервера чем для 77

СКЛю я назначил три проц 1-2-3. Проц 0 для остальных нужд. Приоритет верхний, использовать NT fibers, тредов 500.
mdf - автогрув с приростом в 1.5 гига.
ldf - не автогрув, размер = 6000 MB.
--------------------------------------------------------
Через пару дней обещали предоставить два серванта соответствующих (наверное?) параметров. Но уверенности в благополучном исходе у меня нет.

Рост базы пугает... но это 5 прод.универмагов + хез сколько производства.
Ёлы-палы! V8 замахивается на корпоративное использование!

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

Хотя вообщем очевидно, что может только вери гуд железо помочь.

(12345) Спасибо за совет... ща попробую. Просто нет у меня уверенности, что железо поможет. Ты имеешь в виду, что логу автогрув вернуть? Дать ему какой невменяемый процент прироста... Сейчас для базы общая распр.память 12 с копейками, свободно 4.5 гига.

Хотел было уже в пиво задолжаться... рвется транзакция. В общем, я так понял, вопрос в "раздвигании ног" у железа. Грустно это все - быть бы еще уверенным, что не пентагоновского класса сервант нужен.

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

Печально канечно.

тебе надо 4-х Opteron 875, 32 гб ~ 2 (две) штуки в 70000-80000 долларов уложишься!

(39) я бы поразбивал документы..

Не могу я поразбивать документы... это розница. Вот, вроде, подтвердил подписку... серванты взрослые привезли - через день/два встанут. Там посмотрим. Но меня еще эти ошибки dll достают до невозможности!
Кстати, как скормил скулю один проц, так и договор по дефолту контрику стало невозможно назначить при проведении чегонить! Вернул взад на три проца. Опять же, никто не в курсе, как приложения "хватают" процы? С "0" и дальше? Или случайно? Я ведь свободным оставил "0"... но нагрузка на все 4 очень как-то мутно поддается логике...

(24) у меня такая хрень была на 932 релизе
щас (11 рел) такие ошибки не возникают

левый совет но всёже, может не проводить по партиям?

Я так понимаю что номер процессора не играет роли, играет роль их кол-во.

Была у меня мысль не проводить по партиям... посмотрел на обработку, проводящую по партиям (это первая ред.УПП), и усомнился в правильности её работы. Проверять/тестить некогда - решил полное проведение делать (у меня очень сжаты сроки). Хотя этот вариант не исключаю на будущее. У меня тут, кстати, все усугубляется партионным учетом по складам...

(42) у меня 12 релиз... и, повторяю, 2003 сервер! Есть подозрения, что дело в нём... точнее, в методах работы v8 с MS 2003. На 2000 AS , под эмулями проблем НЕ БЫЛО! Вот что меня беспокоит. И никто не признается в том, что работает на 2003... ;)

Дык, у нас есть такое понятие в 7.7, но это для скорости работы юзверя + избежание транзакций. Проводиться док и проверят только остатки. Но ставит флаг к проведению. А обработка уже проводит доки с флагом к проведению. НО сие на 7.7. Что да как в 8ке ... Рад бы узнать, но пока ни гу-гу. :((

ых, Did, доки проводятся по всем регистрам, кроме партионных. А обработка шарит последовательность(!?) и перепроводит их уже полностью. Сомнения у меня вызвали два момента:
1. О последовательности в УПП/УТ тут частенько проезжаются не в лучшем смысле (как минимум в тип.Укр.УПП Перемещение не задействовано в посл.!!! - это при возможности парт.учета по складам!).
2. Запись в регистры партий занимает незначительное время (я замерял) по сравнению с расчетами/сворачиваниями и т.п. А в конфе при "неполном" режиме проведения все это (кроме записи) один фиг выполняется!

почти аналогичная ситуация как у A 008
1С:Предприятие 8.0 (8.0.11.3) , 2003 сервер
транзакции просто задолбали. я уже отключил проведение по партиям и регистрам продаж в текущем дне чтоб операторы работали быстрее, но последовательности ведь надо восстанавливать, с учетом того, что оператор который занимается возвратной тарой эту последовательность все время откидывает на неделю-две.
в исходнике перековырялся уже как только мог. но топерь загвоздка в очень простом : по замерам производительности теперь 80% времени занимает строка

>>>>>>>    НаборПродажи.Записать(Истина);

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

Подскажите плиз.

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

вот на 7-ке пожалуйста! - можно сделать нормальное параллельное проведение документов

Мда. На грустные размышления все енто наводит...
Выход то каков с этой ситуации?
Виновен 2003 сервак? Тогда на 2000 меняем. А если не сервак?
Ух, млин....

А хотьлайн молчит насмерть... мать их...
Было где-то (или у меня видение было?), что 1С пристально следит за внедрениями УПП?

(52) а нах ты сдался хотлайну?
Купил? Вот и отвали....

(46) попробуй на Win2k, у меня SP4 SQLSP2, доки по 200-300 строк проводяться по 5-10сек с партионным учетом
проверял обработку "проведение по партиям" никаких багоф не нарыл (мож не там рыл :)

(54) серваки разненсены, серв СКЛ наподобии как у тебя, серв 1с простая раб станция Р4 3200 (знаю что это не правильно, времени нет переложить)
+ доки переноса остатков (оприходование товаров) в 7000 строк проводятся за ~1,5 мин

(53) хот лайн как обычно "не мычит не телится", мне помогали мои франчи, за что им большой сенкс

что то я не видел информации от (0) по модулям проведения,
вопрос: проведение кассовых смен в НачатьТранзакцию() идет?

расскажи про модули что там?

(46) а ты не пробовал на 2к обратно поставить?

Узкое место это скорость записи-чтения на диск.
Меняй 5-й раид на 10-й, чем больше дисков, тем лучше, а также strip size установи 16-32. Получишь ощутимый прирост производительности, проверено!!!

(60) по моему у него или "программые" траблы или "софтовые", на железо грешить надо в последнюю очередь

to (60) Производительность лишней не бывает, тем более, когда она лежит под носом.

(62) сагласэн

Модули проведения ОКС типовые, практически ничего не изменял. На w2k откатиться не могу - политика компании иметь все лицензированное... и это лицензированное есть 2003. НачатьТранзакцию не использовал и в обработке проведения нигде, вроде, не видел, равно, как и в общем модуле партионного учета. По RAID 10 - мысль... нужно будет выяснить...

(64)
читай здесь:
http://www.rekvizit.ru/data/lab/cpu/281102/281102.shtml
и здесь:
http://zeus.sai.msu.ru:7000/hardware/data/int_raid/

Мда. Огорчили Вы меня. Производительность вообще больная тема при определенных объемах. На 7.7 действительно можно добиться довольно не плохой скорости, но сложно написать конфигу подобную УПП. :((
2(008), А оптимизить модули не пробовали? Железо железом, а натупить там могли.

Времени нет на серьезную оптимизацию. Из всей оптимизации ликвидировал процедуру, поддерживающую актуальность таблицы-образа партионных регистров. В ней на сворачивание таблицы уходило 99% времени проведения. Доки ОКС проводились по несколько часов!!! Во 2-й редакции этой процы уже нет.

(64) Вроде МС при лицензировании старшей версии разрешает использовать младшие.

(64) красиво сказано "практически ничего не изменял".
Но "не изменял" и ""практически ничего не изменял" не одно и тоже.

(50) пора писать ToySQL для v8

Или уже 9ку начинать :))

Люди! Еще вопрос... уточняющий. Сейчас буду SQL на новой тачке разворачивать. SP4 накатывать? Инстал имеет SP2. Есть настойчивое мнение хороших людей оставить SP2.
P.S. Я уже от каждого нюанса шарахаться начинаю.

(70) а чем язык запросов 8-ки не устраивает?

(0)

Была похожая проблема на 7-ке, оказалось хард один крякнул, но не до конца, и система как-то пыталась эту проблему решить - что-то куда-то переносила, копировала...

Харды проверь, а?

Бубен в студию!!!
Ребяты, вы что ее, эту е**** восьмерку не тестили????
Возьмите и запустите в восьмерке обработку проведения любого документа одного вида на десяти или более клиентах (для счастья парочку в терминале) - на хорошем железе (сервер+сервер+клиент) эти ошибки вылазят РЕГУЛЯРНО, пропорционально количеству непосредственно операций записи в сис таблички в модуле проведения.