Operating system hangs when shutting down R/3 or database
System is 98% in system mode when shutting down R/3 or database -> operating system hangs
An error in Digital Unix (OSF/1) Version 3.2C: processors mutually lock themselves when releasing shared memory.
Preconditions for the appearance of this problem:
* SMP system (multi-processor machine)
* shared memory size greater than 500 MB
* many processes working in the same shared memory (more than 100:
the exact threshold depends upon the installation).
There is an operating system patch which avoids this problem. It can be ordered from the Digital hotline, order no.: OSF350-055. It will probably be integrated in Digital Unix 3.2D.
The patch should be installed only by experienced system administrators or service personnel.
To activate the patch, a large portion of the main memory is reserved exclusively for shared memory. This portion is therefore no longer available to the operating system. Unfavorable settings can lead to considerable performance losses.
A more exact description of the patch and its configuration can be found in the patch documentation and in the release notes for Digital UNIX 3.2D.
Refer any questions to the Digital Competence Center in Walldorf.
Before installing the patch, you must check your requirements for shared memory in a running R/3 system. The value is used to compute the gh-chunks parameter in the file "/etc/sysconfigtab".
Caution: The gh-chunks parameter must be adjusted when you change the shared memory requirements of R/3 or the database. The parameter is computed from
where pagesize is 8192.
The space requirements can be computed with the following script:
------------------------------
#!/usr/bin/ksh
ipcs -mb |
sed 's/dba/dba /' |
sed 's/sapsys/sapsys /' |
awk '{ sum = sum + $7 } |
END { printf("%d Bytes, %6.4f GBytes, %d gh-chunks\n",
sum, sum/1024/1024/1024, sum/512/8192 + 3) }'
------------------------------
When the operating system is started, the value of gh-chunks controls the size of a storage area which can be used exclusively for the shared memories. This area is no longer available for the operating system.
This value may not be defined too large; otherwise the system will have no resources left for the programs. In this case, the system would begin to page!
On the other hand, to avoid this effect safely, no shared memory should be taken from the normal storage pool. You should therefore add 10% to the computed value in order to cover the management information.
The 10% value should not be assumed for all R/3 installations since:
1) frequently 2/3 of the main memory is used for shared memory and 10%
is too large a reserve and
2) R/3 and the database allocate storage statically, that is the
storage requirements are known exactly.
In the R/3 environment, the exact size must be determined depending on the installation.
Two examples: Installation 1 has 2 GB main memory and requires 1.2 GB shared memory. Another 10% is added in order to have some space for tuning measures.
Installation 2 has 1.5 GB and requires 1.1 GB shared memory according to the script. Only 5 chunks were added to the computed value here as otherwise you would have to deal with a bottleneck.
The patch is installed as follows. A new operating system kernel is required.
1) Unpack the patch in a subdirectory
2) Copy the object modules to /sys/BINARY ( backups !)
3) Generate and copy new operating system kernel
4) Edit file "/etc/sysconfigtab"
5) Restart machine
1. Carry out the following steps when unpacking, where the patch is assumed to be on tape rmt0h:
------------------------------
mkdir /var/tmp/patch
cd /var/tmp/patch
tar xv
------------------------------
2. To copy the patch, carry out the following steps, assuming /bin/sh as command interpreter:
------------------------------
for i in *
do
mv /usr/sys/BINARY/$i /usr/sys/BINARY/$i.exit_patch
cp $i /usr/sys/BINARY
done
------------------------------
3. To generate the new kernel, carry out the following steps:
------------------------------
cd /sys/conf
doconfig -c
cp /sys/
------------------------------
4. Before restarting the operating system, the following lines must be entered in file /etc/sysconfigtab in section "vm":
------------------------------
vm:
gh-chunks=
vm-page-lock-count=256
-------------------------------- where the value gh-chunks is equal to " shared memory / 512 / Pagesize ". Pagesize is 8192 for Digital Unix. The value is computed by the above script.
5. The system must be rebooted once more. Stop as few processes as possible at one time.
Test: The problem occurs only if the shared memory is actually used. Normally a "startsap;stopsap" does not indicate whether or not the problem has been corrected.
IMPORTANT: The patch triggers perfromance problems and should not be
installed as a preventative measure.
Additional key words
shutdown stopsap
No comments:
Post a Comment