УТ 10.3.7.8, платформа 8.1.15.14

Неожиданно начали жаловаться пользователи на то, что реализация и перемещение стало проводится более 5 минут. Причем не каждый раз, а периодически. Т.е. одна реализация проведется нормальна, вторая виснет, третья опять нормально. Пользователей в базе ведущих активную работу меньше 10. Номенклатуры в реализациях/перемещениях в среднем меньше 10. По партиям проводится сразу, при проведении документа.

При этом в базе ведутся две организации и жалуются пользователи только одной из них.

SQL база на отдельном сервере. Сервер приложений и sql сервер нагружены на 30%.

"Сервер приложений и sql сервер нагружены на 30%." - ого- как посчитал?

(0) Скорость передачи данных по сети какая? Небось, модем 2400 кб/с через vpn и RDP?

на файловой был прикол.. подобная ситуация с проведением..
база 800 мегов...

при попытке выгрузить базу из конфигуратора - сервак умер после того как 1С создала временный файл на 49 гигов...

спасла утилитка из поставки которая лечит структуру..

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

(1) ну примерное конечно
(2) 10 мбит канал
(3) запустил ТиИ, посмотрим

база 7.6 Гб

(4) 10 мегабит это круто :)

где откопали ?

(4) для начала отключи все фоновые задания

(5) Коаксиальный кабель, понимаешь!

(6) отключены, кроме загрузки валют утром

кусок журнала регистрации
http://i.imgur.com/71MYx.png

(5), (7) удаленное соединение йумористы

(8) чОрт не те места пометил.
в журнале регистрации, что делала программа в промежуток времени 19:53:57 - 19:57:47.... предположительно вызывался контроль остатков, но почему так долго. не то количество народу и объем реализации, что бы происходили такие тормоза системы.

(10)  регламентные операции на сиквеле,
полный ТиИ.

итоги рассчитаны?
RLS имеет место?

(3) один файл на 49 ГБ ? о_О

2(4) мог бы просто не строить догадок. Потому что оценить примерно нет возможности. У тебя будет процессор занят на 2 процента, а очередь на запись на винт - охрененная - и пока не запишется, никто ничего делать не будет...
и на сколько процентов тогда загружена машина?

(13) угу...

(15) что можно засунуть в 49 ГБ при выгрузке ~ 800 МБ ?

(16) 1С умеет
я как то срубил УПП 4 Гбайт,
получил в темпах 35 Гбайт мусора одним файлом

(16) Я однажды устанавливал Подрядчик строительства. Дистрибутив 60 МБ разворачивался несколько часов и отожрал несколько гигов...

Мы сталкивались с этим, ключевым является: По партиям проводится сразу, при проведении документа.
При этом ситуация сложно моделируется, то есть один и тот же запрос по партиям выполняется то 5-15 минут, то 1-10 секунд.
Причина скорее всего в неправильном плане выполнения запроса в этот момент. Необходимо его получить и сравнить с правильным, сделать изменения в запросе.

(12) RLS имеет место, итоги рассчитаны

(13) я оцениваю нагруженность примерно исходя из того что на том же сервере приложений и sql базе развернута УПП в которой работает на порядок больше народа. без тормозов.

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

ТиИ вывалило кучу ошибок типа:
Неверные вспомогательные данные таблицы на регистры Закупки и ДвиженияДенежныхСредств

(20) Насколько я помню один тяжелый по партиям (или несколько но ооочень схожих), для убедительности конечно надо знать его удельный вес в общей длительности. Еще сами не сможете решить, можем подключиться: softpoint.ru

думаю для начала надо с ГП разобраться, она у нас в бородатом году оО

и все таки не понятно, почему по одной организации все отлично, а по другой периодические тормоза, если это ГП то она должна влиять на весь учет сразу

замер производительности показывает:
49% выполнение запроса Процедура КонтрольОстатков рн.ТоварыОрганизаций
13% выполнение запроса Процедура КонтрольОстатков_Реализация_ОтчетОРознПродажах_ЧекККМ рн.ТоварыНаСкладах

а сколько строк в остатках? поди тыщь пицот? закрываются то корректно?

(26) тыщ пицот) ну что значит корректно? без минусов

на самом деле номенклатуры "ниочём" 42000 всего, каждая уникальная, в единственном экземпляре.

Как правильно собрать статистику о загруженности оборудования написано здесь: http://kb.1c.ru/articleView.jsp?id=10
На ютубе есть видео Гилева аналогичного характера, о настройке perfmon и интерпретации его результатов. Только после этого можно говорить о степени загруженности оборудования.

Если окажется, что оборудование недогружено - открываем SQL  profiler, начинаем искать неоптимальные планы запросов (использование Nested Loops с таблицами большого объема, Table Scan или Index Scan). Гадать смысла нет.

(0) Переведи эти документы на режим управляемых блокировок. И будет счастье.

(31) ну это самый последний вариант, запасной аэродром)

(30) спасибо, попробую

итак, отчитаюсь для тех кто встанет на эти же грабли.
камнем преткновения был контроль остатков по регистру ТоварыОрганизаций при оперативном проведении документа.

весь запрос публиковать не буду, он стандартный:
таблица номенклатуры из документа с левым соединением таблицы остатков регистров ТоварыОрганизаций и ТоварыКПередачеОрганизаций.

поэтапное тестирование выявило, что трабла именно в регистре ТоварыКПередачеОрганизаций, но!! он был пустой. не единой записи, не смотря на это запрос вместо <1 секунды, выдавал более четырех минут.

при добавлении в текст запроса ключевого слова РАЗРЕШЕННЫЕ, проблема была решена.