Home
Login
Sign Up
 
 

Forum | Message

Tue, February, 27th 2024
Message Link »
6
View »
Elise Sheppard *MUGA
BC:

Forum Question/Topic:

Article:

Anybody notice MRP taking way longer since the 1/20 maintenance?

Since the 1/20 maintenance, the duration of our MRP jobs in our NIGHTRUN maintenance has roughly tripled. Anybody else notice the same? We only had parallel MRP jobs set to one--we bumped it up to 4 and it's working better, but it's still disconcerting when a process suddenly shoots up like that.

Pretty graph for reference! The GIANT spike is the 1/20 maintenance. Orange line is running 8-wk average. Data comes from SHS300, which shows how long the NIGHTRUN job takes each night.  Read more...You can display the record and see how long each job in the run takes. Our culprit is MMS999S2, one of the MRP jobs. We have some items set to continuous net change, but most are recalculated nightly. Show less...
Delivered Read
6
1
John Panzenhagen
That is disturbing.
Marie-Pascale AUTHIE
Hi Elise,
Just FYI, I did check SHS300 and I do not see any increase. Customer use to have MRP for 6h on prem, now only 2h and consistent since upgrade.
Elise Sheppard
I'm kinda hoping it's something we did and not something Infor did--which is why I'm digging for feedback 😀
We are in M3 Multi-Tenant Cloud, forget if I said.
Patrick Suminski
Hello Elise,

It may be worth checking CRS797 to see how many parallel MRP jobs can run at once. We had faced some issues with MRP runtimes in the past, and increasing this value alleviated the issue. Please consult Infor Concierge/IMS for best practices, a good reference is KB 2033035 - "M3 BE Best Practices - MRP M3 Materials Requirents Planning (MRP) - Optimizing Performance" in the Concierge Portal.

Best,
Patrick
Elise Sheppard
Thanks, Patrick! That's exactly what we're tweaking now to bring down the duration. I'm still curious why it jumped so suddenly and if others have seen same/similar.
Patrick Suminski
Hello,

Our troubleshooting for this issue took place in November of 2023, so unfortunately it seems I won't be able to speculate what could have changed/caused the increased runtime. In our case, this change in CRS797 did the trick and we saw an immediate impact on runtime the following MRP run.

If you have any other related questions or comments, feel free to reach out. I'm glad you're in the process of testing this as a solution to the issue!

Online