Improving MRP Performance

I remember discussing how they reduced XE MRP runs from 18 hrs to 3.5
hours. I have combed the archives with no luck.
Please contact me if you have suggestions on how to reduce the MRP run
time in XE w/ an Oracle data base. Also running on solaris sun.
I believe the improvements were thruogh changing the Oracle DB indices?
Thanx.

Please provide some more details. For instance, how long DOES MRP run? How many branches? How many Items? Large/small BOMs, ...

Have you tried Net Change?
How often do you run Leadtime Rollup?

Hi Keith !

As you know, Application knowledge isn't my strongest suit - but I did help with the creation of the "new" MRP process just before leaving JDE.

There are 2 MRP programs in Xe now :

Theres the standard R3411 MRP process that works as a single-threaded process.

As you know, this works by moving to the lowest possible level of items in a heirachial tree, and processing each item - then jumping up to the next level.

The new MRP process is R3482 which can process in parallel threads. The way this works is as follows :

A processing Option now exists on R3482 for "Parallel processing" with number of subsystem jobs (set as default to 2). This number should actually be set to number of processors on the Enterprise Server minus 1 - but is really tunable based on the type of MRP runs that the company performs.

The MRP run will start processing the lowest level of items - handing each item to each parallel job. As the items complete for that level, then the parallel processes start "sleeping" until the final process realizes it has finished processing that level. The process then jumps up a level, and spawns jobs for all items of that next level. This is continued until all levels are complete.

I know this might not be the right way to describe Parallel MRP - but believe me, when you set it up it can dramatically affect certain customers MRP runs - its been known to beat an MRP process in World by a factor of 2 on the same platform !!!

So, my guess is that you look for R3482 instead of R3411 information in the guides - I'm sure theres an area where it would help you decide whether R3482 is right for your customer.

Jon Steel

Jon:

The same processing option also exists in R3483 (multi-plant planning). I am assuming the same logic applies there WITHIN each branch. But how do the branch relationships affect the logic?

And by the way, thank you for the clear and concise explanation.

Jeff

Details on why MRP takes 17 hours to run:
Full Regen, multi-plant (makes no diff in multi or not); time horizon = 17 months
Oracle. Sun Solaris, 180,000 items; max 7 levels deep, 4 b/p; XE SP 16

Larry_Jones wrote:

Have you tried Net Change?

Someone else we do that JDE reccommended is to truncate the MRP Messages/Work tables prior to a Full MRP run. e.g.
truncate table proddta.f3411;
truncate table proddta.f3412;
truncate table proddta.f3413;


FYI Our Full MRP run is about 45 minutes. We have 50,000 items in a single plant.

I created a new document today ! "Tuning OneWorld for Performance" is on my website at http://www.erpsourcing.com under "Research" and "Whitepapers"

The document provides a simple method to understanding analysis behind any type of performance related issue in OneWorld !

Enjoy !

Jon Steel

Hi Larry

I know this is old - but interestingly enough I was actually able to reduce the customers MRP run down considerably. I'm writing up the whitepaper at the moment - but the issue with MRP in Parallel is all to do with the Subsystem table F986113 - each of the subsystem processes performs a Select for Update on ALL jobs in the table - and if this select for update takes longer to perform than the MRP process itself, then the MRP will in effect turn into a synchronous job - each process waiting its turn to lock the F986113.

With the help of a DBA, I was able to create a SQL program that runs in parallel to the MRP process that checks the number of Waiting jobs in the Subsystem queue and moves them from waiting to a "hold" status. This process will do this for all jobs EXCEPT about 100 or so. Then it will continually feed the "Held" jobs back to "Waiting" status as the jobs feed through the subsystem.

One company I was at had 1/2million rows in their F4102 table with up to 8 levels - their MRP never finished in the past in less than 48 hours.

Just by implementing the above routine, we were able to achieve much higher scalability on the runs, and the time to lock the table went from 60+ seconds to 0.1 second. Level 1 MRP had 62,000 processes and we reduced the entire MRP run to <8 hours - before we hit the limits of the application server processors (on a 4-way).

This showed that Parallel MRP can scale, and does perform extremely fast. I'll put the whitepaper on JDEList over the next week or so with the susbsystem "daemon" process documented !

Jon Steel
erpSOURCING LLC
http://www.erpsourcing.com

Ok, I realize I'm bumping an ancient thread, but we just started trying to use the subsystem
jobs for MRP, and I'm a little confused. I've got two versions, call them 1 and 2.
I changed the properties of 2 to be a subsystem job. Am I supposed to change the processing option to the number of
processes on version 1 or version 2? Should I see multiple records appearing to process at once?