MRP running too slow

(0) Share

Report

Posted on by Daljit Kaur Rahsi

1,260

I read in many documentation and blogs people asking for any alternative or plans to reduce the process of MRP. We are facing same problem and it take about 2-3 hours to run one.

Is there any alternative to reduce the hours?

*This post is locked for comments

I have the same question (0)

All responses (9)

Answers (0)

André Arnaud de Cal... 301,075 Super User 2025 Season 2 on at

Like (0)

Report

Hi,

It all depends on the number of items and settings related to the MRP run and also SQL server configuration.

Can you provide some information about the numbers and configuration settings?

Was this reply helpful? Yes No
Suggested answer

Brandon Wiese 17,788 on at

Like (0)

Report

Some problems with MRP performance reduce to issues with query tuning. If you're still running trace flag 4136, turn it off and turn on PARTITION and DATAAREAID literals instead.

In my system, MRP should run for about 4 hours a night to process a couple dozen companies of various transaction volumes. My problem was the variation from one night to another. I could easily trace these problems to individual queries, but could not understand why the same query would perform so differently one night after another. Just to illustrate, by variation I mean that one small company might take 5 minutes one night and 90 minutes the next.

Eventually I discovered that updating statistics on the req* tables entirely eliminates this variation. The more I read about statistics in SQL Server, the more sense it made. MRP deletes and then re-adds many, many records, and that throws statistics off very quickly.

In the following blog post, I detail my approach that eventually worked, so much so that I later reduced the timing of the update statistics job (and subsequent DBCC FREEPROCCACHE) to every 2 minutes, which yielded even further smoothing of the variation.

community.dynamics.com/.../master-planning-performance-the-statistics-solution

Hope this helps.

Was this reply helpful? Yes No
Suggested answer

Community Member on at

Like (0)

Report

I'd start by looking under MP/setup/plans, pull up the plan, and look at the session log/statistics summary. That can tell you what stages are consuming the most time. From there, you can get more focused help on what the best plan of attack would be.

Also, one very quick/easy thing to try is to make sure you're using multi-thread processing, with "helpers" enabled during your batch process. You can also see this from the session log, both the number of helpers requested and used. There's a white paper lurking out there to optimize this, but one obvious thing to check is to make sure you're maxing this out--with the number requested slightly higher than the number you're getting.

Was this reply helpful? Yes No
Daljit Kaur Rahsi 1,260 on at

Like (0)

Report

Andre,

I have in all 1764 items and MRP setting and SQL configuration is standard as they are mentioned in the Microsoft documentation. With that 16 no. of helpers and Performance is set to maximum for use of cache.

Was this reply helpful? Yes No
Daljit Kaur Rahsi 1,260 on at

Like (0)

Report

Brandon,

The trace flag is already set to No.

With the documentation you mentioned, with that is it possible to reduce the runtime of the MRP?

Was this reply helpful? Yes No
Daljit Kaur Rahsi 1,260 on at

Like (0)

Report

Chan,

We have 16 number of helpers requested and used. And it seems like the runtime is taking 2-3 hours or even more during the MRP process.

My only concern is to reduce the runtime for the MRP process without affecting its performance. Any way to do that?

Was this reply helpful? Yes No
Brandon Wiese 17,788 on at

Like (1)

Report

Yes, updating statistics during MRP along with a DBCC FREEPROCCACHE as I have described can dramatically reduce the time it takes MRP to run, without reducing the work it does.

But, it depends on what kind of problem you are having. I've made the assumption that you're having poor query performance. Others with suggestions came at the problem from other angles, with good suggestions as well. The problem with your post is it doesn't provide enough information to understand the nature of your problem, other than you're unhappy with how long MRP takes to run even though it may be a completely legitimate run-time based on what you're asking it to do and given your environment. I'd love it if my MRP ran twice as fast, but I've fine tuned it pretty well and I'd pretty much have to ask it to do less work to take less time.

If you want real help and better suggestions, start with better evidence on what's actually wrong. For example, are you monitoring MRP with SQL Server DMV's to identify any specific queries that perform poorly? Can you run a small subset of your MRP with trace active and then analyze the results with the trace parser, to identify specific code problems? If you merely post a general question, you're going to get a lot of general answers.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Yes, there are lots of ways to reduce the processing time. Unfortunately, most of them are probably not the right solution, because there are also lots of potential causes of the slower than desired performance. As Brandon mentioned, you'd have to do some preliminary investigation into the session logs in order to narrow down the nature of the problem to help us isolate the cause and recommend an effective resolution. Otherwise, we'll just randomly toss around a dozen or so things to try that might be enlightening and educational, but won't help you accomplish your goal.

We'd need to know whether the issue is technical (ex. database or network configuration, read/write speed, etc.), item coverage or parameters (ex. getting a metric crap-ton of planned orders), explosion issues, scheduling (time fences, plan settings, finite/bottleneck resources). Heck, it could even be something like number sequence setup--can't imagine you'd be doing this, but if anyone's nuts enough to configure something like planned order number sequence as "continuous" (not allowed to have gaps), that could be a drag on performance.

Was this reply helpful? Yes No
André Arnaud de Cal... 301,075 Super User 2025 Season 2 on at

Like (0)

Report

There was a session on the Technical conference in the past "HELP! MRP is Slow". The presentation and video can be found on CustomerSource:

Presentation

Video

This might give you also some insights. You need to login using a CustomerSource or Partnersource account.

1 people found this reply helpful.

Was this reply helpful? Yes No