по времени работы планирования

[niksen]

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

[oip]

Цитата:

Сообщение от niksen

Какие меры принимаете для повышения скорости...какие меры принимаете для эффективного использования ресурсов?

fed: Multithreaded MRP and related issues

[niksen]

Цитата:

Сообщение от oip

fed: Multithreaded MRP and related issues

спасибо, очень интересно, надо попробовать. А насколько это помогло вам? или замеров не делали?

[fed]

У меня мои немцы запускают планирование каждый день (вечер точнее) и занимает это около 4 часов. Создается порядка 200000 плановых заказов и порядка 1200000 чистых потребностей. Планируется с двух средненьких виртуализованых батч-серверов по 4 ядра и 8 хелперов на каждом (Так сложилось). Вообще я думаю, можно было бы без больших проблем гонять и на мощном одном сервере, но у них его просто не было. В настоящее время там все упирается в производительность SQL Server, потому что сейчас большая часть времени тупо уходит на вставку данных в reqTrans/reqTransCOv/ReqPo.
Да - забыл сказать ограничение по мощности они пока не используют. С ним дольше процентов на 20 (то есть - часиков 5). Да - внутри сводного у них есть несколько не самых оптимальных доработок (заполняют всякие справочные поля в reqPO), которые я в крайнем случае перепишу...

[niksen]

Цитата:

Сообщение от fed

У меня мои немцы запускают планирование каждый день (вечер точнее) и занимает это около 4 часов. Создается порядка 200000 плановых заказов и порядка 1200000 чистых потребностей. Планируется с двух средненьких виртуализованых батч-серверов по 4 ядра и 8 хелперов на каждом (Так сложилось). Вообще я думаю, можно было бы без больших проблем гонять и на мощном одном сервере, но у них его просто не было. В настоящее время там все упирается в производительность SQL Server, потому что сейчас большая часть времени тупо уходит на вставку данных в reqTrans/reqTransCOv/ReqPo.
Да - забыл сказать ограничение по мощности они пока не используют. С ним дольше процентов на 20 (то есть - часиков 5). Да - внутри сводного у них есть несколько не самых оптимальных доработок (заполняют всякие справочные поля в reqPO), которые я в крайнем случае перепишу...

Эх, какие хорошие немцы, стараются использовать всё на максимум А эти 2 средненьких сервера физически расположены на 1ой сильной машинке с 2мя физическими процессорами и 8ю ядрами?

[fed]

Цитата:

Сообщение от niksen

Эх, какие хорошие немцы, стараются использовать всё на максимум А эти 2 средненьких сервера физически расположены на 1ой П осильной машинке с 2мя физическими процессорами и 8ю ядрами?

Не знаю. У них сервера года 2009ого стоят. И сервера эти в то время были чуть выше среднего. Так что по нынешним временам - бедненько достаточно.

[niksen]

Цитата:

Да - забыл сказать ограничение по мощности они пока не используют.

а когда используют это ограничение, у них альтернативные рабочие центры и группы задач настроены или нет?

[fed]

Цитата:

Сообщение от niksen

а когда используют это ограничение, у них альтернативные рабочие центры и группы задач настроены или нет?

Нет - не настроены. Но во первых вообще использовать в сводном планирование до уровня заданий - не идейно. Во вторых - я на аксапте ни разу не видел реально работающее и внедренное мощностное планирование с альтернативами. Почти все используют планирование по операциям. Однажды делал аудит финского проекта, в котором стояло планирование заданий, но только чтобы в shopfloor control можно было трудозатраты вносить. Но у них как раз всегда сторого один рабочий центр в группе был

[rDenis2]

Недавно столкнулся с проблемой что Master Planning с Thread`ами работает очень долго. Оказалось что возникали многочисленные блокировки в ReqPlan, ReqTrans и других таблицах в том числе NUMBERSEQUENCETTS.
Помогла вот эта статья, думаю будет полезно всем.

http://sjakalax.blogspot.com/2010/10...-deadlock.html

В кратце решение, для номерный серий связанный с MRP убрать галку Continous.