The purpose of this document is to provide some guidelines to analyze the Enqueue performance. It depends of multiple factors and usually is not easy to analyze.
Enqueue calls consist of a communication part and of a processing part, so the first action would be to identify if the problem is a communication problem or a processing problem .
Do you have performance problems on both sides or only on the DI side?
Both sides: There is an enqueue processing problem.
only on DI: There is a communication problem.
As from Netweaver 7.40 using the Standalone Enqueue Server for deployments with more than ONE instance is a must/prerequisite. In this scenario there are some recommendations:
It makes no sense to set number of threads in ENSA (enq/io/max_threads) higher than 4-6:
The working thread (the one which executes requests) exists only one time. So increasing IO thread won't bring much performance, but rather can slow down the server causing:
High CPU contention Lack of CPU resources
ENSA (Standalone Enqueue Server) and Database shouldn't be placed in the same host sharing CPU resources.
How to identify enqueue performance issues
STAD transaction : Checking enqueue time and count (number of enqueues)
In this example we see 10 enqueue calls with a total time of 20ms è 2ms per call (this is a good value on a Dialog Instance, but would be bad on the Central Instance.
SM12 >> Extras >> Statistics:
Big number of enqueue collisions (rejections)?
Activate enqueue logging feauture to identify the application responsible
See Enqueue overload - collecting and analyzing the enqueue log information
High number of costly operations (Read / Backup) ?
READ operations reduce ENSA's performance.
Backup file is not needed when running Standalone enqueue with Replication Server: ERS is designed for a smooth replication and it does its job perfectly.
Enqueue Replication Server naturely increases total duration of enqueue requests.
Access to Enqueue Statistics file (ENQSTAT)
This file is located at "/usr/sap/<sid>/<instance>/Data/ENQSTAT"
It is accessed with every enqueue operation, then it should resides in the host were the enqueue service is located to avoid accesses over the network
You could identify there is an issue with this in the ENSA "dev_enqwork" trace file, see the following example:
[Thr 139878603158592] Tue Jun 27 14:35:00 2017
[Thr 139878603158592] EnqMemMakeNewStamp: new stamp: 1 498563300 120000
[Thr 139878603158592] *************** EnqStatistics ***************
[Thr 139878603158592] Tue Jun 27 14:35:03 2017
In this case we see it took around 3 seconds to write in the file.
enque/repl/shadow_file_name is set in the ASCS profile
This parameter sets where the replication table is stored, in this case is in the file system instead of shared memory
This slow down the replication process (even more if it's NFS mounted) and can influence also the performance of the Enqueue processing
When enqueue server is placed in the Central Instance check the I/O performance of the disk:
Maybe that disk is used for heavy frequent I/O operations of a database or other applications and processes?
Any system activities like swap file, archive, backup?
What if you separate the backup file from the landscape by assigning it a private disk to be able to use it exclusively?
Wait time should be smaller that processing time, otherwise you would see semaphore 26 often in SM50 and in ST02 semaphore statistics by using "enqt" tool.
See Enqueue performance analysis with enqt