Skip to end of metadata
Go to start of metadata


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.

General Recommendation

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.

By activating Enqueue logging Mode 8 the current throughput is display together with other key figures and shows a summary per second.
To activate it :      enqt pf=<ASCS/SCS instance profile> 81 1 8
To deactivate it after some minutes:  enqt pf=<ASCS/SCS instance profile> 81 2
The output is written in ENQLOG99 in the ASCS/SCS work directory

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.


>> 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]
[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

  • No labels