FYI - The issue is also present in Bash release 5 (5.0.0(1)-release).

In case the script /usr/lib/tuned/sap-netweaver/script.sh should remain in place and part of tuned-profiles-sap, the package will depend on the "bc" package, which is part of BaseOS. Because the bc package is not part of the Minimal Install environment group, a dependency to bc should be explicitly added.

Thanks for the report and the analysis!

Removing the script is fine with me. But it's funny that the script is there in the first place, because the RHEL-7 defaults are exactly the same.

I discussed the issue with my colleague Frank Danapfel. There might be good reasons to keep the script, in case a customer has lowered the defaults of kernel.shmmax and kernel.shmall (for example due to a misconfiguration).

Also in BZ 1701394 which is about a similar issue regarding kernel.sem, the last entry was:
Thanks for info, we will probably add conditional rule to the Tuned profile, i.e. it will increase the value only if it is lower.

So maybe the best approach would be to keep the script and fix the error, and decide later if we want to remove it in future RHEL releases, for example based on experiences with customer cases.

OK, I see two options then:
1. use bc in the existing script
2. using the Tuned's 'sysctl' plugin and a conditional rule instead of having a script do the work. However, we'll need a way to calculate the values of the parameters. To do that, we could either:
   a) Add support for arithmetics in tuned profiles. I think it would be best to create built-in functions for addition, multiplication, etc., such as ${add:value1:value2} and ${multiply:value1:value2}.
   b) Add specialized built-in functions to calculate the shmall/shmmax values.

I think I'd prefer option 2b. It would save us from adding the dependency on 'bc' and from having to run a bash script (which would speed up applying the profile a bit). I also prefer it over 2a, as I think 2b would be more readable.

Would be great if the fix for this issue could be in RHEL 8.1.

(In reply to Ondřej Lysoněk from comment #5)
> OK, I see two options then:
> 1. use bc in the existing script
> 2. using the Tuned's 'sysctl' plugin and a conditional rule instead of
> having a script do the work. However, we'll need a way to calculate the
> values of the parameters. To do that, we could either:
>    a) Add support for arithmetics in tuned profiles. I think it would be
> best to create built-in functions for addition, multiplication, etc., such
> as ${add:value1:value2} and ${multiply:value1:value2}.
>    b) Add specialized built-in functions to calculate the shmall/shmmax
> values.
> 
> I think I'd prefer option 2b. It would save us from adding the dependency on
> 'bc' and from having to run a bash script (which would speed up applying the
> profile a bit). I also prefer it over 2a, as I think 2b would be more
> readable.

Alternatively, we could just rewrite the script in python. That would be the simplest solution and we would not have to clutter up our function list with profile-specific functions.

Rewriting the script in a language which supports larger integer values is certainly a good option and in this case should not take very long.

However, I suggest to no longer use the script but set shmmax and shmall to the RHEL 8 default of 18446744073692774399, for the following reasons:

The referenced SAP note 941735 "SAP memory management system for 64-bit Linux systems" says:

--->
kernel.shmmax
This kernel parameter specifies how large an individual SysV Shared Memory Segment is allowed to be. 
The value is specified in bytes, so "214748364800", for example, allows segments of 200 GB in size.
By default, the Linux distributions already set extremely large values (RHEL: 18446744073692774399, SLES: 18446744073709551615); we recommend that you retain these unchanged.

kernel.shmall
This kernel parameter specifies how much SysV Shared Memory is available in the Linux system as a whole. 
The value is specified in 4 KB blocks, so "52428800", for example, allows 200 GB of SysV shared memory in the entire Linux system.
By default, the Linux distributions already set extremely large values (RHEL: 18446744073692774399, SLES: 1152921504606846720); we recommend that you retain these unchanged.
<---

I confirmed with the author of this SAP note that this SAP note is valid for all 64-bit Linux distributions and for all SAP kernel versions from 6.40 to the most recent ones.

I also checked the change history of SAP note 941735 and found that the last version of that note which does not recommend to use the default very high values of 18446744073692774399 was version 8, dated 12-Nov-2009. The first version which recommends to use the default values was version 9, dated 09-Dec-2014. The current version is 11, dated 04-May-2018.

I am now waiting for a final confirmation that this recommendation is valid for all supported RHEL releases from my SAP contact and will then update this bug again.

I just have been notified by our SAP contact in the SAP LinuxLab that the recommendation to use the default high value of 18446744073692774399 for shmmax and shmall is valid for all SAP NetWeaver installations on RHEL 7 and RHEL 8.

So from my point of view we can set kernel.shmmax and kernel.shmall to the value of 18446744073692774399 unconditionally
in file /usr/lib/tuned/sap-netweaver/tuned.conf for RHEL 7 and RHEL 8.

Regards,
Bernd

Sounds good, thanks.

Upstream pull request:
https://github.com/redhat-performance/tuned/pull/190

QA_ACK+ RHEL8.1

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3633