Problem with identifying root cause of continual m

Hi to all, I have a problem with identifying root cause of continual memory consuming by db-sessions. Our OS: AIX Our IDS: 11.70.FC3 Application layer is Weblogic Application server and the interface is JDBC driver. During investigating this issue I was able to identify that the most memory consumer is the "ralloc" - pool name in each session but I wasn`t able to get any information about this pool name :-( Example of session profile: -------------------------------------------- onstat -g ses 738 IBM Informix Dynamic Server Version 11.70.FC3 -- On-Line (Prim) -- Up 22:01:05 -- 15648816 Kbytes session effective #RSAM total used dynamic id user user tty pid hostname threads memory memory explain 738 ezu - - -1 ::ffff:1 1 12521472 12151496 off tid name rstcb flags curstk status 795 sqlexec 7000002e17cc078 Y--P--- 5824 cond wait netnorm - Memory pools count 2 name class addr totalsize freesize #allocfrag #freefrag 738 V 7000002e1876040 12517376 369168 9457 893 738*O0 V 7000002e18b4040 4096 808 1 1 name free used name free used overhead 0 6576 mtmisc 0 920 resident 0 2904 scb 0 144 opentable 0 27744 filetable 0 8144 ru 0 600 misc 0 168 log 0 16536 temprec 0 21664 keys 0 2384 ralloc 0 11675896 gentcb 0 1648 ostcb 0 3400 sort 0 104 sqscb 0 359832 sql 0 72 hashfiletab 0 552 osenv 0 2400 buft_buffer 0 4216 sqtcb 0 13144 fragman 0 480 GenPg 0 856 sapi 0 776 sqscb info scb sqscb optofc pdqpriority optcompind directives 7000002d50a8200 7000002e1877028 0 0 0 1 Sess SQL Current Iso Lock SQL ISAM F.E. Id Stmt type Database Lvl Mode ERR ERR Vers Explain 738 - ses LC Not Wait 0 0 9.20 Off Last parsed SQL statement : SELECT COUNT(*) FROM SYSTABLES -------------------------------------------- For this session there is following count of ralloc pool names: -------------------------------------------- onstat -g afr 738|grep ralloc|wc -l 8987 -------------------------------------------- Could anyone please explain possible reasons of rallocs balloon or the purpose of this pool name? If I will not be able resolve this "memory leak" problem, I will think on using Memory Manager feature to keep the Virtual memory in defined limits to avoid server hung. Is it good idea ? Thanks for any help in advance Peter

Hello. It seems that you have some mistaken on your onconfig memory parameters. 1) how much physical memory do your machine has? Is your server only a database host? Or weblogic app server resides on the same machine??? 2) grep you onconfig files, and post here your *SHM* variables, and DS_* variables Maybe we could find something strange, ok? Regards. Alexandre Marini IBM Informix Certified Professional v10 / v11.50 / v11.70 IBM Information Management Informix Technical Professional IBM Infosphere DataStage Technical Professional Database Administrator > To: ids@iiug.org > From: peter.lempochner@dignitas.sk > Subject: Problem with identifying root cause of continu.... [26546] > Date: Tue, 20 Mar 2012 07:50:02 -0400 > > Hi to all, > > I have a problem with identifying root cause of continual memory consuming by > db-sessions. > Our OS: AIX > Our IDS: 11.70.FC3 > Application layer is Weblogic Application server and the interface is JDBC > driver. > > During investigating this issue I was able to identify that the most memory > consumer is the > "ralloc" - pool name in each session but I wasn`t able to get any information > about this pool name :-( > > Example of session profile: > -------------------------------------------- > onstat -g ses 738> > IBM Informix Dynamic Server Version 11.70.FC3 -- On-Line (Prim) -- Up 22:01:05 > -- 15648816 Kbytes> > session effective #RSAM total used dynamic > id user user tty pid hostname threads memory memory explain > 738 ezu - - -1 ::ffff:1 1 12521472 12151496 off > > tid name rstcb flags curstk status > 795 sqlexec 7000002e17cc078 Y--P--- 5824 cond wait netnorm - > > Memory pools count 2 > name class addr totalsize freesize #allocfrag #freefrag > 738 V 7000002e1876040 12517376 369168 9457 893 > 738*O0 V 7000002e18b4040 4096 808 1 1 > > name free used name free used > overhead 0 6576 mtmisc 0 920 > resident 0 2904 scb 0 144 > opentable 0 27744 filetable 0 8144 > ru 0 600 misc 0 168 > log 0 16536 temprec 0 21664 > keys 0 2384 ralloc 0 11675896 > gentcb 0 1648 ostcb 0 3400 > sort 0 104 sqscb 0 359832 > sql 0 72 hashfiletab 0 552 > osenv 0 2400 buft_buffer 0 4216 > sqtcb 0 13144 fragman 0 480 > GenPg 0 856 sapi 0 776 > > sqscb info > scb sqscb optofc pdqpriority optcompind directives > 7000002d50a8200 7000002e1877028 0 0 0 1 > > Sess SQL Current Iso Lock SQL ISAM F.E. > Id Stmt type Database Lvl Mode ERR ERR Vers Explain > 738 - ses LC Not Wait 0 0 9.20 Off > > Last parsed SQL statement : > > SELECT COUNT(*) FROM SYSTABLES > --------------------------------------------> > For this session there is following count of ralloc pool names: > -------------------------------------------- > onstat -g afr 738|grep ralloc|wc -l> > 8987 > -------------------------------------------- > > Could anyone please explain possible reasons of rallocs balloon or the purpose > of this pool name? > > If I will not be able resolve this "memory leak" problem, I will think on > using > Memory Manager feature to keep the Virtual memory in defined limits to avoid > server hung. > Is it good idea ? > > Thanks for any help in advance > > Peter > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hello, thanks for reaction. Answers: Hosted machine have 32GB physical memory and is dedicated to BD-servers service only. On this physical machine are running two IDS-instances: primary (instance in question) - with 15GB max usable memory (SHMTOTAL) secondary (instance for another DB system) - with 7GB max usable memory (SHMTOTAL) - this instance hasn`t any problem Weblogic runs on another hosts. Here are the onconfig requested params: *SHM*: --------------------------------------------- SHMBASE 0x700000010000000 SHMVIRTSIZE 4194304 SHMADD 102400 EXTSHMADD 8192 SHMTOTAL 15728640 SHMVIRT_ALLOCSEG 0,3 SHMNOACCESS DD_HASHMAX 10 DUMPSHMEM 0 DS_*: --------------------------------------------- DS_HASHSIZE 31 DS_POOLSIZE 127 DS_MAX_QUERIES 128 DS_TOTAL_MEMORY 1048576 DS_MAX_SCANS 4024 DS_NONPDQ_QUERY_MEM 5120 Best regards. Peter Dòa 20. 3. 2012 13:33, Alexandre Marini wrote / napísal(a): > Hello. > It seems that you have some mistaken on your onconfig memory parameters. > > 1) how much physical memory do your machine has? Is your server only a > database host? Or weblogic app server resides on the same machine??? > 2) grep you onconfig files, and post here your *SHM* variables, and DS_* > variables > > Maybe we could find something strange, ok? > > Regards. > > Alexandre Marini > IBM Informix Certified Professional v10 / v11.50 / v11.70 > > IBM Information Management Informix Technical Professional > > IBM Infosphere DataStage Technical Professional > Database Administrator > >> To: ids@iiug.org >> From: peter.lempochner@dignitas.sk >> Subject: Problem with identifying root cause of continu.... [26546] >> Date: Tue, 20 Mar 2012 07:50:02 -0400 >> >> Hi to all, >> >> I have a problem with identifying root cause of continual memory consuming > by >> db-sessions. >> Our OS: AIX >> Our IDS: 11.70.FC3 >> Application layer is Weblogic Application server and the interface is JDBC >> driver. >> >> During investigating this issue I was able to identify that the most memory >> consumer is the >> "ralloc" - pool name in each session but I wasn`t able to get any > information >> about this pool name :-( >> >> Example of session profile: >> -------------------------------------------- >> onstat -g ses 738>> >> IBM Informix Dynamic Server Version 11.70.FC3 -- On-Line (Prim) -- Up > 22:01:05 >> -- 15648816 Kbytes>> >> session effective #RSAM total used dynamic >> id user user tty pid hostname threads memory memory explain >> 738 ezu - - -1 ::ffff:1 1 12521472 12151496 off >> >> tid name rstcb flags curstk status >> 795 sqlexec 7000002e17cc078 Y--P--- 5824 cond wait netnorm - >> >> Memory pools count 2 >> name class addr totalsize freesize #allocfrag #freefrag >> 738 V 7000002e1876040 12517376 369168 9457 893 >> 738*O0 V 7000002e18b4040 4096 808 1 1 >> >> name free used name free used >> overhead 0 6576 mtmisc 0 920 >> resident 0 2904 scb 0 144 >> opentable 0 27744 filetable 0 8144 >> ru 0 600 misc 0 168 >> log 0 16536 temprec 0 21664 >> keys 0 2384 ralloc 0 11675896 >> gentcb 0 1648 ostcb 0 3400 >> sort 0 104 sqscb 0 359832 >> sql 0 72 hashfiletab 0 552 >> osenv 0 2400 buft_buffer 0 4216 >> sqtcb 0 13144 fragman 0 480 >> GenPg 0 856 sapi 0 776 >> >> sqscb info >> scb sqscb optofc pdqpriority optcompind directives >> 7000002d50a8200 7000002e1877028 0 0 0 1 >> >> Sess SQL Current Iso Lock SQL ISAM F.E. >> Id Stmt type Database Lvl Mode ERR ERR Vers Explain >> 738 - ses LC Not Wait 0 0 9.20 Off >> >> Last parsed SQL statement : >> >> SELECT COUNT(*) FROM SYSTABLES >> -------------------------------------------->> >> For this session there is following count of ralloc pool names: >> -------------------------------------------- >> onstat -g afr 738|grep ralloc|wc -l>> >> 8987 >> -------------------------------------------- >> >> Could anyone please explain possible reasons of rallocs balloon or the > purpose >> of this pool name? >> >> If I will not be able resolve this "memory leak" problem, I will think on >> using >> Memory Manager feature to keep the Virtual memory in defined limits to avoid >> server hung. >> Is it good idea ? >> >> Thanks for any help in advance >> >> Peter >> >> >> > ******************************************************************************* >> Forum Note: Use "Reply" to post a response in the discussion forum. >> > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

Ok. I think it probably some application problem. Could you check out if your Informix server is using OPTOFC=1 value? It should. I also suggest you to search for the JDBC connection string (or properties), for IFX_AUTOFREE parameter. It also must be turned on. Maybe that´s the cause: your applications are not freeing the used memory, ok? Hope it helps. Regards. Alexandre Marini IBM Informix Certified Professional v10 / v11.50 / v11.70 IBM Information Management Informix Technical Professional IBM Infosphere DataStage Technical Professional Database Administrator > To: ids@iiug.org > From: peter.lempochner@dignitas.sk > Subject: Re: Problem with identifying root cause of con.... [26549] > Date: Tue, 20 Mar 2012 09:16:21 -0400 > > Hello, > > thanks for reaction. Answers: > > Hosted machine have 32GB physical memory and is dedicated to BD-servers > service only. > On this physical machine are running two IDS-instances: > primary (instance in question) - with 15GB max usable memory (SHMTOTAL) > secondary (instance for another DB system) - with 7GB max usable memory > (SHMTOTAL) - this instance hasn`t any problem > > Weblogic runs on another hosts. > > Here are the onconfig requested params: > *SHM*: > --------------------------------------------- > SHMBASE 0x700000010000000 > SHMVIRTSIZE 4194304 > SHMADD 102400 > EXTSHMADD 8192 > SHMTOTAL 15728640 > SHMVIRT_ALLOCSEG 0,3 > SHMNOACCESS > DD_HASHMAX 10 > DUMPSHMEM 0> > DS_*: > --------------------------------------------- > DS_HASHSIZE 31 > DS_POOLSIZE 127 > DS_MAX_QUERIES 128 > DS_TOTAL_MEMORY 1048576 > DS_MAX_SCANS 4024 > DS_NONPDQ_QUERY_MEM 5120> > Best regards. > > Peter > > Dòa 20. 3. 2012 13:33, Alexandre Marini wrote / napísal(a): > > Hello. > > It seems that you have some mistaken on your onconfig memory parameters. > > > > 1) how much physical memory do your machine has? Is your server only a > > database host? Or weblogic app server resides on the same machine??? > > 2) grep you onconfig files, and post here your *SHM* variables, and DS_* > > variables > > > > Maybe we could find something strange, ok? > > > > Regards. > > > > Alexandre Marini > > IBM Informix Certified Professional v10 / v11.50 / v11.70 > > > > IBM Information Management Informix Technical Professional > > > > IBM Infosphere DataStage Technical Professional > > Database Administrator > > > >> To: ids@iiug.org > >> From: peter.lempochner@dignitas.sk > >> Subject: Problem with identifying root cause of continu.... [26546] > >> Date: Tue, 20 Mar 2012 07:50:02 -0400 > >> > >> Hi to all, > >> > >> I have a problem with identifying root cause of continual memory consuming > > by > >> db-sessions. > >> Our OS: AIX > >> Our IDS: 11.70.FC3 > >> Application layer is Weblogic Application server and the interface is JDBC > >> driver. > >> > >> During investigating this issue I was able to identify that the most memory > >> consumer is the > >> "ralloc" - pool name in each session but I wasn`t able to get any > > information > >> about this pool name :-( > >> > >> Example of session profile: > >> -------------------------------------------- > >> onstat -g ses 738> >> > >> IBM Informix Dynamic Server Version 11.70.FC3 -- On-Line (Prim) -- Up > > 22:01:05 > >> -- 15648816 Kbytes> >> > >> session effective #RSAM total used dynamic > >> id user user tty pid hostname threads memory memory explain > >> 738 ezu - - -1 ::ffff:1 1 12521472 12151496 off > >> > >> tid name rstcb flags curstk status > >> 795 sqlexec 7000002e17cc078 Y--P--- 5824 cond wait netnorm - > >> > >> Memory pools count 2 > >> name class addr totalsize freesize #allocfrag #freefrag > >> 738 V 7000002e1876040 12517376 369168 9457 893 > >> 738*O0 V 7000002e18b4040 4096 808 1 1 > >> > >> name free used name free used > >> overhead 0 6576 mtmisc 0 920 > >> resident 0 2904 scb 0 144 > >> opentable 0 27744 filetable 0 8144 > >> ru 0 600 misc 0 168 > >> log 0 16536 temprec 0 21664 > >> keys 0 2384 ralloc 0 11675896 > >> gentcb 0 1648 ostcb 0 3400 > >> sort 0 104 sqscb 0 359832 > >> sql 0 72 hashfiletab 0 552 > >> osenv 0 2400 buft_buffer 0 4216 > >> sqtcb 0 13144 fragman 0 480 > >> GenPg 0 856 sapi 0 776 > >> > >> sqscb info > >> scb sqscb optofc pdqpriority optcompind directives > >> 7000002d50a8200 7000002e1877028 0 0 0 1 > >> > >> Sess SQL Current Iso Lock SQL ISAM F.E. > >> Id Stmt type Database Lvl Mode ERR ERR Vers Explain > >> 738 - ses LC Not Wait 0 0 9.20 Off > >> > >> Last parsed SQL statement : > >> > >> SELECT COUNT(*) FROM SYSTABLES > >> --------------------------------------------> >> > >> For this session there is following count of ralloc pool names: > >> -------------------------------------------- > >> onstat -g afr 738|grep ralloc|wc -l> >> > >> 8987 > >> -------------------------------------------- > >> > >> Could anyone please explain possible reasons of rallocs balloon or the > > purpose > >> of this pool name? > >> > >> If I will not be able resolve this "memory leak" problem, I will think on > >> using > >> Memory Manager feature to keep the Virtual memory in defined limits to > avoid > >> server hung. > >> Is it good idea ? > >> > >> Thanks for any help in advance > >> > >> Peter > >> > >> > >> > > > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. > >> > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hi, just a hint which came to my mind (not really knowing if the ralloc pool is influenced by this): We once had the phenomenon of a steadily growing memory pool in our Informix connections when using JDBC with a self-constructed connection pool mechanism. This connection pool did not take care of unclosed statements. We identified the cause for the memory consumption in unclosed cursors/resultsets in the application. Maybe you can check if there are a number of unclosed cursors, which acquire memory on the IDS side, but are "forgotten" in the application. Marcus ----- Ursprüngliche Mail ----- Von: "Peter Lempochner" <peter.lempochner@dignitas.sk> An: ids@iiug.org Gesendet: Dienstag, 20. März 2012 14:16:21 Betreff: Re: Problem with identifying root cause of con.... [26549] Hello, thanks for reaction. Answers: Hosted machine have 32GB physical memory and is dedicated to BD-servers service only. On this physical machine are running two IDS-instances: primary (instance in question) - with 15GB max usable memory (SHMTOTAL) secondary (instance for another DB system) - with 7GB max usable memory (SHMTOTAL) - this instance hasn`t any problem Weblogic runs on another hosts. Here are the onconfig requested params: *SHM*: --------------------------------------------- SHMBASE 0x700000010000000 SHMVIRTSIZE 4194304 SHMADD 102400 EXTSHMADD 8192 SHMTOTAL 15728640 SHMVIRT_ALLOCSEG 0,3 SHMNOACCESS DD_HASHMAX 10 DUMPSHMEM 0 DS_*: --------------------------------------------- DS_HASHSIZE 31 DS_POOLSIZE 127 DS_MAX_QUERIES 128 DS_TOTAL_MEMORY 1048576 DS_MAX_SCANS 4024 DS_NONPDQ_QUERY_MEM 5120 Best regards. Peter Da 20. 3. 2012 13:33, Alexandre Marini wrote / napsal(a): > Hello. > It seems that you have some mistaken on your onconfig memory parameters. > > 1) how much physical memory do your machine has? Is your server only a > database host? Or weblogic app server resides on the same machine??? > 2) grep you onconfig files, and post here your *SHM* variables, and DS_* > variables > > Maybe we could find something strange, ok? > > Regards. > > Alexandre Marini > IBM Informix Certified Professional v10 / v11.50 / v11.70 > > IBM Information Management Informix Technical Professional > > IBM Infosphere DataStage Technical Professional > Database Administrator > >> To: ids@iiug.org >> From: peter.lempochner@dignitas.sk >> Subject: Problem with identifying root cause of continu.... [26546] >> Date: Tue, 20 Mar 2012 07:50:02 -0400 >> >> Hi to all, >> >> I have a problem with identifying root cause of continual memory consuming > by >> db-sessions. >> Our OS: AIX >> Our IDS: 11.70.FC3 >> Application layer is Weblogic Application server and the interface is JDBC >> driver. >> >> During investigating this issue I was able to identify that the most memory >> consumer is the >> "ralloc" - pool name in each session but I wasn`t able to get any > information >> about this pool name :-( >> >> Example of session profile: >> -------------------------------------------- >> onstat -g ses 738>> >> IBM Informix Dynamic Server Version 11.70.FC3 -- On-Line (Prim) -- Up > 22:01:05 >> -- 15648816 Kbytes>> >> session effective #RSAM total used dynamic >> id user user tty pid hostname threads memory memory explain >> 738 ezu - - -1 ::ffff:1 1 12521472 12151496 off >> >> tid name rstcb flags curstk status >> 795 sqlexec 7000002e17cc078 Y--P--- 5824 cond wait netnorm - >> >> Memory pools count 2 >> name class addr totalsize freesize #allocfrag #freefrag >> 738 V 7000002e1876040 12517376 369168 9457 893 >> 738*O0 V 7000002e18b4040 4096 808 1 1 >> >> name free used name free used >> overhead 0 6576 mtmisc 0 920 >> resident 0 2904 scb 0 144 >> opentable 0 27744 filetable 0 8144 >> ru 0 600 misc 0 168 >> log 0 16536 temprec 0 21664 >> keys 0 2384 ralloc 0 11675896 >> gentcb 0 1648 ostcb 0 3400 >> sort 0 104 sqscb 0 359832 >> sql 0 72 hashfiletab 0 552 >> osenv 0 2400 buft_buffer 0 4216 >> sqtcb 0 13144 fragman 0 480 >> GenPg 0 856 sapi 0 776 >> >> sqscb info >> scb sqscb optofc pdqpriority optcompind directives >> 7000002d50a8200 7000002e1877028 0 0 0 1 >> >> Sess SQL Current Iso Lock SQL ISAM F.E. >> Id Stmt type Database Lvl Mode ERR ERR Vers Explain >> 738 - ses LC Not Wait 0 0 9.20 Off >> >> Last parsed SQL statement : >> >> SELECT COUNT(*) FROM SYSTABLES >> -------------------------------------------->> >> For this session there is following count of ralloc pool names: >> -------------------------------------------- >> onstat -g afr 738|grep ralloc|wc -l>> >> 8987 >> -------------------------------------------- >> >> Could anyone please explain possible reasons of rallocs balloon or the > purpose >> of this pool name? >> >> If I will not be able resolve this "memory leak" problem, I will think on >> using >> Memory Manager feature to keep the Virtual memory in defined limits to avoid >> server hung. >> Is it good idea ? >> >> Thanks for any help in advance >> >> Peter >> >> >> > ******************************************************************************* >> Forum Note: Use "Reply" to post a response in the discussion forum. >> > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

original post: Hi to all, I have a problem with identifying root cause of continual memory consuming by db-sessions. Our OS: AIX Our IDS: 11.70.FC3 Application layer is Weblogic Application server and the interface is JDBC driver. During investigating this issue I was able to identify that the most memory consumer is the "ralloc" - pool name in each session but I wasn`t able to get any information about this pool name :-( <stuff cut out> Could anyone please explain possible reasons of rallocs balloon or the purpose of this pool name? If I will not be able resolve this "memory leak" problem, I will think on using Memory Manager feature to keep the Virtual memory in defined limits to avoid server hung. Is it good idea ? Thanks for any help in advance Peter Response: Ralloc memory is used for pretty much all SQL...so prepared statements and cursors and what not use ralloc memory. I'd be curious if as your ralloc memory grows, what does that onstat -g stm <session id> do? Does it continue to add more and more statements to the session? If so it could be that as statements and cursors are getting prepared and used, they aren't getting freed, which causes more ralloc memory to be retained in the session. The onstat -g stm should not only show the statement, but the heapsz which is theheap size or the amount of ralloc memory used for that statement (roughly anyway I believe). So while monitoring the -g stm <session id> for more statements to be added, you can also see if there is 1 or a smaller sub set of statements to see if heapsz keeps growing as well, which could be an indication of a possible engine memory leak for that statement. Jacques Renaut IBM Informix Advanced Support APD Team

Hi, OPTOFC isn`t set - so its value is 0 (I assume) I`m going to send request to apps Vendor to check, if the IFX_AUTOFREE is set or not. Today we have planned outage, so we will try to set it up and test it. Thanks a lot for your answers. Dòa 20. 3. 2012 14:35, Alexandre Marini wrote / napísal(a): > Ok. > I think it probably some application problem. > Could you check out if your Informix server is using OPTOFC=1 value? It > should. > I also suggest you to search for the JDBC connection string (or properties), > for IFX_AUTOFREE parameter. It also must be turned on. > Maybe that´s the cause: your applications are not freeing the used memory, ok? > > Hope it helps. > Regards. > > Alexandre Marini > IBM Informix Certified Professional v10 / v11.50 / v11.70 > > IBM Information Management Informix Technical Professional > > IBM Infosphere DataStage Technical Professional > Database Administrator > >> To: ids@iiug.org >> From: peter.lempochner@dignitas.sk >> Subject: Re: Problem with identifying root cause of con.... [26549] >> Date: Tue, 20 Mar 2012 09:16:21 -0400 >> >> Hello, >> >> thanks for reaction. Answers: >> >> Hosted machine have 32GB physical memory and is dedicated to BD-servers >> service only. >> On this physical machine are running two IDS-instances: >> primary (instance in question) - with 15GB max usable memory (SHMTOTAL) >> secondary (instance for another DB system) - with 7GB max usable memory >> (SHMTOTAL) - this instance hasn`t any problem >> >> Weblogic runs on another hosts. >> >> Here are the onconfig requested params: >> *SHM*: >> --------------------------------------------- >> SHMBASE 0x700000010000000 >> SHMVIRTSIZE 4194304 >> SHMADD 102400 >> EXTSHMADD 8192 >> SHMTOTAL 15728640 >> SHMVIRT_ALLOCSEG 0,3 >> SHMNOACCESS >> DD_HASHMAX 10 >> DUMPSHMEM 0>> >> DS_*: >> --------------------------------------------- >> DS_HASHSIZE 31 >> DS_POOLSIZE 127 >> DS_MAX_QUERIES 128 >> DS_TOTAL_MEMORY 1048576 >> DS_MAX_SCANS 4024 >> DS_NONPDQ_QUERY_MEM 5120>> >> Best regards. >> >> Peter >> >> Dòa 20. 3. 2012 13:33, Alexandre Marini wrote / napísal(a): >>> Hello. >>> It seems that you have some mistaken on your onconfig memory parameters. >>> >>> 1) how much physical memory do your machine has? Is your server only a >>> database host? Or weblogic app server resides on the same machine??? >>> 2) grep you onconfig files, and post here your *SHM* variables, and DS_* >>> variables >>> >>> Maybe we could find something strange, ok? >>> >>> Regards. >>> >>> Alexandre Marini >>> IBM Informix Certified Professional v10 / v11.50 / v11.70 >>> >>> IBM Information Management Informix Technical Professional >>> >>> IBM Infosphere DataStage Technical Professional >>> Database Administrator >>> >>>> To: ids@iiug.org >>>> From: peter.lempochner@dignitas.sk >>>> Subject: Problem with identifying root cause of continu.... [26546] >>>> Date: Tue, 20 Mar 2012 07:50:02 -0400 >>>> >>>> Hi to all, >>>> >>>> I have a problem with identifying root cause of continual memory > consuming >>> by >>>> db-sessions. >>>> Our OS: AIX >>>> Our IDS: 11.70.FC3 >>>> Application layer is Weblogic Application server and the interface is > JDBC >>>> driver. >>>> >>>> During investigating this issue I was able to identify that the most > memory >>>> consumer is the >>>> "ralloc" - pool name in each session but I wasn`t able to get any >>> information >>>> about this pool name :-( >>>> >>>> Example of session profile: >>>> -------------------------------------------- >>>> onstat -g ses 738>>>> >>>> IBM Informix Dynamic Server Version 11.70.FC3 -- On-Line (Prim) -- Up >>> 22:01:05 >>>> -- 15648816 Kbytes>>>> >>>> session effective #RSAM total used dynamic >>>> id user user tty pid hostname threads memory memory explain >>>> 738 ezu - - -1 ::ffff:1 1 12521472 12151496 off >>>> >>>> tid name rstcb flags curstk status >>>> 795 sqlexec 7000002e17cc078 Y--P--- 5824 cond wait netnorm - >>>> >>>> Memory pools count 2 >>>> name class addr totalsize freesize #allocfrag #freefrag >>>> 738 V 7000002e1876040 12517376 369168 9457 893 >>>> 738*O0 V 7000002e18b4040 4096 808 1 1 >>>> >>>> name free used name free used >>>> overhead 0 6576 mtmisc 0 920 >>>> resident 0 2904 scb 0 144 >>>> opentable 0 27744 filetable 0 8144 >>>> ru 0 600 misc 0 168 >>>> log 0 16536 temprec 0 21664 >>>> keys 0 2384 ralloc 0 11675896 >>>> gentcb 0 1648 ostcb 0 3400 >>>> sort 0 104 sqscb 0 359832 >>>> sql 0 72 hashfiletab 0 552 >>>> osenv 0 2400 buft_buffer 0 4216 >>>> sqtcb 0 13144 fragman 0 480 >>>> GenPg 0 856 sapi 0 776 >>>> >>>> sqscb info >>>> scb sqscb optofc pdqpriority optcompind directives >>>> 7000002d50a8200 7000002e1877028 0 0 0 1 >>>> >>>> Sess SQL Current Iso Lock SQL ISAM F.E. >>>> Id Stmt type Database Lvl Mode ERR ERR Vers Explain >>>> 738 - ses LC Not Wait 0 0 9.20 Off >>>> >>>> Last parsed SQL statement : >>>> >>>> SELECT COUNT(*) FROM SYSTABLES >>>> -------------------------------------------->>>> >>>> For this session there is following count of ralloc pool names: >>>> -------------------------------------------- >>>> onstat -g afr 738|grep ralloc|wc -l>>>> >>>> 8987 >>>> -------------------------------------------- >>>> >>>> Could anyone please explain possible reasons of rallocs balloon or the >>> purpose >>>> of this pool name? >>>> >>>> If I will not be able resolve this "memory leak" problem, I will think on >>>> using >>>> Memory Manager feature to keep the Virtual memory in defined limits to >> avoid >>>> server hung. >>>> Is it good idea ? >>>> >>>> Thanks for any help in advance >>>> >>>> Peter >>>> >>>> >>>> > ******************************************************************************* >>>> Forum Note: Use "Reply" to post a response in the discussion forum. >>>> >>> > ******************************************************************************* >>> Forum Note: Use "Reply" to post a response in the discussion forum. >>> >>> >> >> > ******************************************************************************* >> Forum Note: Use "Reply" to post a response in the discussion forum. >> > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >