Hi Team,
MRP run extremely slow. Takes almost 9 hours to complete. Is there any way to check why the process take long time to run ?
Thanks.
How many processors are you running? How deep are your BOMs? How Complex are your BOOs? Are you running finite Scheduling? Constrained Materials? How many unfirm jobs are created? Multi Site? Product Configurator?
Your question is a wide open question, and it is very difficult to answer.
But you can turn on full logging, and capture the log files. It will tell you some hints. You can see how long it takes to create each job.
3 Likes
Post a screen grab of your MRP screen before you press “Process”. That will help answer some questions.
1 Like
I’m no MRP expert, but three things I see are:
- You should probably use a cutoff date. Something that makes sense for your manufacturing constraints. We have gone from 1 year out, down to 6 months.
- Do you need to back schedule that far?
- I would change the number of MRP processes and schedule processes. How many CPUs does your APP server have?
2 Likes
Good morning. In 10.2.600.7 that is due out this week there is the last of bug fixes that i am aware of in regards to performance being released. If can post a response from Tim S response that would be helpful. We too have an enormous MRP run. We are creating around 85,000 jobs, BOMs are up to 12 levels. Our Processors and Schedulers are set at 20 and 10 respectfully.
Regens are in the 8 - 12 hour range. BTW… We are on prem running 10.2.400.6 as of today.
2 Likes
Agree with @Doug.C re schedule start date… when you backdate the schedule start date, you are also backdating all the start date of all jobs and po suggestions when you are below minimum/safety stock. It is best to set the start date to TOMORROW (if you run this in the evening) so that any new min/safety suggestions will be suggested tomorrow. (I also don’t believe in historical scheduling. we cannot do it yesterday).
Number of MRP Processes and schedulers can be bumped up in most environments. The count is dependent on your BOMs/Boos… If you have heavy scheduling, then you should bump that higher. Also… running Finite scheduling will slow things down, but if you need that, then leave it on. On the other hand, if you are not using the finite scheduling, it is a waste of time. Since you are historically scheduling, and since you have the schedule start date in the past, I sincerely doubt that you are using the finite data.
3 Likes
One other thing… you can try running NET CHANGE daily, and then only run full regen on the weekends. It is very rare (but happens) that Net Change takes longer than Full regen.
1 Like
Matt (long time no see!) Have you tried Net Change? I know you have enormous amount of data as we have discussed in the past… in some strange environments, Net Change MRP actually takes longer, but that is very rare. Have you tried Net Change? There are a couple of other Net Change support programs that need to be regularly run if always running net change… but it could save some time.
1 Like
1 Like
We have tried 10.2.500.x and now we are testing 10.2.600.x. 10.2.600.x is the first versions of Epicor that we have been able to run a completely successful MRP run with no errors. Being a 7 year customer, we have been trying desperately to get MRP running smooth. My suggestion is to get updated to the latest 10.2.600.7 as soon as possible. Especially if you are having lots of issues.
1 Like
Question on this one, how much do you know on your hardware, have you looked at your performance monitor and resource monitors to see what is limiting the performance?
sadly we are cloud and have no access to this data ;(
If there are performance issues in SaaS, file a ticket. If you think MRP is slow, you’ll first want to make sure that your parameters are correct for your business as mentioned above. If your company has unique challenges, you might become a good candidate for Epicor to experiment with burstable compute in the future. They dropped the term a few times at the last Insights and MRP would be a great candidate to delegate to a beefy elastic instance. In the cloud, you shouldn’t have to worry about current sizes like we do on-prem. With a little ingenuity, one should be able to provision the needed resources for only the time we really need it and not let extra capacity sit around in our local data centers.
MRP takes close to 9-12 hrs. It was 2 hrs in the week before, but something changed. I have tried different options but seems that certain factors impact the regen calculation more than others. Factors:
1) Long finite period of 720 days and resources are split in greater detail. Some were reduced from 720 days to 540 or 360, but this did not show impact compared to previous 2 hrs run.
2) Work orders are split more accurately - 6 levels down, but each level has less than 10 manufactured parts.
3) SO and forecast visible until 3 years with less and less detail after 1 year window-
4) Ca 20000 unfirm jobs are managed per MRP run and about 650 open jobs.
5) Uncompleted operations in open work orders - part of rescheduling?
6) Constrained materials - 12 constrained materials used on level 6 products only.
7) Using 4 cores - 3 for processing and 1 for scheduling. IT was 1 and 1 and then MRP Regen ran 2,5 hrs.
MOM Redundancy check was also done and no errors there.
Any other bright suggestions?
I’ll say this. I will never, ever add UD fields to JobMtl. It is off limits in my world. I tried once. It went very badly for MRP.
Have you looked at the logs? You might find that one process gets hung up on a really popular part number:
There is a post here MRP Trouble - #11 by Noffie that mentions issues with MRP speed being related to SQL indexes and fragmentation. This might be what you are seeing.
1 Like