Резкое падение производительности после пересчета итогов #227653

Доброго времени суток всем! Столкнулся с проблемой сильного торможения работы в начале каждого месяца. Попробую описать проблему подробнее. Стоит конфигурация Управление Торговлей 10.2 довольно сильно переписанная , размер около 14 ГБ, трехзвенная структура работы  Пользователь  -> Server1C -> SQL Server.  Сервера 2х процессорные, на обоих 1й скази рейд и по 4 ГБ оперативки, сеть 1ГБ. С 5го числа пользователям предлагается произвести пересчет итогов (стандартно) и вот всегда после этого пересчета возникают проблемы со скоростью работы, 1 заявка делающая минимум движений проводится по 10 минут, такое наблюдается уже несколько месяцев помогает только «Переиндексация» и «Пересчет итогов» через конфигуратор да и то со скрипом т.е. работать начинает быстрее, но не так как было до этого пересчета, за 2-3 дня все само приходит в норму. К слову сказать, что если не делать пересчет итогов, то соответственно очень медленно делаются отчеты. Огромная просьба, если вы уже сталкивались с такой проблемой или может чего-нибудь посоветовать – напишите, буду ОЧЕНЬ признателен.

а что именно происходит медленно? В отладчике замерял производительность?

Движения по регистрам. Вообще все операции связаные с чтением и записью в базу происходят на 2 порядка медленнее

базу обслуживать надо: регулярная реиндексация, ну или дефрагментация индексов + обновление статистики, очистка процедурного кэша. На ИТС написано чего и как делать.

На ИТС почитай, там что то со скулем(его средствами) для профилактики периодически надо делать для увелич. производительности.

8.0 очень интересно считает регистры накопления: в нем храняться остатки на КОНЕЦ текущего месяца, и для вычисления остатка на конкретную дату сначало береться остаток на конец ТЕКУЩЕГО месяца и ВЫЧИТАЮТЬСЯ движения... В результате если это оперативное ведение, то скорость повышаеться, но при НЕ ОПЕРАТИВНОМ в начале месяца скорость падает

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

не поможет... 1. причина: 8.0 хранит и последние итоги ВСЕГДА!!!! 2. и внутренний расчет ведеться ВСЕГДА в обратном порядке от БЛИЖАЙШЕЙ БУДУЩЕЙ ТОЧКИ, и если ее нет то из системной (1.) можно попробовать сделать вместо месяца неделю или даже день, только возможно-ли это я не знаю...

тогда скорее всего тормозит не по этой причине :-)

Спасибо всем за отзывы. На данный момент база уже "умерла", востанавливаю из резервной копии (со всеми вытикающими), у моего кабинета толпа... кто-то чем-то стучит по двери подозрительно смахивающим на топор. Сколько осталось жить - даж не знаю :-) Все это было так весело если не так грустно

Вот очень интересно, почему описаные выще действия через конфигуратор в какой-то мере спасают ситуацию?

не переживай у нас в четверг упали 2 из 3 дисков в 5райде, головки упали, а архивы хранились ТОЖЕ на райде, в результате 2базы - год еще 2 базы - квартал

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

Да, спасибо. Я себе составил примерно такую же схему. Взять Профайлер и трасировать запросы к SQL сравнивая результаты с тестовой базой.

Может кого заинтересует в чем была проблема: Во первых самые страшные тормоза оказались при проведении заказов покупателей, запись в регистр происходила чудовищно медленно, а вот такая не хитрая строчка спасла мир (мой личный, внутренний): РегистрыНакопления.ЗаказыПокупателей.УстановитьИспользованиеИтогов(Ложь); В регистре оказалось ОЧЕНЬ много не закрытых заказов и как я понял при записи нового движения происходил какой-то перерасчет чего-то, естественно в силу указыных причин выше, занимавший не мало времени. Почему обострение произошло после пересчета итогов... надо еще подумать (связь где-то на поверхности плавает, но ускальзывает) Когда проблема решена, все кажется таким простым, а я сам себе таким глупым :-)

Ты в отладчике посмотрел, что именно при записи новых движений такое происходило?

А как же актуальность итогов? Если отключить расчет итогов при проведении - тогда итоги будут не актуальны...

А делали после этого "реиндексацию"? И что с лог-файлом.. Он не вырос "до умопомрачения"???