728x90


Problem(Abstract)

A long running session may allocate huge memory pool if DONTDRAINPOOLS environment variable was enabled on server's startup

Symptom

You notice that long running sessions have large memory pools allocated (can be up to several gigabytes).

onstat -g ses


session                                      #RSAM    total      used       dynamic 
id       user     tty      pid      hostname threads  memory     memory     explain

<...>
229697969 user1 -        -1       192.168. 1        94208      87480      off 
229694677 user3 162      21785    host1    1        7140388864 946472     off 
229673199 user5 -        29050    host1    1        118784     92752      off 
229668414 user1 -        -1       192.168. 1        131072     107280     off 
229667792 user1 -        -1       192.168. 1        102400     69608      off 
229667782 user1 -        -1       192.168. 1        106496     85304      off 
229667776 user1 -        -1       192.168. 1        94208      87480      off 
229657782 user6 494      11416    host1    1        102400     71400      off 
229634560 user2   -        -1       192.168. 1        94208      67504      off 
229630635 user1 -        -1       192.168. 1        131072     107280     off 
229630075 user1 -        -1       192.168. 1        102400     69608      off 
229630064 user1 -        -1       192.168. 1        106496     85304      off 
229630055 user1 -        -1       192.168. 1        94208      87480      off 
229626281 user7 406      125      host1    1        139264     76040      off 
229623552 user5 -        25571    host1    1        471040     399904     off 
229617823 user8  -        6118     host1    1        798720     693920     off 
229612008 user4  -        -1       192.168. 1        90112      67472      off 
229611119 user4  -        -1       192.168. 1        90112      67472      off 
229605475 user9   951      7697     host1    1        348160     121784     off 
229588448 user10 1207     28006    host1    1        737280     521296     off 
229578372 user4  -        -1       192.168. 1        90112      67448      off 
229576124 informix -        29244    host1    2        131670016  129610816  off 
229565621 user1 -        -1       192.168. 1        131072     107280     off 
229565020 user1 -        -1       192.168. 1        102400     69608      off 
229565011 user1 -        -1       192.168. 1        106496     85664      off 
229565004 user1 -        -1       192.168. 1        94208      87480      off 
229546565 user2   -        -1       192.168. 1        94208      67504      off 
229531732 user2   -        -1       192.168. 1        98304      90568      off 
229531707 user2   -        -1       192.168. 1        94208      84976      off 
229519448 user3 154      19733    host1    1        753565696  30887704   off 
229512098 user3 133      16367    host1    1        851968     626672     off 
<...>

However, when you look at the session information, most of the allocated memory is shown as free.

onstat -g ses 229519448 

session           effective                            #RSAM    total      used       dynamic 
id       user     user      tty      pid      hostname threads  memory     memory     explain 
229519448 billproc -         154      19733    mobis    1        753565696  30887704   off 

Program :
-

tid      name     rstcb            flags    curstk   status
241358080 sqlexec  9a0ea1170        --BPR--  11263    ready-

Memory pools    count 3
name         class addr              totalsize  freesize   #allocfrag #freefrag 
229519448    V     80cb19040        753258496  722660672  604        31        
229519448*O  V     7e51bd040        12288      9000       1          3         
229519448_S  V     7eed67040        294912     8320       29         3         

But in time, the amount of allocated memory keeps growing which may result in additional segments allocated for the virtual portion of shared memory.

online.log

<...>
13:35:08  Maximum server connections 2943 
13:35:08  Checkpoint Statistics - Avg. Txn Block Time 0.004, # Txns blocked 63, Plog used 1561232, Llog used 180616

13:35:14  Requested shared memory segment size rounded from 409600KB to 425984KB
13:35:15  Dynamically allocated new virtual shared memory segment (size 425984KB)
13:35:15  Memory sizes:resident:27820032 KB, virtual:9899008 KB, no SHMTOTAL limit
13:35:15  Segment locked: addr=987000000, size=436207616
13:35:50  Requested shared memory segment size rounded from 409600KB to 425984KB
13:35:50  Dynamically allocated new virtual shared memory segment (size 425984KB)
13:35:50  Memory sizes:resident:27820032 KB, virtual:10324992 KB, no SHMTOTAL limit
13:35:50  Segment locked: addr=9a1000000, size=436207616
<...>

Cause

Having DONTDRAINPOOLS environment variable set on server's startup changes behavior of Informix memory manager to keep the memory in the local session and not release it back to the main memory pool until that session terminates and frees its pool.

Diagnosing the problem

Run 'onstat -g env' and see if the DONTDRAINPOOLS environment variable was set on startup:


Server start-up environment:

Variable Value [values-list]
DBDATE dmy4
DBDELIMITER |
DBMONEY .
DBPATH .
DBPRINT lp -s
DBTEMP /tmp
DONTDRAINPOOLS 1
IGNORE_UNDERFLOW 1
INFORMIXCONRETRY 1
INFORMIXCONTIME 10
INFORMIXDIR /informix/mobserver/inf11
<...>

Check messages in online.log file produced during server's startup if there is a message like "Server is disabling pools draining".

Resolving the problem

- You can run 'onmode -F' to free allocated memory.

- Unset DONTDRAINPOOLS environment variable and restart the Informix server.


http://www-01.ibm.com/support/docview.wss?uid=swg21627991

728x90

+ Recent posts