memory used by a session
Frank saw two Java application sessions on IDS 11.50.FC8 each consuming over 200 MB of session memory, forcing many extra virtual memory segments. Respondents suggested checking 'onstat -g stm <sid>' for prepared statements never freed, and 'onstat -g ses <sid>' for PDQ usage; John Miller noted Java code that relies on garbage collection rather than explicitly closing/freeing statements lets them accumulate. Frank confirmed no PDQ was involved and that the sessions were indeed piling up prepared statements, pointing to the application needing to free them.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Folks,
You can see the two sessions below occupied excessive amount of memory (
marked ). It is a Java application.
Any guess/ideas... what the big memory are holding for? Why IDS need so
big memory size for the two guys? ( what possible data/info in it?)
( Many Virtual memory segments were added for it)
Thanks,
Frank
[informix@maggie ~]$ onstat -g ses
IBM Informix Dynamic Server Version 11.50.FC8 -- On-Line -- Up 31 days
20:18:19 -- 7596160 Kbytessession #RSAM total used
dynamic
id user tty pid hostname threads memory memory
explain
17661248 informix - 0 - 0 12288 11872
off
17661218 saapmgr - 11880 olive 1 122880 87816
off
17661214 saapmgr - 11864 olive 1 126976 87776
off
17661213 saapmgr - 11860 olive 1 131072 87920
off
17499445 saapmgr - -1 olympia- 1 81920 65928
off
17499441 saapmgr - -1 olympia- 1 81920 65928
off
17499439 saapmgr - -1 olympia- 1 223924224 212080344
off <====This ONE
17499183 saapmgr - -1 olympia- 1 81920 65928
off
17499180 saapmgr - -1 olympia- 1 81920 65928
off
17499173 saapmgr - -1 olympia- 1 81920 65928
off
17499168 saapmgr - -1 olympia- 1 81920 65928
off
17499162 saapmgr - -1 olympia- 1 81920 65928
off
17499156 saapmgr - -1 olympia- 1 81920 65928
off
17499151 saapmgr - -1 olympia- 1 81920 65928
off
17499145 saapmgr - -1 olympia- 1 226394112 211701616
off <====This ONE
17495850 saapmgr - 22386 marvin 1 151552 105920
off
17495812 saapmgr - 22188 marvin 1 155648 105792
off
17495783 saapmgr - 22010 marvin 1 155648 105552
off
--e89a8f6426f435cc3504c51e4b56
You could check to see if they are holding open prepared statements. Issuing
onstat -g stm <sid> would show you the statements that they have prepared and
not freed.
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK
Sent: Wednesday, July 18, 2012 12:50 PM
To: ids@iiug.org
Subject: memory used by a session [27657]
Folks,
You can see the two sessions below occupied excessive amount of memory (
marked ). It is a Java application.
Any guess/ideas... what the big memory are holding for? Why IDS need so big
memory size for the two guys? ( what possible data/info in it?)
( Many Virtual memory segments were added for it)
Thanks,
Frank
[informix@maggie ~]$ onstat -g ses
IBM Informix Dynamic Server Version 11.50.FC8 -- On-Line -- Up 31 days
20:18:19 -- 7596160 Kbytessession #RSAM total used
dynamic
id user tty pid hostname threads memory memory explain
17661248 informix - 0 - 0 12288 11872
off
17661218 saapmgr - 11880 olive 1 122880 87816 off
17661214 saapmgr - 11864 olive 1 126976 87776 off
17661213 saapmgr - 11860 olive 1 131072 87920 off
17499445 saapmgr - -1 olympia- 1 81920 65928 off
17499441 saapmgr - -1 olympia- 1 81920 65928 off
17499439 saapmgr - -1 olympia- 1 223924224 212080344 off <====This ONE
17499183 saapmgr - -1 olympia- 1 81920 65928 off
17499180 saapmgr - -1 olympia- 1 81920 65928 off
17499173 saapmgr - -1 olympia- 1 81920 65928 off
17499168 saapmgr - -1 olympia- 1 81920 65928 off
17499162 saapmgr - -1 olympia- 1 81920 65928 off
17499156 saapmgr - -1 olympia- 1 81920 65928 off
17499151 saapmgr - -1 olympia- 1 81920 65928 off
17499145 saapmgr - -1 olympia- 1 226394112 211701616 off <====This ONE
17495850 saapmgr - 22386 marvin 1 151552 105920 off
17495812 saapmgr - 22188 marvin 1 155648 105792 off
17495783 saapmgr - 22010 marvin 1 155648 105552 off
--e89a8f6426f435cc3504c51e4b56
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Also check onstat -g ses [sid] to see if those sessions are using PDQ.
That could set much more memory than regular sessions, depending on your
onconfig PDQ settings.
Regards.
Alexandre Marini
> To: ids@iiug.org
> From: DALink@west.com
> Subject: RE: memory used by a session [27659]
> Date: Wed, 18 Jul 2012 14:35:10 -0400
>
> You could check to see if they are holding open prepared statements. Issuing
> onstat -g stm <sid> would show you the statements that they have prepared and
> not freed.>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK
> Sent: Wednesday, July 18, 2012 12:50 PM
> To: ids@iiug.org
> Subject: memory used by a session [27657]
>
> Folks,
> You can see the two sessions below occupied excessive amount of memory (
> marked ). It is a Java application.
>
> Any guess/ideas... what the big memory are holding for? Why IDS need so big
> memory size for the two guys? ( what possible data/info in it?)
>
> ( Many Virtual memory segments were added for it)
>
> Thanks,
> Frank
>
> [informix@maggie ~]$ onstat -g ses
> IBM Informix Dynamic Server Version 11.50.FC8 -- On-Line -- Up 31 days
> 20:18:19 -- 7596160 Kbytes> session #RSAM total used
> dynamic
> id user tty pid hostname threads memory memory explain
> 17661248 informix - 0 - 0 12288 11872
> off
> 17661218 saapmgr - 11880 olive 1 122880 87816 off
> 17661214 saapmgr - 11864 olive 1 126976 87776 off
> 17661213 saapmgr - 11860 olive 1 131072 87920 off
> 17499445 saapmgr - -1 olympia- 1 81920 65928 off
> 17499441 saapmgr - -1 olympia- 1 81920 65928 off
>
> 17499439 saapmgr - -1 olympia- 1 223924224 212080344 off <====This ONE
>
> 17499183 saapmgr - -1 olympia- 1 81920 65928 off
> 17499180 saapmgr - -1 olympia- 1 81920 65928 off
> 17499173 saapmgr - -1 olympia- 1 81920 65928 off
> 17499168 saapmgr - -1 olympia- 1 81920 65928 off
> 17499162 saapmgr - -1 olympia- 1 81920 65928 off
> 17499156 saapmgr - -1 olympia- 1 81920 65928 off
> 17499151 saapmgr - -1 olympia- 1 81920 65928 off
>
> 17499145 saapmgr - -1 olympia- 1 226394112 211701616 off <====This ONE
>
> 17495850 saapmgr - 22386 marvin 1 151552 105920 off
> 17495812 saapmgr - 22188 marvin 1 155648 105792 off
> 17495783 saapmgr - 22010 marvin 1 155648 105552 off
>
> --e89a8f6426f435cc3504c51e4b56
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
it would be nice to see what these two users are currently doing:
onstat -g ses {session id}
onstat -g ses 17499439
Also to see how many current statements this application is using along
with how much memory each SQL statement is taking:
onstat -g stm {session id}
onstat -g stm 17499439
I am guessing you will find that a java programmer relied on the clean
up of the class to free the database statements. There is not specific
time table or requirement that the cleanup happens so the number of
statements grow and grow. In test it works great because there are
plenty of free cycles for the garbage collector to run.
John F. Miller III
STSM, Embedability Architect
miller3@us.ibm.com
503-578-5645
IBM Informix Dynamic Server (IDS)
ids-bounces@iiug.org wrote on 07/18/2012 10:50:09 AM:
> From: "FRANK" <yunyaoqu@gmail.com>
> To: ids@iiug.org,
> Date: 07/18/2012 11:01 AM
> Subject: memory used by a session [27657]
> Sent by: ids-bounces@iiug.org
>
> Folks,
> You can see the two sessions below occupied excessive amount of memory (
> marked ). It is a Java application.
>
> Any guess/ideas... what the big memory are holding for? Why IDS need so
> big memory size for the two guys? ( what possible data/info in it?)
>
> ( Many Virtual memory segments were added for it)
>
> Thanks,
> Frank
>
> [informix@maggie ~]$ onstat -g ses
> IBM Informix Dynamic Server Version 11.50.FC8 -- On-Line -- Up 31 days
> 20:18:19 -- 7596160 Kbytes> session #RSAM total used
> dynamic
> id user tty pid hostname threads memory memory
> explain
> 17661248 informix - 0 - 0 12288 11872
> off
> 17661218 saapmgr - 11880 olive 1 122880 87816
> off
> 17661214 saapmgr - 11864 olive 1 126976 87776
> off
> 17661213 saapmgr - 11860 olive 1 131072 87920
> off
> 17499445 saapmgr - -1 olympia- 1 81920 65928
> off
> 17499441 saapmgr - -1 olympia- 1 81920 65928
> off
>
> 17499439 saapmgr - -1 olympia- 1 223924224 212080344
> off <====This ONE
>
> 17499183 saapmgr - -1 olympia- 1 81920 65928
> off
> 17499180 saapmgr - -1 olympia- 1 81920 65928
> off
> 17499173 saapmgr - -1 olympia- 1 81920 65928
> off
> 17499168 saapmgr - -1 olympia- 1 81920 65928
> off
> 17499162 saapmgr - -1 olympia- 1 81920 65928
> off
> 17499156 saapmgr - -1 olympia- 1 81920 65928
> off
> 17499151 saapmgr - -1 olympia- 1 81920 65928
> off
>
> 17499145 saapmgr - -1 olympia- 1 226394112 211701616
> off <====This ONE
>
> 17495850 saapmgr - 22386 marvin 1 151552 105920
> off
> 17495812 saapmgr - 22188 marvin 1 155648 105792
> off
> 17495783 saapmgr - 22010 marvin 1 155648 105552
> off
>
> --e89a8f6426f435cc3504c51e4b56
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
This thread is eerily similar to some problems I had with some Java programmers (may the fleas of a thousand camels infest their armpits) some time ago where we got excessive dynamic virtual segment allocations: it's to do with java sessions not freeing statements after they've completed. Have a look at these threads if you can see them: https://groups.google.com/forum/?fromgroups#!topic/comp.databases.informix/wrmJX yobNkA https://groups.google.com/forum/?fromgroups#!topic/comp.databases.informix/1KuXe lY0LBI
Thanks, John, David A DALink and Alex!
I know what SQL jobs they are running(no PDQ involved). As you guys
pointed out, It just accumulate Prepare statements..........
Will have a closer watch and get back to you if needed.
Thanks,
Frank
On Wed, Jul 18, 2012 at 2:50 PM, John Miller iii <miller3@us.ibm.com> wrote:
> it would be nice to see what these two users are currently doing:
>
> onstat -g ses {session id}>
> onstat -g ses 17499439>
> Also to see how many current statements this application is using along
> with how much memory each SQL statement is taking:
>
> onstat -g stm {session id}>
> onstat -g stm 17499439>
> I am guessing you will find that a java programmer relied on the clean
> up of the class to free the database statements. There is not specific
> time table or requirement that the cleanup happens so the number of
> statements grow and grow. In test it works great because there are
> plenty of free cycles for the garbage collector to run.
>
> John F. Miller III
> STSM, Embedability Architect
> miller3@us.ibm.com
> 503-578-5645
> IBM Informix Dynamic Server (IDS)
>
> ids-bounces@iiug.org wrote on 07/18/2012 10:50:09 AM:
>
> > From: "FRANK" <yunyaoqu@gmail.com>
> > To: ids@iiug.org,
> > Date: 07/18/2012 11:01 AM
> > Subject: memory used by a session [27657]
> > Sent by: ids-bounces@iiug.org
> >
> > Folks,
> > You can see the two sessions below occupied excessive amount of memory (
> > marked ). It is a Java application.
> >
> > Any guess/ideas... what the big memory are holding for? Why IDS need so
> > big memory size for the two guys? ( what possible data/info in it?)
> >
> > ( Many Virtual memory segments were added for it)
> >
> > Thanks,
> > Frank
> >
> > [informix@maggie ~]$ onstat -g ses
> > IBM Informix Dynamic Server Version 11.50.FC8 -- On-Line -- Up 31 days
> > 20:18:19 -- 7596160 Kbytes> > session #RSAM total used
> > dynamic
> > id user tty pid hostname threads memory memory
> > explain
> > 17661248 informix - 0 - 0 12288 11872
> > off
> > 17661218 saapmgr - 11880 olive 1 122880 87816
> > off
> > 17661214 saapmgr - 11864 olive 1 126976 87776
> > off
> > 17661213 saapmgr - 11860 olive 1 131072 87920
> > off
> > 17499445 saapmgr - -1 olympia- 1 81920 65928
> > off
> > 17499441 saapmgr - -1 olympia- 1 81920 65928
> > off
> >
> > 17499439 saapmgr - -1 olympia- 1 223924224 212080344
> > off <====This ONE
> >
> > 17499183 saapmgr - -1 olympia- 1 81920 65928
> > off
> > 17499180 saapmgr - -1 olympia- 1 81920 65928
> > off
> > 17499173 saapmgr - -1 olympia- 1 81920 65928
> > off
> > 17499168 saapmgr - -1 olympia- 1 81920 65928
> > off
> > 17499162 saapmgr - -1 olympia- 1 81920 65928
> > off
> > 17499156 saapmgr - -1 olympia- 1 81920 65928
> > off
> > 17499151 saapmgr - -1 olympia- 1 81920 65928
> > off
> >
> > 17499145 saapmgr - -1 olympia- 1 226394112 211701616
> > off <====This ONE
> >
> > 17495850 saapmgr - 22386 marvin 1 151552 105920
> > off
> > 17495812 saapmgr - 22188 marvin 1 155648 105792
> > off
> > 17495783 saapmgr - 22010 marvin 1 155648 105552
> > off
> >
> > --e89a8f6426f435cc3504c51e4b56
> >
> >
> >
>
>
>
*******************************************************************************
>
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--14dae93410db9f855904c522c6c3
Thanks Malc_p! On Wed, Jul 18, 2012 at 3:35 PM, malc_p <iiug@perrior.net> wrote: > This thread is eerily similar to some problems I had with some Java > programmers (may the fleas of a thousand camels infest their armpits) > some time ago where we got excessive dynamic virtual segment > allocations: it's to do with java sessions not freeing statements after > they've completed. Have a look at these threads if you can see them: > > > https://groups.google.com/forum/?fromgroups#!topic/comp.databases.informix/wrmJX yobNkA > > > > https://groups.google.com/forum/?fromgroups#!topic/comp.databases.informix/1KuXe lY0LBI > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae93407d722c68f04c522d39b
Related threads
- Posting from the Informix-list
- Migrating from IDS 9.40.UC6 to 11.50.UC3
- Ip for a network session
- questions onstat -g