opentable memory leak
Andrew saw opentable memory for a session growing uncontrollably (visible via onstat -g ses/-g afr) after upgrading to 12.10.FC5 on Linux, suspecting the already-fixed APAR IT03031/IT03000. Wolfgang noted those were fixed in xC5 and suggested checking for an AUTOINDEX plan, but there was none; turning PDQ off avoided the leak and served as a workaround. IBM's Jacques Renaut identified it as a separate defect, APAR IT09544: sub-threads (auto-index builds or PDQ) don't clean up on exit, leaking memory in the parent sqlexec thread. It is not fixed in 12.10.xC5W1, but in 12.10.xC6, which was not yet released at the time.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
I recently upgraded to 12.10.FC5WE on Linux and appear to be running into
IT03031: OPENTABLE MEMORY OF A SESSION CAN GROW AND CAN LEAD TO OVERLY
LARGER MEMORY CONSUMPTION AND POSSIBLY TO MEMORY FRAGMENTATION
or possibly IT03000 as I've also seen it referenced.
onstat -g ses <session> shows the opentable memory allocation growing out ofcontrol quickly and onstat -g afr <sessionid> | grep opentable also shows
this number is growing.
Anyone experienced this before and know of a fix/workaround? PMR is opened,
but thought I'd ask here too.
Thanks,
Andrew
Hi Andrew, IT03000/IT03031 is fixed in 12.10.xC5. It has to be a different issue. Support should find out. Wolfgang
it's just a shot in the dark... check your query plan if an AUTOINDEX path is used. if yes, try after creating a permanent index on that column. Wolfgang
Is it still fixed in fc5w1 ? Cheers Paul Paul Watson Oninit www.oninit.com +1 913 387 7529 Oninit® is a Registered Trademark of Oninit LLC > On Jul 9, 2015, at 06:41, WOLFGANG EPPLER <wolfgang.eppler@de.ibm.com> wrote: > > Hi Andrew, > > IT03000/IT03031 is fixed in 12.10.xC5. > It has to be a different issue. > Support should find out. > > Wolfgang > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum.
No AUTOINDEX as far as I can tell. Turning off PDQ avoids the issue and I can live with this until permanent fix is found. Thanks, Andrew -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of WOLFGANG EPPLER Sent: Thursday, July 09, 2015 6:57 AM To: ids@iiug.org Subject: Re: opentable memory leak [35416] it's just a shot in the dark... check your query plan if an AUTOINDEX path is used. if yes, try after creating a permanent index on that column. Wolfgang **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.
Original post: No AUTOINDEX as far as I can tell. Turning off PDQ avoids the issue and I can live with this until permanent fix is found. Thanks, Andrew Response: It's a APAR in 12.10.xC5. APAR IT09544. The description talks about auto-index path, but the real trigger is any sqlexec thread that does something with sub-threads, when the sub-threads exit they aren't cleaning up properly so that is leaking memory in the parent sqlexec thread. In the testcase for the defect, it was the sub threads required for the auto-index build, but as you have found out, if you use PDQ the sub-threads for pdq can also cause the problem. The APAR has been fixed already. Jacques Renaut IBM Informix Advanced Support APD
If it's not that would be a new bug, or at least a reversion. That's one of the three bugs fixed in 12.10.xC5 that I've mentioned before that can cause a memory allocation storm. Also fixed in the latest fixpacks for 11.70 and 11.50. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Jul 9, 2015 at 8:03 AM, Paul Watson <paul@oninit.com> wrote: > Is it still fixed in fc5w1 ? > > Cheers > Paul > > Paul Watson > Oninit www.oninit.com > +1 913 387 7529 > > Oninit® is a Registered Trademark of Oninit LLC > > > On Jul 9, 2015, at 06:41, WOLFGANG EPPLER <wolfgang.eppler@de.ibm.com> > wrote: > > > > Hi Andrew, > > > > IT03000/IT03031 is fixed in 12.10.xC5. > > It has to be a different issue. > > Support should find out. > > > > Wolfgang > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a1140289c2a0ed2051a71684d
In which fixpack Jacques? Is the fix in the 12.10.xC5W1 fixpack or a later one? Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Jul 9, 2015 at 8:40 AM, JACQUES RENAUT <jrenaut@us.ibm.com> wrote: > Original post: > > No AUTOINDEX as far as I can tell. > > Turning off PDQ avoids the issue and I can live with this until permanent > fix is found. > > Thanks, > > Andrew > > Response: > > It's a APAR in 12.10.xC5. APAR IT09544. The description talks about > auto-index > path, but the real trigger is any sqlexec thread that does something with > sub-threads, when the sub-threads exit they aren't cleaning up properly so > that is leaking memory in the parent sqlexec thread. In the testcase for > the > defect, it was the sub threads required for the auto-index build, but as > you > have found out, if you use PDQ the sub-threads for pdq can also cause the > problem. The APAR has been fixed already. > > Jacques Renaut > IBM Informix Advanced Support > APD > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a113ec7704e5f37051a716e58
Original post: In which fixpack Jacques? Is the fix in the 12.10.xC5W1 fixpack or a later one? Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. Response: It is not fixed in 12.10.xC5W1. It is fixed in 12.10.xC6 (obviously not out yet). Jacques Renaut IBM Informix Advanced Support APD
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