| 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
| Цитата:
| | ||
| 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
| Цитата:
Цитата:
| | ||
| 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-Дебилы > и не говори | |
Интернет-форум Краснодарского края и Краснодара |
