So, weird thing since upgrading to 2023.2.6, we’ve had this happen a few times where MRP runs impossibly slow, not just normal slow. Daily net change typically only takes about 5 minutes, processing something like 20 parts per second, but when we encounter this issue it shows down to around 2 parts per minute. I watched it yesterday take more than 10 minutes just to write it the first 30 lines of the main log file - just the execution settings.
Rerunning MRP afterwards and it runs just fine and in the normal time frame.
Until now we’ve only had this happen on net change by class, after 18 hours it eventually finishes. Now it has finally happened on the nightly full regen, which normally only takes 10-15 minutes. Short of restarting the appserver I’m unable to stop the process.
Plenty of resources of the server, cpu, RAM, disk io are all normal before during and after. We never saw this until after upgrading from 10.2.700 a couple months ago (same server). Has anyone else run into similar?
Make sure you do not have another instance running MRP and writing to the same log file location. This causes issues.
In a test environment, try turning off custom code via the Host Config file. by changing this to true. Recycle App pool to take affect.
customizationSettings disabled=“true”
Simply try recycling the app pool before each MRP run. We had our weekend MRP runs (have 5 different ones) all fail due to time it took to run until we implemented an auto app pool recycle before each run. (We have a dedicated app server for MRP runs with BPMs turned off as well so it does not impact MRP and the recycling does not impact users)
Nothing else running, except 5 minute multi-company process, no MRP in the other companies. If I could reproduce the problem consistently it would be easier to troubleshoot. My first thought was a BPM interfering but the inconsistent nature and especially after seeing it bogged down just writing it the initial lines of the main log file, disk/file io seems a more likely suspect.
I like the idea of a scheduled app pool recycling and I’ll look into setting that up. A dedicated appserver without code for MRP sounds good too, except even though I’ve tried to stop the practice, we still run MRP manually for certain parts/groups throughout the week. Because… reasons. Sometimes the slow down occurs on scheduled tasks and sometimes on manual executions.
I’m going to upgrade from .6 to whatever the latest is next weekend or the the following so we’ll see if that helps.
Good idea. We use defender on the server, so I’ve now added exclusions for Epicor directories. We didn’t need it before so I wasn’t thinking about it. We’ll see if that makes any difference.
I have this same issue right now that started Monday morning but I am on the cloud. I have logs and a ticket into Epicor. Just weird that out of the blue all of our MRP’s are slowing down to a crawl.