SAP on IBM i – Update week 47 2014: Performance Considerations when Upgrading to Kernel Release 7.4x
When you are planning an upgrade or update to a higher SAP release, you have always been advised to test carefully and check SAP Notes for potential additional resources that may be required for the new release. For example, SAP Note 1974405 explains that you may need 5 to 10 percent more CPU resources when upgrading to SAP ERP Central Component 6.0 EHP7. However, SAP recently got feedback from customers, that the additional CPU resources may exceed that in some cases. These customers have experienced longer response times after upgrading to a release that contains SAP_BASIS at release 7.40 and a kernel at release 7.40 or higher (for example by upgrading to SAP ERP Central Component 6.0 EHP7).
Compared to release 7.2x, the SAP kernel has undergone major changes in 7.4x, in particular in the area of memory management and process communication. To get the best performance from this kernel, SAP has put together SAP Note 2098347 with a list of recommendations, among them:
- Configure a standalone enqueue server as described in SAP Note 2013043.
- Make sure to have a current patch level, at least 7.41 patch level 47 or 7.42 patch level 14.
- For lib_dbsl in release 7.41 install at least patch level 115, for lib_dbsl in release 7.42 install at least patch level 29 (see SAP Note 2101009).
- Use profile parameter ES/TABLE=SHM_SEGS along with as4/MAXSHR64=2048. Please note that ES/SHM_BASE_ADDR should not longer be set explicitely with kernel release 7.4x (see SAP Note 808607).
- Set profile parameter rdisp/queue/use_events_for_dispatching=on (default in 7.42 patch level 14, see SAP Note 2050408).
- Verify the settings of your memory related profile parameters, because beginning with 7.40 all defaults are calculated based on the physical size of the main storage (parameter PHYS_MEMSIZE, see SAP Note 2085980).
- Verify the buffer settings in transaction ST02, in particular the CUA buffer. With 7.40, the maximum number of entries is no longer calculated from the buffer size but explicitly set through profile parameter rsdb/cua/max_objects (see SAP Notes 702728 and 2044752).
SAP Note 1387644 recommends setting the profile parameter SETENV_xx = LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K for the operating system AIX. For the operating system IBM i, no significant improvement was noticed as a result of setting this parameter. Therefore, we do not recommend setting this parameter. If you still want to set the parameter, make sure that the PTFs 5770999-MF59805 for IBM i 7.1 or 5770999-MF59810 for IBM i 7.2 are applied.
If additional settings that help the overall performance of the 7.4x kernel are identified, SAP will update SAP Note 2098347. Please always reference the note to get the latest information.
Hello Mr. Bartels,
thanks a lot for this information.
I'm going to do an EHP3 for CRM 7.0 upgrade soon (starting from EHP1 for CRM 7.0) so this will be interesting to know.
I will share my experience on this blog.
Although in my 3-system-landscape (DEV-QAS-PRD) I have just central instance systems without any additional application server so let's see whether I need a standalone enqueue server or not.
One last question to SAP note 2098347:
"4. Setzen Sie den Profilparameter SETENV_xx = LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K in allen Parametern."
-> do you mean "in allen Profilen"?
Kind regards
Rüdiger Höckel
Hello Mr. Höckel,
thank you for your feedback. You are right with your assumption, I have updated SAP Note 2098347 accordingly.
Kind regards,
Christian Bartels.
In an earlier version of this blog entry we had recommended to follow SAP Note 1387644 and set profile parameter SETENV_xx = LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K. However, a customer has experienced serious problems under heavy load some time after setting this parameter. The root cause of these problems are still under investigation, but until we know them we do not recommend to set this parameter. We will update this blog entry when we get more information.
Just finished the first update (from CRM 7.0 EHP1 to EHP3).
So kernelwise I had to go from 7.20 EXT #600 to 7.42 #30.
After having applied the latest kernel patches (dw 30, lib_dbsl 29 etc.) -as SUM used the SAPEXE_28 files- and implementing the recommended profile parameters (SAP note 2098347 and 2085980) I restarted the system.
So far I didn't configure a standalone enqueue server.
Of course it is a bit early to say but I think the system runs a bit more smoothly than before the changes from SAP note 2098347.
But this is a test system anyway with only a handful users - the production system will follow in late February/early March.
Another question:
On my test server there are eight different SAP systems running (RAM = 128 GB).
Speaking of profile parameter PHYS_MEMSIZE:
would it make sense to lower the value to e.g. 40960 instead of using the whole memory available?
Kind regards
Rüdiger Höckel
Hello Mr Höckel,
with kernel releases 7.40 and higher, the default values of some memory-related profile parameters, such as rdisp/PG_SHM, abap/heap_area_total, em/initial_size_MB and em/max_size_MB depend on the value of PHYS_MEMSIZE. If you had set these profile parameters manually, PHYS_MEMSIZE does not change your settings. However, if you were running with defaults before, leaving PHYS_MEMSIZE at the actual physical size for all eight SAP systems may result in too large values for the other parameters. On IBM i, this would mainly result in too much temporary storage being allocated, page fault rates or other performance characteristics should not be affected.
To define a reasonable value for PHYS_MEMSIZE, you should look at all the eight SAP systems in the partition: If they all have about the same size and importance, than you could select PHYS_MEMSIZE as 1/8 of the available main storage size, which is 16 GB. If some SAP systems are more important than others, you could divide the 128 GB into chunks of different sizes.
In general, the new approach of PHYS_MEMSIZE is just an attempt to make storage management easier for customers. There are no absolute values that are "right" or "wrong". In the end, you will have to look at the systems (ST02) and decide afterwards if the storage and buffer sizes are sufficient, or if they need some fine-tuning.
Kind regards,
Christian Bartels.