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!
– 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!
Kernel Release 742 SP210
PAS with ASCS (NUC)
AIX 7.1 DB2 10.5 FP3/4 120WP
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)
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
=> default size = 10.000 * 50.000 = 500MB
=> just edit the parameters if your ENQ table size is above 500MB
=> the package size is :
=> 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 😉
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
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:firstname.lastname@example.org] )
Technology Consultant at Q-Partners (www.qpcm.eu )
#V1.1 Added example of 1320810 – Z_ENQUEUE_PERF
#V2.0 style adjustments In cause of new SAP portal