E10.1.500.16 Both MRP and Getting Details SLOOOOW

Epicor ERP 10
,
1

Just interested if others have had the following issues.

  1. When loading a job manually and getting details on a multi-level BOM it is a lot slower in comparison to Epicor 9.05.700b
    Previously took 6 seconds in E10 it now takes 80 seconds.

  2. MRP not loading the details into a lot of the unfirm jobs. When looking at the MRP log we get the following deadlock error.

06:27:20 Adding to job:U0000000048714 Quantity:2.00000000.
06:27:20 Copying BOM from Part:192768 08 Rev:9 to Job:U0000000048714.
06:27:21 Transaction (Process ID 354) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Have reported but not getting a lot of response from Epicor, any advice would be welcome.

Regards

Richard

2

Are you getting a lot of those deadlock errors? We had that problem when we first went live on E10 - it was miserable slow and crashed a lot and errors all over the place - and then happened to realized that I had changed a setting on the database that needed to be reset - and that Epicor by default when creating a database does it this way. It was the read/write isolation level setting on the database that we needed to change to the Epicor recommended - as you can see in the Epicor PDT config check:

image.png908×294 6.74 KB

If interested, some further reading:

3

Hi Adam

Unfortunately it’s set to 1 as above.

Thanks for the suggestion.

Regards

Richard

4

We are going through the same issue with MRP. Epicor has no solution for the deadlocked records, but they asked us to increase the number of processors and schedulers used in the MRP run. We started with 3 and 1 and have moved up to 7 and 3. We have seen some improvement but we still can’t match the ET we got in Vantage 8.03.
The good news is that when you find an “empty” UF job, you can run MRP by part. We have seen that this takes about 5-10 minutes, depending on the number of levels in the BOM. That usually fixes the issue on that part. The bad news is that if you had open purchase orders or jobs for the parts within that “empty” UF job, there would be cancellation suggestions for those parts. We have to work closely with Purchasing to make sure we don’t act on these cancellations right away.

5

That’s concerning that such an important module is slower and has problems. It reminds me of an indexing problem we had in Epicor 9.04 that Stephen Edginton fixed for us. Does anyone use the SQL Database Tuning Advisor to analyse any indexing issues?

1 Like
6

I believe this is down to an indexing problem on the file attachments. Have added an index and everything is a lot faster and now no deadlocks.

1 Like
7

We did receive an SCR from Epicor to address the deadlock issues, and it works great! it is SCR 201978. Thanks for the tip on the attachments. We will try the indexing fix and see what happens.

8

Wait, what!? I thought Epicor didn’t do One-Off Fixes anymore on Epicor 10.1 and above?

9

It will be incorporated into the E10.1.500.21 release. We got it a little ahead of time :smile:

1 Like
10

So you are on like 10.1.500.20 or something like that?

1 Like
11

@DavisStd1 Thanks for the tip about the 10.1.500.21 update fixing MRP deadlock errors! We are upgrading from E9 to E10 and when testing MRP this week we were getting many deadlock errors in the MRP logs. We were also getting unfirm jobs created with no BOM and some of the unfirm jobs were getting production run quantities of 0. In Time Phase for those parts the Exception for those unfirm jobs was “Direct” for some reason. We were on the 10.1.500.20 version. Once we upgraded to the 10.1.500.21 version all these issues cleared up. Thanks again! :+1:

1 Like
12

Able to get random MRP Deadlocks on JobAsmbl_UD and JobMtl_UD whenever MRP runs; no BPMs or Customizations on those tables. I would say every 3-5 days. Then we re-run it and it works fine until next time it happens. Typically I would say Multi-Job (Job-Job) MRP Runs / Scheduling. Which is new in 10.1.500.x so I would assume they have bugs in there.

Whats even more bothersome that It takes MRP 4-6 hours to run on 10.1.500.26 (Full Regen).

keylock hobtid=72057601627652096 dbid=5 objectname=EpicorERP.Erp.JobMtl_UD indexname=PK_JobMtl_UD id=lockc7f6d1800

02:27:31 Process 6 not responding. Abandoned during process ‘Defunct : Processing Part~5-01236’
02:27:41 Process 4 not responding. Abandoned during process ‘Defunct : Processing Part~5-02377’
02:27:52 Process 3 not responding. Abandoned during process ‘Defunct : Processing Part~5-02800’
02:27:57 Process 2 not responding. Abandoned during process ‘Defunct : Processing Part~5-02822’
02:27:57 Process 8 not responding. Abandoned during process ‘Defunct : Processing Part~5-02836’
02:28:02 Process 7 not responding. Abandoned during process ‘Defunct : Processing Part~5-03485’
02:28:33 Process 1 not responding. Abandoned during process ‘Defunct : Processing Part~5-04567’