ASCS ENQ performance tuning

Hello SAP Administrators,

the ASCS is not really a new topic, but I guess most of you never changed ASCS parameters after the installation/migration of it. In the most cases the defaults are good enough, but for big system environments you have to optimize them.

In a good sizing/parametrization you should take care also of the ASCS parameters!

Basics

ASCS

– Messages Server

– Enqueue Server

Every new system will be installed with ASCS and the option for ERS. ERS is the Enqueue Replication Service which take place in a cluster scenario.

The future is the standalone enqueue server which is just another name for the ENQ service inside the ASCS.

There are a lot of documents and notes regarding the enqueue server and I will just collect them here with some hidden parameters and also show you my tests.

In the past integrated ENQ Server can be administrated in the CI ABAP profile via RZ10 or directly in the filesystem.

The new ASCS can only be configured via the profile on the filesystem. It is not visible anymore via RZ11/RZ10 for change. Don’t believe what you see in RZ11! You just see the defaults or any old value which were note deleted from the profile. It is essential that the binaries from (A)SCS and ERS instance are from the same binary set.

Please delete all old enqueue parameters from default and instance profiles!

Test environment:

Kernel Release 742 SP210

PAS with ASCS (NUC)

    AIX 7.1

    DB2 10.5 FP3/4

    120WP

Application Server

    20x linux vmware

    150WP per server

    =>3000WP

Calculate some parameters

1) calculation of enque/server/max_requests

workprocesses + enqueue table size in MB * 20|25 (NUC|UC)

=> 3120 + 1024 * 20 (because we have a NUC system)

=> 23600

2) calculation of the snapshot area

the snapshot memory area must be greater than the enqueue table sizeThere is no restriction or recommendation about the better number of packages and its size because this depends on the business process1903553 – Standalone Enqueue Server (ENSA) and snapshot packages

ENQ table size: 1024MB

snapshot memory=enque/snapshot_pck_ids*enque/snapshot_pck_size

=> default size = 10.000 * 50.000 = 500MB

=> just edit the parameters if your ENQ table size is above 500MB

=> the package size is :

1.000.000*80.000

80.000.000 KB

80 GB

=> so in this case we can definitely reduce the parameter, but our tests have shown that this settings are working pretty good

3) Client profile (application Server):

    enque/process_location = REMOTESA

    enque/serverhost = <hostname of the enqueue-server>

    enque/serverinst = <instance number of the enqueue-server>

    enque/deque_wait_answer = TRUE

4) ASCS instance profile:

    #If you set this parameter to 0, the lock table is not placed in any pool

    ipc/shm_psize_34 = 0

    #default 50KB => parameter value 50.000 (30.000 and 100.000 possible values)- determines the size of

    #the individual packets. A lock entry requires about 1 KB.

    enque/snapshot_pck_size = 80000

    #enqueue table size

    enque/table_size = 1024000

    #default: 10.000 (10-1.000.000 possible) => newer releases default: 1600 - determines the

    #maximum number of snapshot packets

    enque/snapshot_pck_ids = 1000000

    # hidden parameter, see note 1850053 - ENSA suspended the ERS network connection

    enque/ni_queue_size = 1000

    #default: 1000 - parameter determines the number of processes that can be connected to the

    #enqueue server. Set the parameter to the same value as the total number of work processes in the system

    enque/server/max_clients = 5000

    #new name for 'max_query_requests' is 'enque/server/query_block_count' since release 800

    enque/server/max_query_requests = 5000

    # default 1000 - maximum number of enqueue requests that can be processed simultaneously

    enque/server/max_requests = 23600

    #Max. number of subsequent asynchronous requests - a synchronous request is forced

    #every n asynchronous request. You specify this number n in this parameter.

    enque/async_req_max = 5000

    #The number of I/O threads - a value higher than 4 has never resulted in an increase in throughput.

    enque/server/threadcount = 8

    #parameter specifies how many memory blocks (each has 32 KB) are reserved in the

    #replication server for transferring the data

    enque/server/query_block_count = 5000

    #ENQ server name

    rdisp/enqname = $(rdisp/myname)

    #mechanism for communication between the threads - with value true, the communication

    #is quicker but generates a heavy load on the system

    enque/server/use_spinning=false

undocumented parameters which have to be tested by your own:

    enque/server/req_block_size = 13333

    enque/enrep/req_block_count = 14000

We have tested a lot with the threads and the snapshot size. That settings which you see above are the final setup. In the past we have a lot of ENQ time (up to 30%) in our mass processing batch. We could reduce this to about 1-2%.

This reduced the overall time for the massive parallism for about 40-60%!!! Nobody expected such a big benefit for this processes. But it depends on your application and the current ENQ time if the improvements can also take place in your environment.

Please analyze your ASCS and Application Server profile for this parameters. If you see a lot of ENQ time while analyzing with TX STAD or SE30, you should check the performance of your ENQ server.

This can be done with SM12 (OK Code: test/dudel). Please use the following note how to do this: 1320810 – Z_ENQUEUE_PERF

Here are an example of a small test system without application server (I will add some screenshots from the big environment in some weeks):

=> you can see that most of the requests are <= 1ms

=> more intresting is a an environment with more application servers in cause of the RTT (network round trip times)

Another indicator could be the report SAPLSENA. If you see in TX ST03 high times on this report you should take care of it. Also when you see the report a long time in SM66/SM50 this is an indicator of bad ENQ performance.

A good starting point for your analyze could be this blog on sap-perf.ca

and than => happy tuning 😉

Details:

920979 – Out of memory im Standalone-Enqueue-Server

1850053 – ENSA suspended the ERS network connection

1903553 – Standalone Enqueue Server (ENSA) and snapshot packages

654744 – Several errors corrected in the standalone enqueue server

sap.help ENQ Server

If you have any further questions, don’t hestate to comment the blog or contact me or one of my colleagues at Q-Partners ( [info_at_qpcm_dot_de | mailto:info@qpcm.de] )

Best Regards,

Jens Gleichmann

Technology Consultant at Q-Partners (www.qpcm.eu )

Edit History:

#V1.1 Added example of 1320810 – Z_ENQUEUE_PERF

#V2.0 style adjustments In cause of new SAP portal