MDM Performance - Read & Write Lock

[Former Member]

Hello Experts,

We have enabled Max thread per operation = AUTO in MDS.ini to use multiple cores to handle the requests. Currently we have 4 CPU for the MDM server.I could see the threads has been distributed across all 4 CPU's. Current Version used : MDM 7.1 SP09

Does MDM server always route the write request to one of the CPU whereas the read request is distributed across all available CPU's?

Just to elaborate : 4 Users logged in to Data Manager. 2 Users try to create a record (Write) and other 2 does search & match (Read)

In this case, how 2 write request and 2 read operation will be treated at server level?

• Does the 2 write requests will be queued in CPU 1?
• Does other 2 read requests are distributed to CPU 2 and CPU 3 ?

Kindly confirm on this

Regards,

Antony

[Former Member · Accepted solution]

Hi Antony,

Only thing that can be said here is that no of threads will get automatically generated depending on the number of cores that are available.So if you 4 systems with dual core processor then number of threads will be calculated as 4*2 - 1 = 7.This will get calculated automatically when you keep Max Thread per Operation as AUTO.

I do not think we can premeditate whether a particular write operation's thread would lead to CPU1 or other,as this depends much upon concurrent operations and load on CPUs.

Decreasing the number of Data Manager usage in single LAN and resorting to better network will definitely help here.

Thanks,

Ravi

[Former Member · Accepted solution]

Hi Ravi,

Thanks for the response.

The overall initention is to understand if mulitple write requests(W1,W2) are send to MDS (Via Data Manager, Java API) whether the write operations are carried in sequence ?

As i understand the write operations (W1) does a exclusive repository write lock , does it mean the other write requests (W2) are kept on hold till the lock gained by W1 is released?

Currently we have multiple users logged in via portal and data manager as well. Their response time of the requests are very slow. Hence this request

Regards,

Antony

[junwu · Accepted solution]

what they are doing in portal and DM?

anyway if your cpu is 100% used, the slowness is understandable, right?

[Former Member · Accepted solution]

Hi Antony,

One workaround I would suggest is to get rid of multiple users trying to access server at one instance when CPU utilization is high.

To monitor this you can use CLIX Command and identify the user because of whom entire repository is locked and based on that result , request the user to log off from current search operation until following locks are cleared (X-Exclusive, S-Shared)

Alphabet “X” represents exclusive lock and this happens when lot of activities keep server busy increasing CPU Utilization. We cannot define the exact time for each lock. It depends on the number of processes and no. of users logged on to specific repositories.

Shared lock (S) is another type with which users can still perform search and use client systems. With exclusive lock, it will be difficult for users to access clients and parallel operations will be on hold until this lock is cleared.

Regards,

Mir Kasim Ali

[Former Member · Accepted solution]

Hi Mir,

Thanks for your response.

With your comments , "With exclusive lock, it will be difficult for users to access clients and parallel operations will be on hold until this lock is cleared" , following are conclusion of my understanding

1. At single of point of time, only 1 write request can be processed for a repository
2. All other read & write requests for that repository will be queued till the write lock is completed.
3. This behaviour is independent of the number of CPU's which we use. (Multiple write requests for the same repository cant be processed parallely using multiple CPU's)

Please confirm my above understandings

Regards,

Antony

[Former Member · Accepted solution]

I would apparently agree with your understanding but would also suggest to cross check with SAP, if you are facing major challenge in your system landscape.

Regards,

Mir

[Former Member · Accepted solution]

Hi Mir,

Thanks for the confirmation

Would request any of the SAP Mentor in this forum to confirm on this please

Thanks & Regards,

Antony

[junwu · Accepted solution]

write lock is at row level, unless it is batch update.

[Former Member · Accepted solution]

Hi Antony,

I agree with points mentioned above about the behavior of MDS.

With regard to point 3 - It is one of deciding factors for the duration for which there will be exclusive lock on the repository.Increasing this will certainly decrease exclusive lock on repository and hence less wait time for the other write operations.

Thanks,

Ravi

[junwu]

why this matters to you?

[Former Member]

Hi,

Currently we are facing the performance issue and during our analysis we found CPU utilization is more than 100 % during the peak time.

So need to understand the handling of requests at server side to do remedial steps

Kindly provide response

Regards,

Antony

[junwu]

are all the cpu used? all are 100% ?

[Former Member]

Hi,

I could see all the 4 CPU's are used and all are 100 %. We understand the CPU capacity needs to be enhanced.

However we also need to understand if all the write requests are queued at one CPU, then we can increase that CPU capacity more than the other 3

Thanks in advance

Regards,

Antony

[junwu]

i don't believe mdm is doing in that way