Category: UNIX for SAP

Finding how much memory is available on Linux system may probably, not seem to be a complicated task. But do we really know how to extract this information correctly? I can assure you that this information is a little bit more difficult to find out, than it seems to be.
The information from ST06 is not accurate and if you want to check it out from OS level, you need to know exactly where to look.
The command for finding out the memory information is the free command:

free -m displays the memory in Mb, the free -g presents the results in gigabytes and if you add the “t” option, it will add also display the swap information:

Let’s have a look on the command and see what do the values displayed mean?

(1) => the amount of physical memory the server has
(2) => the amount of memory that is in use now
(3) => the amount of memory that is currently free
(4) => the amount of shared memory is currently used by the system
(5), (6) => the amount of cached memory that the kernel is using for filesystems buffers, etc …
(7) => the amount of memory that is really used
(8) => the amount of memory that can be free when the linux kernel will try to release it, if an application tries to allocate more that what it is free at (3). It is calculated from the values from the first line: free + buffers + cached (3) + (5) + (6)

Conclusion:

The amount of free memory from the second line cannot be considered entirely free, in case SAP and databases are running on that server, because some of the cached memory is already actively occupied by the SAP shared memory and database caches and these memory areas are needed by the applications.
So what amount of memory can be really considered available in case of need? That would be the Cached memory – Shared memory that is 2116 Mb.
This can also be calculated also from /proc/meminfo easily by the difference between Cached and Shmem 13114880 kb – 10946292 kb = 2118 Mb

Additional information:

1382721 – Linux: Interpreting the output of the command ‘free’

The situation of the file system full for /usr/sap is frequently met. Probably that the first thing that any admin would do is to check if he can cleanup any core files on the FS.
In order to have an overview and also to avoid this manual check/cleanup, I created a script to check the existence, time stamp and size of such file and send this information via email.
Also if the file is older than seven days this will be deleted, having enough time to analyze the cause for the generation of the file.
Here is how the script looks like:

#!/usr/bin/ksh
cd /usr/sap/SID/DVEBMGS*/work
FILE1=$(ls -l core |grep -v grep | grep -cw core)
FILE2=$(find . -name core -mtime +7 | grep -v grep | grep -cw core)
if [ $FILE1 != 0 ]
then
echo "There is : $(ls -l | grep -cw core) core
with the name : $(ls -l core)
and size : $(du -h core)
space left on FS :
$(df -h core)
$(hostname), $(date)" |
/usr/lib/sendmail -v email@domain.com
else echo "no core - do nothing"
fi
if [ $FILE2 != 0 ]
then
(rm core) && (echo "A core file older than one week has been deleted on $(hostname), $(date)" : [$(ls -l core)]) |
/usr/lib/sendmail -v email@domain.com
else echo "no core older than one week"
fi

This is how such an email should look like, if any cores are found:

There is : 1 core 
with the name : -rw-------   1 sidadm   sapsys   90001069 Mar 19 16:12 core
and size :   86M	core
space left on FS :
Filesystem             size   used  avail capacity  Mounted on
hostname:/usr/sap   1.0G   175M   849M    18%    /home/sidadm
hostname, Thu Mar 24 10:10:00 CET 2017