MRP - Different Results between 2 Settings when Running

Epicor ERP 10
,
1

When I run MRP manually with the following settings:

image
image591×826 22.3 KB

My logs are as follows:
07:22:26 Building Non-Part List
07:22:26 Building PartList Level: 0-0
07:30:16 Building PartList Level: 1-0
07:36:20 Building PartList Level: 2-0
07:38:52 Building PartList Level: 3-0
07:39:44 Building PartList Level: 4-0
07:39:54 Building PartList Level: 5-0
07:40:00 Building PartList Level: 6-0
07:40:05 Processing Schedule Load
07:41:30 Processing Orphan PO’s…
07:41:30 MRP Regeneration process finished.

When I run MRP through a schedule with the following settings:

image
image588×823 21.9 KB

My logs are as follows:
01:01:35 Building Non-Part List
01:01:35 Building PartList Level: 0-0
01:12:47 Building PartList Level: 1-0
01:14:25 Building PartList Level: 1-0
01:21:06 Building PartList Level: 2-0
01:23:44 Building PartList Level: 2-0
01:24:54 Building PartList Level: 3-0
01:26:01 Building PartList Level: 4-0
01:26:16 Building PartList Level: 5-0
01:26:21 Building PartList Level: 6-0
01:26:26 Processing Schedule Load
01:27:41 Processing Orphan PO’s…
01:27:42 MRP Regeneration process finished.
01:27:47 Building PartList Level: 3-0
01:28:49 Building PartList Level: 4-0
01:29:04 Building PartList Level: 5-0
01:29:09 Building PartList Level: 6-0
01:29:14 Processing Schedule Load
01:30:30 Processing Orphan PO’s…
01:30:30 MRP Regeneration process finished.

Has anyone seen this before?

Roberto

2

H Roberto,

Your log reminds me of when we copied production database to a test port and left the scheduled mrp/logging running on the test database at same time. Now we ensure that right after copy we delete the scheduled MRP task,

Any chance you have another database running MRP close to same time using same log?

Nancy

3
  • Number of MRP Processes - The Number of MRP Processes modifier defines how many separate threads your server runs to complete the MRP process. This feature improves performance, as you can split one large MRP process into several threads. The process then takes less time to complete. Use this value together with the Number of Schedulers value to maximize the performance of MRP processing and scheduling.
  • Number of Schedulers - The Number of Schedulers modifier defines how many separate threads your server runs to schedule unfirm jobs. This feature improves performance, as you can schedule unfirm jobs on several threads and the process takes less time to complete. Use this value together with the Number of MRP Processes value to maximize the performance of both MRP processing and scheduling.

The more MRP processes you can run, the faster unfirm jobs and suggestions can execute and complete. You can also improve performance by increasing the number of schedulers that can run on your server; the more schedulers you can run, the faster the scheduling engine can schedule unfirm jobs. You modify the Number of MRP Processes and Number of Schedulers values on the Process MRP window.

However as you increase the number of MRP processors and schedulers, the performance boost you receive will eventually decline. This occurs because the server will run out of capacity to handle all of the multiple threads you attempt to run concurrently. Your server has limited capacity, so there will be a point when using multiple MRP processors and schedulers can slow down MRP performance as well.

To help you decide how many MRP processors and schedulers you can run at the same time, check your MRP log to review the performance results. Continue to increase the MRP processes and schedulers until you notice the MRP performance times begin to increase again. You should then be able to determine the optimal values for your server.

Most servers can handle two MRP processes and two schedulers at the same time, so you could start by entering a “2” value in both of these fields. As you run MRP, continue to monitor the MRP and Scheduling logs. If the schedulers are consistently waiting for the next job, you have some options. You can remove one scheduling thread to free up more CPU resources for the rest of the company. If you have CPU resources available, you can also add one more thread to the Number of MRP Processes field and keep the Number of Schedulers value the same. Likewise, if you notice times in the log where the MRP process threads are idle, they can also be used as scheduling threads.

Keep in mind that more threads are not always better. As you run your tests, start with a small value to get a base time. Then increase the Number of MRP Processes and/or Number of Schedulers values for each test. Be sure you always make these changes in small increments. Your performance should improve each run, but you will get to a point where it starts to run slower again. This indicates that your server cannot handle any more MRP process or scheduling threads, and you need to reduce the MRP process threads and scheduling threads back to the point where you achieved optimal performance.

If you notice times in the log where the scheduler threads are idle, these scheduler threads can also be used as MRP processor threads. By increasing the number of MRP processors, you can then improve the performance of the schedulers as well.

If you do not know how many cores are available, check the Pull Max value on the AppServer. This value defines the core limit available on your system.

4

What do your additional logs say, it should have created many little log files? Does it show processing of seperate Parts.

5

NANCY:

Many thanks for the reply.
I think this problem has only started since I copied my Live to Test and did not turn off MRP on the Test - I will check tonight and advise.
Roberto.

1 Like
6

HASO:

Many thanks for the reply.
My MRP runs in less than 20 minutes on the Schedule with settings at 1.
I will leave it like this and turn off my Test environment to see if this solves the problem.
Roberto.