Good Morning
We have been having some issues with our ‘MRP with Forecast’ runs, these happen on a Thursday evening starting at 17:30,
Every other weekday evening we run MRP without Forecast and in most cases this completes OK.
I am not an Epicor or SQL Admin so am spending a lot of time reading articles here and making small changes that seem to clear a problem only to find another,
We had some trouble with VSS snapshots causing issues on the SQL server, extended the log backup interval to find VSS snapshots still running, these turned out to be the virus software so they got disabled last week,
Friday Morning MRP had failed,
IIS was recycling the App Pool at the time MRP seemed to give up so that was moved out side the MRP window,
This morning MRP has failed, this time I have an error that I have not seen before in the MRP log.
I am hoping someone here with more know how than me can help push me in the right direction,
MRP starts and gets to Building Partlist @ 17:53, just over 5hrs later it fails and reports the connection has been broken,
What connection and why?
Here is that section of the MRP log, There is a Stack Trace after this if it is of any use?
17:53:20 Building PartList Level: 0-0
22:03:54 Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunSubTask: The underlying provider failed on EnlistTransaction.
Inner Exception:
The requested operation cannot be completed because the connection has been broken.
It repeats this until 23:58 at which point this happens, I have removed our actual part number
23:58:25 Process 1 not responding. Abandoned during process ‘Processing Part~XXXXXXXX’
Then at 05:00 MRP is cancelled which is what the System Monitor reports
05:00:11 Cancelling from MrpExp mrp
So my current target is to work out what happens at 22:03 and why the connection breaks
You are correct, the system.transactions defaultsettings timepoout was set to 5 hrs,
I have now put this back out to 9 hrs and we will see what happens this Thursday night,
Certainly is a new adventure, we have been running Epicor for around 6 years but I have not been involved in the Admin side to much until now,
So a couple weeks on we have a successful run,
I did adjust the timeout and this allowed it to run longer the 1st week, Veeam then knocked it out when it started the nightly backup,
I did exclude that part from that run as well, how ever think it was just the part being processed at the time it failed and added it back in this week,
Last night the Veeam backup was disabled and we had a successful run, although it took close to 10.5 hrs and as can be seen in this log snip most of that time is ‘Building PartList Level 0-0’
Can anyone break down what is it doing at this point?
Why are the other levels quick?
Can I do anything to reduce the time this takes?
It is currently running with 3 MRP processes and 3 Schedulers, would increasing either of these help?
17:55:45 Building Non-Part List
17:55:50 Building PartList Level: 0-0
03:41:35 Building PartList Level: 1-0
03:43:55 Building PartList Level: 2-0
03:46:44 Building PartList Level: 3-0
03:47:05 Processing Schedule Load
So, to jump ahead before explaining anything, run this and it may help with the processing. It can’t hurt anyway. (The 0-0, 1-0, etc. are those “low level codes.”)
The processes and schedulers is a trial and error thing. But probably more than 3 is better, yes. I run 7 each. Is that optimal? No idea.
Where I work, the math on the codes is simple. We are engineer to order. So:
Level 0-0 is the trucks we build, and their demand comes from sales orders
Level 1-0 is components of the trucks
Level 2-0 is components of level 1-0
3-0 is components of 2-0 and so on
Ours go down to… 8-0, I think?
I’ve run that low-level-code process but it has never mattered. It’s not that the process stinks; I imagine it is just fine. Our problem is that our production is very heavy at the top of this chain. So unless we were to change our whole shop flow to split our trucks into smaller jobs (we will not), then this will remain the case.
Now, if your company is not like this, then you might get closer to parity across the levels.
The processor can double as a scheduler, but the schedule cannot double as a processor. With 3 processors, that mean 3 threads are grabbing the next part in line (alpha/numerically) and the schedulers are sitting around waiting for a job they can schedule. I would try going at least 4 processes and 2 schedulers.
When I was troubleshooting a bunch of MRP issues, we tried going up to 6 processors and 2 schedulers but were getting abandoned threads on the processors. Our happy place was 5 and 3 - it does vary based on your server power, MoM complexity, if you have configurators, etc.
Jenn
Oh this reminds me - if you run MRP with finite scheduling (equals true), then it ignores the schedulers and runs it on just one. This has a huge impact.
(I did verify it later in that thread.)
But if you DO want finite scheduling, I’m not telling you that’s bad. But it is a time sink - fair warning.
I have never heard that. Not questioning it, just saying, that’s interesting.
Thank You both for the information, gives me \ us some more tings to look at,and now I understand something I didn’t before,
Now we have a method to complete a run and it is only like this once a week it removes the urgency.so just small adjustments each week and see what happens.
