К списку форумов К списку тем
Регистрация    Правила    Главная форума    Поиск   
Имя: Пароль:
Рекомендовать в новости

Очень медленно проводится сдельный наряд

Гость
0 - 18.11.2014 - 15:06
ЗУП 2.5
Платформа 8.3
==============
С какого-то времени, с месяц назад, сдельные наряды стали очень медленно проводиться. В среднем, в сдельном наряде около 20 тех.операций и около 20 исполнителей.
Начала копать, делаю замер производительности и вижу, что 97% времени уходит на такую глупость в процедуре "УдалитьДвижения()" в модуле документа. А именно, в строчке "Движения.ЕСНОсновныеНачисления.Записать();". Ага, думаю, регистр этот расчетный надо бы подробнее рассмотреть. Оказалось, что количество записей там почти миллион и увеличивается ежемесячно на 100 тысяч, а каждый сдельный наряд генерирует около 1500 записей.
Помогииите, пожалуйста, оптимизировать! Или неужели с нового года придется обрезать базу ?



Гость
1 - 18.11.2014 - 15:24
Оптимизировать "наряды", не? Заместо "Дворник Петров: подметание в понедельник", "... подметание во вторник", и т.д. по всем дням недели (с указанием дождика, снега, прочих трудностей" просто "Подметание"?
Или даже (была-не была!) на оклад перевести, а?
У вас серьезно кто-то анализирует эти 100000 операций ежемесячно?
Гость
2 - 18.11.2014 - 17:03
0-KyasLis > СУБД укажи для начала, там посмотрим.
Гость
3 - 19.11.2014 - 16:58
(Извините за молчание, но только вчера зарегистрировалась, потому один день карантин.)

VZ
на окладах они уже сидели, причем на 25 счете, никаких проблем не было, но начальство (а с ними и экономисты) захотело, чтобы для начала было хотя бы по изделиям, а в дальнейшем и по тех. операциям. А в каждом изделии этих самых ТО будет штук по 20. Что-то боюсь я, учитывая уже нынешние проблемы с производительностью (когда упрощенно считается 1 изделие = 1 ТО), что это все фантазии.

Reaper
Сначала была файловая. Там один наряд проводился по 2 минуты. Перевели на MS SQL, теперь по 30 сек.

Делала замер производительности по процедурам - буквально, начало/окончание. Вышло что на удаление движений 50% времени, на собственно проведение тоже 50%. Странно все это! Ну ладно, я понимаю, что проведение, но удаление почему так долго ?
Пыталась подсмотреть в sql-профайлере, видно, что сначала делаются insert'ы в тайм-тейбл, затем эта временная таблица инсертом переносится в таблицу регистра. Вот этот insert и занимает самое большое время.

Ребятки, ну что делать ? Помогайте! Съедят ведь меня расчетчики :(
Гость
4 - 19.11.2014 - 17:05
а нахрена на 2.5 платформа 8.3?
Гость
5 - 19.11.2014 - 17:07
сделай в мс скл стандартные хрени, переиндексация, чистка процедурного кэша
Гость
6 - 19.11.2014 - 17:08
обычно сильно помогает, но если есть rls то не сильно
Гость
7 - 19.11.2014 - 17:38
Дебилы
Проблема проявила себя еще когда была 8.2. А 8.3 была поставлена не мной, потому как на этом сервере есть и другие базы.
Все стандартные действия с скл админом уже проведены, именно после этого время с первоначальной минуты упало до 30 сек. Но все-равно это очень дооолго, расчетчицы очень недовольны.
Мне другое непонятно: делала статистику по базе, есть и другие таблицы, которые перевалили далеко за миллион, но проблем с ними нету. Ведь смешное же количество записей - миллион!
А что будет, если перейти на учет непосредственно технологических операций ? И что, все кто внедряли ЗУП или УПП на крупных производственных предприятиях с многопередельным производством, усаживали всех сдельщиков на оклад ? Ну смешно же.
Гость
8 - 19.11.2014 - 19:29
7-KyasLis > Вообще-то платформы могут работать параллельно. Установка 8.3 вовсе не предписывает снос 8.2, и не запрещает запуск одной и той же конфы на разных релизах. Разумеется, если в конфигурации не задействован функционал различающийся/отсутствующий в какой-то платформе.
Еще крайне не рекомендуется задействовать разные релизы движка в многопользовательском режиме.
А так, ЗУП2.5 вполне можно оставить на движке 8.2.
Гость
9 - 19.11.2014 - 19:44
VZ
Пробовала переносить ЗУП на другой сервер с скл. Результат точно такой же, с поправкой на разницу в производительности серверов.
Гость
10 - 19.11.2014 - 19:51
+8 И тем не менее вопрос "У вас серьезно кто-то анализирует эти 100000 операций ежемесячно?" остается.
Если ответ отрицательный, то это означает, что выхлоп от заведения этих операций единственный: толстенькие пачки бумаги, которые "экономисты" предъявляют руководству как доказательство спиноломной работы, и неисчислимых бедствий, которые обрушатся на предприятие, если им дать под зад коленом.
Гость
11 - 19.11.2014 - 20:08
(10) Давайте разобьем вопрос на две части:
1. Эти 100тыс. записей анализирует как минимум документ, который считает налоги с ФОТ. Я так думаю, что для того регистр расчета ЕСН по основным начислениям и существует.
2. Да, сделка нужна чтобы честно посчитать зарплату сдельщикам. Сделал 10 изделий - получи (расценка за изделие)x10. Это честно. Иначе, как на большинстве предприятий, как я видела: дали бригадиру сумму за месяц, бригадир поковырялся носом в пальце и разделил - этому столько, а этому столько. Потом сунули все это на счет 25 и аккуратно размазали ровным слоем по себестоимости выпущенных изделий. А дальше возникает ряд вопросов: а почему зарплата основных рабочих садите на 25, а не на 20 ? а сколько зарплаты в структуре себестоимости конкретных позиций изделий ? и т.д. по возрастающей.
В идеале, я понимаю, что надо бы расценивать технологические операции и отражать именно ТО.
Если так пошло, тогда почему вообще используют спецификации на выпуск продукции ? Можно ведь списать сырье котловым методом и опять же размазать результат по выпуску ? Фин.рез. ведь от того не изменится ? Конечно, не изменится.
Я к тому, что если у такой проблемы нет решения, тогда 1С и вправду исключительно для автоматизации ларьков :( Грустно :(((
Гость
12 - 19.11.2014 - 20:33
11-KyasLis > Насколько я понял из ответа, анализом этих 100 тыщь записей никто не занимается. Понятно, чО :)
Но мысль о полезности анализа сравнительной себестоимости изделий сама по себе здравая. Но затратная.
Гость
13 - 20.11.2014 - 00:12
3-KyasLis > Ну вот. Проведение ускорилось в 4 раза. Для дальнейшего расследования нужно больше информации. Хотя бы список 10 самых длительных операций в процессе проведения с их временем выполнения и процентом по отношению к длительности процесса проведения.
Гость
14 - 20.11.2014 - 14:20
(13) Есть даже конкретная строчка: "Движения.ЕСНОсновныеНачисления.Записать();" в процедуре "УдалитьДвижения()".
Гость
15 - 20.11.2014 - 15:31
14-KyasLis >Сохрани движения документа в Excell, закомментируй эту строчку, перепроведи документ и сравни движения с сохраненными ранее. За результат не ручаюсь, но шансы есть.
16 - 20.11.2014 - 15:44
Ннну проверьте может перед записью или при записи чегог-нибудь делается?
Или это именно физически запись в регистр? В таком случае и остальные регистры тормозили бы, раз тормозит только этот - похоже что обработчик или подписка.
Исхожу из того, что ТиИ и dbcc отработано всё.
Гость
17 - 21.11.2014 - 10:58
(15) Да, конечно, если закомментировать строчку, то результат есть, но это конечно же неправильно, это не решает проблему. Ведь этот документ не умеет сам удалять свои движения, поэтому и есть процедура, которая это делает.
(16) Подписки я посмотрела в первую очередь, их там штук 6, но все они безобидные и отнимают исчезающе малое время.
У самого регистра есть процедура набора записей "ПриЗаписи", но она опять же очень мало чего делает и делает это очень быстро. Тормозит именно физическая запись в регистр, я об этом в (3) уже писала и в профайлере уже подглядывала - insert в таблицу происходит долго. Кстати, в инсерте есть соединение с какой-то другой таблицей и по тем полям, по которым есть условия "ON ..." я сделала индекс отдельный. Не помогло :(

А ТиИ, dbcc и chdbfl (для файловой) конечно же делала - никаких проблем не обнаружено :(
Гость
18 - 21.11.2014 - 11:49
Цитата:
Сообщение от KyasLis Посмотреть сообщение
но это конечно же неправильно
Обоснуй? Я там пока не увидел потребности в очистке движений по проблемному регистру при перепроведении. При отмене проведения - да, зачем при перепроведении это делать - не понял.
Гость
19 - 21.11.2014 - 12:04
(18) Попробую обосновать за разработчиков 1С. Наверное, нужно очищать движения регистра по документу, чтобы не получить удвоение записей регистра по документу. Нет ? Ведь если не очищать, тогда останутся старые движения плюс добавятся движения от проведения ? Потому как у самого документа в настройках стоит, что "Удаление движений" - "Не удалять автоматически". Это наверное для того, чтобы самим контролировать процесс удаления движений. С какой-то не очень нам, простым смертным, понятной логикой. Я думаю, что факт этот надо принять как данность. И я не уверена, что автоматическое удаление движений не будет делать такой же записи набора движений.
Гость
20 - 21.11.2014 - 12:22
19-KyasLis > Для исключения дублирования достаточно очистки наборов записей (привет, документация!). Запись движений, выполняемая платформой для документов с настройкой "записывать модифицированные" выполняется с перезаписью движений. Автоматическое удаление не используется из-за ограничений некоторых версий MS SQL, которое не позволяет использовать более 256 таблиц в одном запросе. Ты уже сделаешь эксперимент, или тебе надо чтобы тебя уговаривали?
Гость
21 - 21.11.2014 - 12:48
(20) О, вот это дело! Спасибо! Буду экспериментировать :)
Гость
22 - 21.11.2014 - 13:05
Докладываю: у документа сделала автоматическое удаление движений, а процедуру удаления движений закомментировала. Время проведения документа увеличилось вдвое :(
Гость
23 - 21.11.2014 - 13:15
22-KyasLis > А я что просил сделать?
24 - 22.11.2014 - 14:36
Киас, сравни пожалуйста время трёх операций:
1. Отмена проведения.
2. Проведение непроведённого документа.
3. Перепроведение ранее проведённого документа.
25 - 22.11.2014 - 19:54
Цитата:
Сообщение от KyasLis Посмотреть сообщение
Докладываю: у документа сделала автоматическое удаление движений, а процедуру удаления движений закомментировала. Время проведения документа увеличилось вдвое :(
это мне напомнило анекдот:
Цитата:
- Далеко-о ли до Таллина-а?
- О, теперь оч-чень, оч-чень далеко-о...
26 - 23.11.2014 - 13:17
sweet little girl...
you're too young to realize...
Гость
27 - 25.11.2014 - 14:57
(24) Я не сдаюсь!
На файловой версии:
1. 35 сек.
2. 36 сек.
3. 67 сек.
Но это лишь подтверждает ранее мною открытое, т.е. на удаление движений уходит почти такое же время, что и на проведение. И время это равно времени записи набора движений в регистр расчета "ЕСН основные начисления".

Я бы вот еще что хотела бы узнать: есть ли у кого-нибудь база с количеством записей в этой таблице больше миллиона ? Все ли в порядке с записью в этот регистр ? Со временем проведения документов ?
Гость
28 - 25.11.2014 - 15:01
Или вот так: есть ли у кого-нибудь база, в которой есть начисление зарплаты сдельными нарядами и примерно с такими же объемами, т.е. каждый день по 5-10 подразделениям делаются наряды, в каждом из которых 20 тех.операций и 20 исполнителей ? Или это все фантастика ? Или на всех производственных предприятиях используют котловой метод начисления зарплаты повременкой на окладах c премиями ?
29 - 26.11.2014 - 00:32
Киас, сделай пожалуйста замер производительности проведения непроведённого документа и расскажи, кто там у нас лидер.
Гость
30 - 26.11.2014 - 23:12
(30)
1. Строка "Выборка = Запрос.Выполнить().Выбрать();" из функции "Функция ПолучитьГрафикСотрудникаНаДату(Сотрудник, ДатаПолученияГрафика)" - 47%.
2. Строка "Выборка = Запрос.Выполнить().Выбрать();" из процедуры "Процедура ЗарегистрироватьПерерасчетыПоФактическойВыработке( )" - 35%.

При отмене проведения лидер тот самый, о котором я и говорила в начале: "Движения.ЕСНОсновныеНачисления.Записать();" в процедуре "Процедура УдалитьДвижения()" - 94%.

Кроме того, отмена движений отрабатывает еще и при проведении проведенного документа.
31 - 28.11.2014 - 00:31
Рекомендации, что можно сделать простого, не углубляясь:

1. Разобраться, какого лешего так долго получаются графики, оптимизировать. В случае непреодолимых затруднений хотя бы кэшировать.
2. Если перерасчеты не применяются в реальной работе - можно попробовать нафиг убрать их регистрацию. Но придётся внимательно проверять, что ничего не упало. Ну либо оптимизировать запрос ясен пень :).
3. Убрать движения и удаление движений ЕСНОсновныеНачисления из сдельных нарядов. Регистратором оставить конечно. Написать обработку, которая добавляет эти движения во все сдельные наряды за месяц. При желании сделать регламентное задание.
32 - 28.11.2014 - 01:41
Ещё можно попробовать странную вещь (вместо пункта 3): в регистре ЕСНОсновныеНачисления поставить свойство "индексировать" у измерений Сотрудник и ФизЛицо.
Гость
33 - 08.12.2014 - 19:35
Эх, оптимизация SQL сервера помогла! Не я оптимизировала, а сисадмин. Теперь в 10 сек укладывается перепроведение документа. Всем большущее спасибо за участие!
34 - 08.12.2014 - 20:01
... и вот так всю жизнь.
Пожалуйста! Обращайтесь! :)
Гость
35 - 08.12.2014 - 20:35
[*****]
Гость
36 - 08.12.2014 - 21:50
35-Дебилы > и не говори


К списку вопросов
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск




Copyright ©, Все права защищены