Permanently Growing SHM

Hi, I have a Problem with permanently growing SHM on SINIX 5.43. One session takes more and more memory. As I now these session is a daemon with only two simple Select-Cursors (ESQL/C). I think the two cursors are closed and freed. Here is a print of 'onstat -g ses' of the session: What goes in the 'gentcb'? What does it mean? ( 1989520 Byte !!!! ) --> and it is growing ------------------------------------------------------------------------------------- INFORMIX-OnLine Version 7.24.UC3 -- On-Line -- Up 3 days 23:59:30 -- 48504 Kbytes session #RSAM total used id user tty pid hostname threads memory memory 1214 ddvpc - 15472 m002_09 1 2031616 2014568 tid name rstcb flags curstk status 1252 sqlexec 20fd0cd8 Y--P--- 1512 20fd0cd8 cond wait(sm_read) Memory pools count 1 name class addr totalsize freesize #allocfrag #freefrag 1214 V 211fe018 2031616 17048 49473 4 name free used name free used overhead 0 120 scb 0 96 opentable 0 2728 filetable 0 520 ru 0 224 misc 0 152 blobio 0 5080 log 0 2136 temprec 0 840 gentcb 0 1989520 ostcb 0 2072 sqscb 0 7520 rdahead 0 208 hashfiletab 0 280 osenv 0 1664 sqtcb 0 1360 fragman 0 48 Sess SQL Current Iso Lock SQL ISAM F.E. Id Stmt type Database Lvl Mode ERR ERR Vers 1214 - - - Not Wait 0 0 7.24 Last parsed SQL statement : SELECT benutzer , lfd_nr , prozess_id FROM auftrag WHERE bearb_stat =? -------------------------------------------------------------------------------- Thanks Ruediger Papke

Rüdiger Papke wrote: > > Hi, > I have a Problem with permanently growing SHM on SINIX 5.43. > One session takes more and more memory. As I now these session is a > daemon > with only two simple Select-Cursors (ESQL/C). I think the two cursors > are closed and freed. > Here is a print of 'onstat -g ses' of the session: > What goes in the 'gentcb'? What does it mean? > ( 1989520 Byte !!!! ) --> and it is growing > ------------------------------------------------------------------------------------- > INFORMIX-OnLine Version 7.24.UC3 -- On-Line -- Up 3 days 23:59:30 -- > 48504 Kbytes > > session #RSAM total used > id user tty pid hostname threads memory memory > 1214 ddvpc - 15472 m002_09 1 2031616 2014568 > > tid name rstcb flags curstk status > 1252 sqlexec 20fd0cd8 Y--P--- 1512 20fd0cd8 cond wait(sm_read) > > Memory pools count 1 > name class addr totalsize freesize #allocfrag #freefrag > 1214 V 211fe018 2031616 17048 49473 4 > > name free used name free > used > overhead 0 120 scb 0 > 96 > opentable 0 2728 filetable 0 > 520 > ru 0 224 misc 0 > 152 > blobio 0 5080 log 0 > 2136 > temprec 0 840 gentcb 0 > 1989520 > ostcb 0 2072 sqscb 0 > 7520 > rdahead 0 208 hashfiletab 0 > 280 > osenv 0 1664 sqtcb 0 > 1360 > fragman 0 48 > > Sess SQL Current Iso Lock SQL ISAM F.E. > Id Stmt type Database Lvl Mode ERR ERR Vers > 1214 - - - Not Wait 0 0 7.24 > > Last parsed SQL statement : > SELECT benutzer , lfd_nr , prozess_id FROM auftrag WHERE bearb_stat => ? > -------------------------------------------------------------------------------- > Thanks > > Ruediger Papke Hi, possibly the problem is a side-effect of a known "signal-problem" in 5.43 SINIX. To ensure that you do not have this signal-problem you should set the kernel parameter DVHANGUP to the value 9. I will try to find out what's inside the gentcb-memory pool and will inform you as soon as as possible. BTW, cursors and prepared statement information is stored in the ralloc-pool. Therefore, open cursors are not the reason for your problem. Have a nice day, Stefan Weideneder -- Stefan Weideneder ---------------------------------------------------------------- ----------------------------------------------------------------

In article <36A22EF2.6E0C1C00@weideneder.de>, Stefan Weideneder <stefan@weideneder.de> writes >Rüdiger Papke wrote: >> >> Hi, >> I have a Problem with permanently growing SHM on SINIX 5.43. >> One session takes more and more memory. As I now these session is a >> daemon >> with only two simple Select-Cursors (ESQL/C). I think the two cursors >> are closed and freed. >> Here is a print of 'onstat -g ses' of the session: >> What goes in the 'gentcb'? What does it mean? tcb = Thread Control Block. I suspect gentcb = general thread control block info. >> ( 1989520 Byte !!!! ) --> and it is growing >> ------------------------------------------------------------------------------ >------- >> INFORMIX-OnLine Version 7.24.UC3 -- On-Line -- Up 3 days 23:59:30 -- >> 48504 Kbytes >> >> session #RSAM total used >> id user tty pid hostname threads memory memory >> 1214 ddvpc - 15472 m002_09 1 2031616 2014568 >> >> tid name rstcb flags curstk status >> 1252 sqlexec 20fd0cd8 Y--P--- 1512 20fd0cd8 cond wait(sm_read) >> >> Memory pools count 1 >> name class addr totalsize freesize #allocfrag #freefrag >> 1214 V 211fe018 2031616 17048 49473 4 >> >> name free used name free >> used >> overhead 0 120 scb 0 >> 96 >> opentable 0 2728 filetable 0 >> 520 >> ru 0 224 misc 0 >> 152 >> blobio 0 5080 log 0 >> 2136 >> temprec 0 840 gentcb 0 >> 1989520 >> ostcb 0 2072 sqscb 0 >> 7520 >> rdahead 0 208 hashfiletab 0 >> 280 >> osenv 0 1664 sqtcb 0 >> 1360 >> fragman 0 48 >> >> Sess SQL Current Iso Lock SQL ISAM F.E. >> Id Stmt type Database Lvl Mode ERR ERR Vers >> 1214 - - - Not Wait 0 0 7.24 >> >> Last parsed SQL statement : >> SELECT benutzer , lfd_nr , prozess_id FROM auftrag WHERE bearb_stat =>> ? >> ------------------------------------------------------------------------------ >-- >> Thanks >> >> Ruediger Papke > >Hi, > >possibly the problem is a side-effect of a known "signal-problem" >in 5.43 SINIX. To ensure that you do not have this signal-problem >you should set the kernel parameter DVHANGUP to the value 9. >I will try to find out what's inside the gentcb-memory pool and >will inform you as soon as as possible. > >BTW, cursors and prepared statement information is stored in the >ralloc-pool. Therefore, open cursors are not the reason for your >problem. > >Have a nice day, > >Stefan Weideneder I would log a support call with Informix, it looks like a bug.. -- David Williams