v7: Долгое проведение реализации 1с ТиС 7.7 sql #606765

Ребят помогите! есть база 1с ТиС 7.7 на sql2000 sp4 на win2k3x64 (raid10, 15к SAS), пользователей около 200 на терминалах. Проблема, во второй половине месяца начинают долго проводиться документ реализации (40 сек,)на другом сервере эта же база в dbf документ реализации проводится во второй половине месяца (без пользователей 15 сек), но в начале месяца все проводится быстро и там и там, бывают сообщения типа "Время транзакции истекло", "Ожидание блокировки таблицы журнала" В какую сторону копать

Наверное там же и бух база и бухгалтера начинают активно работать с программой - книгу продаж формировать или что-то в этом роде... :)

В средине месяца ТА переносят на 31 число... Не?

Расчет итогов. Переписать на прямые.

У нас базы буховские есть есть но никто не формирует книгу продаж сейчас, нет та никто не переносит на 31, Прямые запросы писать не умею

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

ну для начала сделай замер производительности. С вероятность 99% - тормозит расчет итогов. Лечится такими способами: -проводить доки только на ТА -переписать на прямые запросы -расчет себестоимости и контроль остатков делать регламентно, а не при проводке дока. ЗЫ чего вы к бух прицепились - автор же указал конфу

А что говорит товарищ Профайлер? спрашивали?

Прямые запросы не панацея. Смотреть надо. Если уж счет идет на десятки секунд, то посмоти отладчиком, может все-таки проваливаешься в расчет по временным регистрам.

именно так.

загрузка цп 20% средняя длина очереди диска total средний (через монитор производительности виндовый ) 1.3, а диска с базой средний 1 на максимум иногда проскакивает до 40 сеть 1GB, но перепровожу реализацию с этого же сервера процент попадания в кэш скл (% поподаний при отображении данных - 100 % поподаний при чтении с копированием - 100 % поподаний фиксации при чтении - 100 % поподаний чтений MDL - 0 )

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

Да для начала штатным посмотри, 1совским... после - мониторь скриптом от vde69/

если перепроведение  - вынесите папку пользователя на рам диск : 1с77 для запросов создаёт временные файлы. также может помочь обновление статистик.

Посмотрел штатным отладчиком, да проваливаемся в расчет временных итогов на 93%, обновление статистики 2 раза в день, реиндексация ночью

Сервак работает 267 дней поэтому дело явно не в перезагрузке

Ну вот и старайся проводить на ТА.

Реализации проводятся в ТА

тогда откудова в них временный расчет?

Ну ошибся я, потому что перепроводил документ более старый, но сейчас подключился к кассиру и увидел что основное время уходит на ожидание блокировки таблицы "журналы"

ты не 86 года?

нет не 86, для использования скрипта vde69, открываю query analizer, вставляю скрипт он выполняется и записывается в master---stored procedures. Далее выполняю exec track_waitstats 30, 1. Ничего ненапутал?

Ничего не напутал. Там все написано :-)

Но тебе _ДО_ анализа собственно сервера (что никогда не бывает бесполезным) надо для начала найти то, что тормозит поток...

СПС но описание не нашел скачал с инфостата если есть описание буду рад ссылке

там прямо в тексте скрипта и описание. в первых 3 строчках

Я уже на тестовом серваке сделал только не могу найти куда пишется в master процедура track_waitstats

вот что выдал exec track_waitstats 10, 1

10 минут не показатель. ЗЫ я бы на твоем месте в первую очередь оптимизировал бы обработку проведения документа Реализация.

завтра протестирую на 2 часа и выложу ибо не понимаю там, основные тормоза из-за ожидание блокировки таблицы "журналы"

естественно. это общая табличка - пока один документ проводится - остальные "курят бамбук", при этом грузят проц бесконечным циклом. Уменьшить нагрузку на проц можно с помощью патча от Romix-а (хотя не все этот метод считают "кошерным") или установкой параметра "ожидание тразакции.." в 0. В любом случае на 1 документ - 40 секунд - это очень-очень-очень много. Для начала определись - проводятся ли доки задним числом или же нет - воткни в ОбработкуПроведения ЗаписьЖурналаРегистрации "проводим задним числом" или "проводим оперативно" + время проводки документа. Через пару дней выгрузи ЖР в ексель и посмотри что там да как. Думаю, что 90% доков проводятся "задним числом"...

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

(all) что есть в Вашем понимании заднее число. Если период расчетов итогов месяц ( M ) то любое движение документа в текущем месяце это одна запись в rg. т.е. предположим ta установлена на 31.04.2012 Есть документ N1 от 05.04.2012 и документ N2 от 18.04.2012 и оба этих документа делают только одно движение без всяких рассчетов ( предположим по кассе) то проведение этих документов эквивалентно Отмена проведения удалить ra сначала rg - для периода 01.04.2012 Проведение запись ra после rg + для периода 01.04.2012 Если не говорить о твоем железе то  делай оптимизацию модуля проведения. Если есть в модуле проведения рассчет итогов то реализуй обратный расчет временных итогов ( от конца периода) и получишь выигрыш т.к. большинство документов вводиться текущим днем.

В принципе ответ дан в . Да, кратко и понятно. Кому нужно разжевать думаю спросит. Из своего опыта делал по разному. На одной высоконагруженной базе пришлось отказаться от расчетов при обычном проведении а вынести в групповое перепроведение с прямым запросом. В результате операторы неуспевают набирать документы. Единственный минус - нужно перепроводить что б увидеть главное (сколько заработали).

вынеси это в регламентное задание.

Да перепроведение и так по расписанию идет. Просто минус в том что сразу невидно результата. Но тут, как говорится, или шашечки или ехать. А у автора стопудово на расчете партий тормоз. Вот только он сам должен понять что ему делать.

а зачем нужен "сразу результат"?