foreach and open descriptor
A user on IDS 10 (RHEL 4) found that stored procedures with many nested FOREACH loops and nested SP calls left huge numbers of entries in 'onstat -g opn' (reaching ~64000 for one session), after which the session hung; he asked which Linux kernel file-descriptor parameter to raise. Respondents pointed out that 'onstat -g opn' tracks internal open cursors/tables, not OS descriptors controlled by the kernel, and asked for 'onstat -u', '-g ses', '-g stk' output, sample 'opn' output and details of the routines, suspecting cursors weren't being closed. The poster only added that the count hit 64000 with nested FOREACHs; no resolution is recorded, and the thread ends with an unrelated post about OpenAdmin/PHP connection errors.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
hi,
i'm executing routines containing foreach ... end foreach
instructions. it seems that after many execution
onstat -g opn shows a great number of lines and my session hangs.what's could be the linux kernel parameter that could increase the
number of available open descriptor for a session? i'm running ids10
on linux rhel 4.
thanks.
jack
On Feb 18, 4:20 pm, vomari...@yahoo.com wrote:
> hi,
> i'm executing routines containing foreach ... end foreach
> instructions. it seems that after many execution
> onstat -g opn shows a great number of lines and my session hangs.> what's could be the linux kernel parameter that could increase the
> number of available open descriptor for a session? i'm running ids10
> on linux rhel 4.
> thanks.
> jack
onstat -g opn doesn't list any resource that would be controlled bythe linux kernel (well technically I suppose you could say "memory"
but that's about it).
What does onstat -u, onstat -g ses <hung session id> and possibly
onstat -g stk <threadid of your hung session> show? Is your sessionwaiting for some resource?
jprenaut@yahoo.com wrote:
> On Feb 18, 4:20 pm, vomari...@yahoo.com wrote:
>
>>hi,
>>i'm executing routines containing foreach ... end foreach
>>instructions. it seems that after many execution
>>onstat -g opn shows a great number of lines and my session hangs.>>what's could be the linux kernel parameter that could increase the
>>number of available open descriptor for a session? i'm running ids10
>>on linux rhel 4.
>>thanks.
>>jack
>
>
> onstat -g opn doesn't list any resource that would be controlled by> the linux kernel (well technically I suppose you could say "memory"
> but that's about it).
>
> What does onstat -u, onstat -g ses <hung session id> and possibly
> onstat -g stk <threadid of your hung session> show? Is your session> waiting for some resource?
Post a little bit of the onstat -g opn ... perhaps you are mis-handling something :-/
TBP (The Big Potato) wrote:
> jprenaut@yahoo.com wrote:
>> On Feb 18, 4:20 pm, vomari...@yahoo.com wrote:
>>
>>> hi,
>>> i'm executing routines containing foreach ... end foreach
>>> instructions. it seems that after many execution
>>> onstat -g opn shows a great number of lines and my session hangs.>>> what's could be the linux kernel parameter that could increase the
>>> number of available open descriptor for a session? i'm running ids10
>>> on linux rhel 4.
>>> thanks.
>>> jack
>>
>>
>> onstat -g opn doesn't list any resource that would be controlled by>> the linux kernel (well technically I suppose you could say "memory"
>> but that's about it).
>>
>> What does onstat -u, onstat -g ses <hung session id> and possibly
>> onstat -g stk <threadid of your hung session> show? Is your session>> waiting for some resource?
> Post a little bit of the onstat -g opn ... perhaps you are mis-handling
> something :-/
and when you say "routines", what exactly are you doing...?
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
On 18 fév, 23:39, Fernando Nunes <s...@onlinedomus.net> wrote:
> TBP (The Big Potato) wrote:
>
>
>
> > jpren...@yahoo.com wrote:
> >> On Feb 18, 4:20 pm, vomari...@yahoo.com wrote:
>
> >>> hi,
> >>> i'm executing routines containing foreach ... end foreach
> >>> instructions. it seems that after many execution
> >>> onstat -g opn shows a great number of lines and my session hangs.> >>> what's could be the linux kernel parameter that could increase the
> >>> number of available open descriptor for a session? i'm running ids10
> >>> on linux rhel 4.
> >>> thanks.
> >>> jack
>
> >> onstat -g opn doesn't list any resource that would be controlled by> >> the linux kernel (well technically I suppose you could say "memory"
> >> but that's about it).
>
> >> What does onstat -u, onstat -g ses <hung session id> and possibly
> >> onstat -g stk <threadid of your hung session> show? Is your session> >> waiting for some resource?
> > Post a little bit of the onstat -g opn ... perhaps you are mis-handling
> > something :-/
>
> and when you say "routines", what exactly are you doing...?
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
well, the 3rd columns of onstat -g opn reach 64000 for a single
session. some SP contains many nested foreach and call others SP.
Hi all, I'm setting up a development environment on a Red Hat Enterprice 5 and I'm running in a small problem. I have installed IDS 11 Dev Edition (iif.11.10.UC1DE.Linux-RHEL4), Unix ODBC 2.2.12, Zend Core for IBM 2.5. I have recompiled pdo informix from pecl and added it - together with pdo_sqlite, gd and soap, to the php.ini file. I've setup my odbc and I can connect to the database trough isql. I've followed the installation notes for Open Admin for IDS (version 2.11.01) and the installation went well... until I tried logging in: Connection Failed: DSN:informix:host = 127.0.0.1 ;service = 50000 ;database=sysmaster;protocol=onsoctcp;server=demo_on;TRANSLATIONDLL=/ opt/informix/lib/esql/igo4a304.so;Driver=/opt/informix/lib/cli/ libifdmr.so; SQLSTATE=08001, SQLDriverConnect: -1013 [IBM][CLI Driver] SQL10007N Message "0" could not be retrieved. Reason code: "3". I've tried to manually substititude the dsn to use the odbc one, but that didn't work either. I have checked my php env and I can clearly see that the environment variables are set correctly. Anyone an idea what the problem could be or how I can solve this? Thanks, Jeroen