SAP System OS Collector – SAPOSCOL in a Nutshell
The SAP System OS Collector (SAPOSCOL) is a platform-independent program that runs in the background of the operating system and collects system information using a segment of shared memory for multiple applications and all SAP instances in one instance. host. These information details can be viewed through transaction code ST06/OS06 in the SAPGUI interface. It is a very useful tool for NetWeaver/Basis administrators and consultants to monitor server performance. SAPOSCOL extracts data in real time from the system, although it does not update automatically, you must click the ‘Refresh’ button to get the updated data. SAPOSCOL collects data from the system every 10 seconds and logs it, and also logs hourly averages for the last 24 hours. It runs autonomously from SAP instances exactly one process per host and collects data from various operating system resources. User can monitor all servers under SAP panorama with this tool. But for the remote server (livecache server) the transaction code is OS07. You can check CPU utilization, physical and virtual memory usage, pool data/swap size, disk response time, utilization of physical disks and file systems, resource load for running processes and even LAN data from the monitoring list.
You can navigate to this tool from SAP Menu->Tools->CCMS->Control/Monitoring->Performance->Operating System->Local->Activity.
If you can’t see any data, that means the OS Collector (SAPOSCOL) is not running (error code: shared memory not available). In this situation, your main task is to fix the saposcol so that it works properly. This usually happens after a new SAP installation or Kernel updates. If you are new to SAP systems, the following guide will be helpful in overcoming the saposcol issue.
Unix/Linux/AIX/Sun/Solaris system:
First, check the permission of the saposcol.exe file, it should be 777 (owner is root in the sapsys group) and the sticky bit should be set to 4750. If you want to know which user is running saposcol, use “ps -ef | grep saposcol “. Now, to change the saposcol file to owner root, sapsys group, mode 4750, log in as root to your Unix system and run the commands as shown below.
cd /usr/sap//SYS/exe/run
chown root sapocol
chgrp sapsys saposcol
chmod 4750 sapocol
You can also run “saproot.sh” in the exe directory to set permissions. Then run saposcol -l as the same owner (root). Check the status of the collector using saposcol -s. After setting the file permissions, you can also use ST06 -> OS Collector -> Click ‘Start’ to run SAPOSCOL.
To stop the OS collector, use saposcol -k. If this command failed to kill the process, you can run “cleanipc 99 remove” (see SAP Note 548699). If this attempt also fails, you must remove the saposcol shared memory key. Run the “ipcs -ma” command and note the shared memory ID on the line containing the saposcol key. Then run the command “ipcrm -m ID”. The shared memory key will be created again the next time you run saposcol.
Sometimes using “saposcol -l” gives a message that it is already running, but when you grep the process using “ps -ef|grep -i saposcol”, it may not show the process. In this situation, you can use an undocumented parameter “saposcol -f”, where “f” means forcefully start the process. When it starts, stop the process in the throttling method using “saposcol -k” and then start it normally using “saposcol -l”.
If saposcol is not already running, you must start it in dialog mode. Login with use adm and follow the steps below,
saposcol -d
collector > clean
collector > quit
saposcol -k to stop the collector.
before reboot
saposcol -d
Collector > exit (you should get a message – Shared memory deleted)
collector > quit
cd /usr/sap/tmp
mv coll.put coll.put.sav
CD
sapocol
“coll.put”, if this file contains the old shared memory and must be removed to start from scratch (See SAP Note 548699, item 7). If you are unable to clear shared memory, try the following commands to clear shared memory:
$ sapocol-kc
$ sapocol -f
If this also fails, you need to reboot from the OS level and it seems you also need a new version of saposcol (see SAP note 19227).
IBM iSeries i5/OS (OS/400, OS/390):
– Check the permissions of the ‘/usr/sap/tmp’ directory and the ‘saposcol.exe’ file, it must be 4755 and the owner must be root in the sapsys group. See SAP note 790639. After assigning permissions, you can run from the operating system command line using ‘SAPOSCOL -l’. To display the status use ‘SAPOSCOL -s’ and to stop the process use ‘SAPOSCOL -k’. You can also run the process by submitting a job at the OS level using
CALL PGM(SAPOSCOL) PARM(-l)
Submit the job to the QBATCH job queue in the QGPL library.
– On iSeries, you might experience strange data when analyzing CPU utilization with tcode ST06/OS06. Even if you are using multiple CPUs, SAPOSCOL can only report CPU usage for the first CPU. Also, you will sometimes find CPU usage reported above 100% in some intervals, if you are running an SAP instance on an unlimited partition where multiple logical partitions are using a shared processor pool. In this situation, make sure that the reported CPU usage for CPU number 0 is the average usage of all CPUs being used in the system. If you want to view the shared CPU partition information, please apply the support packages as per SAP note 994025, including the following patch levels
6.40 device+work package (DW): 182 SAPOSCOL: 69
7.00 availability+work package (DW): 109 SAPOSCOL: 34
When applying these patches and support packs to the system, the new transactions OS06N, ST06N, and OS07N are available for viewing additional information in two sections titled “Host System” and “Virtual System.” These include information about the partition type and the CPU available and consumed in the current partition, as well as the shared processor pool. Therefore, if you are an iSeries user and your SAPOSCOL is not running, chances are you need to install the latest kernel and saposcol patch. (SAP Note 708136 and 753917)
– Another scenario on iSeries, when your saposcol is not running and you cannot start it from ST06/OS06. The problem could be because the R3ADMAUTL authorization list was not accurate. You can solve it like this,
1) Delete QSECOFR *ALL X
2) Change *PUBLIC from *USE to *EXCLUDE
3) Add R3OWNER *ALL X
Now you can start saposcol using tcode ST06/OS06. And you can also start the process from the command line,
CALL PGM(/SAPOSCOL PARM(‘-l’)
If this does not resolve the problem, check whether both programs QPMLPFRD and QPMWKCOL in library QSYS have *USE- authority assigned to user R3OWNER (SAP note: 175852). Otherwise, you need to run the following commands:
GRTOBJAUT OBJ(QSYS/QPMLPFRD) OBJTYPE(*PGM) USER(R3OWNER) AUT(*USE)
GRTOBJAUT OBJ(QSYS/QPMWKCOL) OBJTYPE(*PGM) USER(R3OWNER) AUT(*USE)
You then need to check if the R3OWNER user is part of the R3ADMAUTL authority list (SAP Note: 637174). After this, if you get the error “SAPOSCOL is not running? (Shared memory not available), follow the steps below,
1) Delete shared memory (coll.put) per SAP note: 189072. The location of ‘coll.put’ is: ‘/usr/sap/tmp’.
2) End the QPMASERV, QPMACLCT, QYPSPFRCOL and CRTPFRDTA jobs in QSYSWRK if they are running.
3) Delete temporary user space, WRKOBJ OBJ(R3400/PERFMISC*) OBJTYPE(*USRSPC)
4) ENDTCPSVR*MGTC
5) CALL QYPSENDC PARM(‘*PFR ‘ ‘ ‘) [There are 6 blanks after *PFR and there are 6 blanks making up the second parameter]
6) ENDJOB JOB (xxxxxx/QSYS/QYPSPFRCOL) OPTION (*IMMED) SPLFILE (*YES) [This command must be run for all QYPSPFRCOL jobs found on the system even if they show with *OUTQ as their status]
7) ENDJOB JOB(xxxxxx/QSYS/CRTPFRDTA) OPTION(*IMMED) SPLFILE(*YES) [This command must be run for all CRTPFRDTA jobs even if they show with *OUTQ as their status]
8) RNMOBJ OBJ(QUSRSYS/QPFRCOLDTA) OBJTYPE(*USRSPC) NEWOBJ(QPFRCOLDTX)
9) RNMOBJ OBJ(QUSRSYS/QPFRCOLDTA) OBJTYPE(*DTAQ) NEWOBJ(QPFRCOLDTX) [This object may or may not exist at this time]
10) CALL QYPSCOLDTA *note This program will create a new USRSPC. After the collection services start, there should be a new *DTAQ.
11) Initiate collection services using GO PERFORM, opt 2, and opt 1; OR CALL QYPSSTRC PARM(‘*PFR ‘ ‘*STANDARDP’ ‘ ‘) [There are 6 blanks after *PFR and there are 6 blanks making up the second parameter]. Or, start the collection services from Operations Navigator.
12) STRTCPSVR*MGTC
13) Quit and restart Operations Navigator if it is running. See IBM Authorized Program Analysis Report (APAR) SE12188 for more information.
14) Now start SAPOSCOL from ST06/OS06.
Windows system:
– Go to the Kernel folder in the command line where you will find saposcol.exe. Set full owner permission
for file and folder. Then run saposcol -l (saposcol -d in dialog mode)
– You can also try Start/Stop SAPOSCOL service from Control Panel -> Administrative Tools -> Services (services.msc).
If all other attempts fail, make sure you have the correct version of SAPOSCOL. Get the latest SAPOSCOL from the SAP Service Marketplace for your operating system. Download the SAPOSCOL.SAR file for your Kernel and save it to a directory. Then STOP SAP & SAPOSCOL. Check for Kernel library crashes and don’t forget to back up the library. Then run APYR3FIX and then APYSAP. See OSS note 19466.
SAPOSCOL can also be terminated due to a small amount of internal memory allocation. When this memory gradually fills up during SAPOSCOL runtime, the system writes data out of the buffer. As a result, the next buffer is cleared and SAPOSCOL ends with a dump. Apply the following patches with at least the patch levels specified below:
SAP Release 640: SAPOSCOL patch level 100 and DW patch level 293
SAP Release 700: SAPOSCOL patch level 75 and DW patch level 151
SAP Release 701: SAPOSCOL Patch Level 18 and ILE Patch Level 53
SAP Release 710: SAPOSCOL patch level 36 and ILE patch level 161
SAP Release 711: SAPOSCOL patch level 12 and ILE patch level 48
So it is obvious that if we use different SAP systems on one server with incompatible combination of kernel versions, SAPOSCOL will face a crisis and will not provide data for all systems, even though SAP system functions will run smoothly. This is because we are using the new technology from IBM with EXT Kernels, so it will not allow SAPOSCOL to reside in a Single Level Store (SLS), instead placing it in Teraspace. In this situation, it is obvious that if you run an EXT system with other non-EXT systems, saposcol will run only on one system. To overcome this problem, you must upgrade to EXT Kernel for all SAP systems with the latest patches. Then configure the proper authorization for the SAPOSCOL file and directory as indicated, which will resolve any issues related to SAP OS Collector.