You can monitor use of memory that your UDR allocates (explicitly or implicitly) with the following options of the onstat utility:
You can specify a particular session identifier after the ses keyword. If you do not include a session identifier, onstat -g ses outputs a one-line summary for each active session. Look for any session whose memory allocation or usage steadily increases.
Internally, the database server organizes memory allocations into memory pools by duration. You can specify a particular pool name after the mem keyword. If you do not include a pool name, onstat -g mem outputs a one-line summary for each memory pool. To detect memory leakage, look for any pool whose memory allocation or usage steadily increases.
Monitoring memory is useful for tracking down memory leakage. Memory leakage occurs when memory remains allocated after the structure that holds its address was deallocated. There is no way to access the memory once its address is gone. Therefore, the memory remains with no way to remove it.
Suppose that the onstat -g ses command produces the following sample output:
session #RSAM total used
id user tty pid hostname threads memory memory
24 informix - 0 - 0 8192 5880
23 informix - 13453 bison 1 6701056 6608512
8 informix - 0 - 0 8192 5880
7 informix - 0 - 0 16384 14344
6 informix - 0 - 0 8192 5880
4 informix - 0 - 0 16384 14344
3 informix - 0 - 0 8192 5880
2 informix - 0 - 0 8192 5880
ps auxw | grep 13453
Suppose also that your DB–Access session is hooked to session 23 (the italicized line in the preceding sample output).
You can determine the session identifier of the DB–Access session on UNIX or Linux with the following command:
ps auxw | grep 13453
You
can now obtain information about memory-pool usage with the
-g mem option of onstat:
onstat -g mem
Suppose that the preceding onstat command generated the following sample output (some output lines are omitted for brevity):
Pool Summary: name class addr resident R a002018 res-buff R a118018 global V a18a018 mt V a18e018 smartblob V a192018 ... 23 V a3e0018 24 V a3e2018 23.RTN.SAPI V a40c018 23.CMD.SAPI V a3ee018 ...
Figure 88 shows the lines of the onstat -g mem output that indicate user memory allocations.
Each memory duration has a separate memory pool. The three letters before "SAPI" identify each memory pool. The following table shows the memory-pool names for regular and advanced memory durations.
After you determine a specific session identifier or memory-pool name that exhibits a problem, you can find out which specific kind of memory is affected with the -g ufr option of onstat. The -g ufr option of onstat shows memory fragments by usage. For example, the following onstat command captures a snapshot every 30 seconds of memory pools that session 23 uses:
onstat -g ufr 23 -r 30
Sample output for the preceding command follows:
Memory usage for pool name 23:
size memid
2152 log
2016 ostcb
2600 sqtcb
8472 gentcb
1664 osenv
6392648 sqscb
792 filetable
112 rdahead
120 overhead
96 scb
416 sapi
3296 fragman
18808 opentable
280 hashfiletab
10056 temprec
592 GenPg
224 ru
56 sort
94848 ralloc
In the preceding sample output, the main memory consumer is sqscb.
Any memory leakage from a DataBlade API function would show up in the memid column entry labelled sapi. For more information on the onstat command, see the IBM Informix: Administrator's Reference.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]