Re: threads still running?
If the routine contains a query sufficient complex to benefit from
parallelism or from fragment elimination and you wanted those options to be
always available to any user no matter what their current PDQPRIORITY is.
This problem is why my dostats utility resets PDQPRIORITY to zero before
recompiling the SPL stored routines.
Art
On Thu, Aug 21, 2008 at 12:28 PM, Bill Hamilton <garage_dba@hotmail.com>wrote:
>
> Thanks.
> I see now that that was the problem. The script that updates stats had set
> pdqpriority 80 at top and never
> change it before it updated stats for 'routine'.
>
> What would be an example of "routines that are known to require PDQPRIORITY
> set" ?
> I mean what type of task would they be performing?
>
>
> ------------------------------
>
> Date: Thu, 21 Aug 2008 10:34:45 -0400
> From: art.kagel@gmail.com
> To: informix-list@iiug.org
> Subject: Re: threads still running?
>
>
>
> Unused threads left around are usually a symptom of having run a stored
> procedure that was compiled under a non-zero PDQPRIORITY setting. All SPL
> routines should be compiled with PDQPRIORITY zero except for specific
> routines that are known to require PDQPRIORITY set.
>
> Art
>
> On Thu, Aug 21, 2008 at 10:00 AM, Davorin Kremenjas <
> davorin.kremenjas@gmail.com> wrote:
>
> > tid name rstcb flags curstk status1289 sqlexec
> 2a99d0f4 Y--P--- 740 cond wait(netnorm)2713 join_1.0 30fda2b8
> Y------ 552 cond wait(await_MC1)2714 join_1.1 30fd847c Y------
> 552 cond wait(await_MC1)2715 join_2.0 30fd9cac Y------ 552
> cond wait(await_MC2)2716 join_2.1 30fd96a0 Y------ 552 cond
> wait(await_MC2)2717 scan_3.0 30fd6034 Y------ 552 cond
> wait(await_MC3)2718 join_1.0 30fda8c4 Y------ 552 cond
> wait(await_MC1)2719 join_1.1 30fdaed0 Y------ 552 cond
> wait(await_MC1)2720 join_2.0 30fdb4dc Y------ 552 cond
> wait(await_MC2)2721 join_2.1 30fdbae8 Y------ 552 cond
> wait(await_MC2)2722 scan_3.0 30fdc0f4 Y------ 552 cond
> wait(await_MC3)2723 join_1.0 30fdc700 Y------ 552 cond
> wait(await_MC1)2724 join_1.1 30fdcd0c Y------ 552 cond
> wait(await_MC1)2725 join_2.0 30fdd318 Y------ 552 cond
> wait(await_MC2)2726 join_2.1 30fdd924 Y------ 552 cond
> wait(await_MC2)2727 scan_3.0 30fddf30 Y------ 552 cond
> wait(await_MC3)2728 join_1.0 30fde53c Y------ 552 cond
> wait(await_MC1)2729 join_1.1 30fdeb48 Y------ 552 cond
> wait(await_MC1)2730 join_2.0 30fdf154 Y------ 552 cond
> wait(await_MC2)2731 join_2.1 30fdf760 Y------ 552 cond
> wait(await_MC2)2732 scan_3.0 30fdfd6c Y------ 552 cond
> wait(await_MC3)
> >scb sqscb optofc pdqpriority sqlstats optcompind
> directives2cb9c0b8 2bb4f018 0 0 0 0 1
>
>
> > This proc does not run but a heartbeat. What do all the "cond wait..."
> messages mean?
> > Are those threads still alive? Or does onstat -t ses nnn report things
> that have terminated (like -g sql).
> >
> > The function is called from a c++ COM dll, so perhaps the object is not
> closing the connection?
> > But it seems like the threads would die when the function returned the
> last row. Not so?
>
>
> Hi Bill,
>
> this probably has to do something with PDQPRIORITY, although the
> onstat -g ses says it's running at PDQPRIORITY=0.> It may be the case you started the engine in the environment where
> PDQPRIORITY env. var. was exported as greater than 0. Also, you may
> try to update stats for all your procedures making sure PDQ is indeed
> set to zero.
>
> HTH
>
> Davorin
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>
>
>
> --
> Art S. Kagel
> Oninit (www.oninit.com)
> IIUG Board of Directors (art@iiug.org)
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on my employer, Oninit, the IIUG, nor any other
> organization with which I am associated either explicitly or implicitly.
> Neither do those opinions reflect those of other individuals affiliated with
> any entity with which I am affiliated nor those of the entities themselves.
>
>
--
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do those
opinions reflect those of other individuals affiliated with any entity with
which I am affiliated nor those of the entities themselves.