Is gradually increasing memory in long running session normal?

[Dave Thacker]

I've been trying to debug a problem with a constantly running
application that is
experiencing a performance degradation over time. Today I set up a
script to
run onstat -g ses every 60 seconds and log the results. One of the
things that caught my eye is that this session's memory use increases
constantly over time.
For example,

total
memory
13:38 1265664
14:38 1977408
15:38 2646016

Will the total memory ever decrease during the lifespan of a session?

Dave Thacker

[Fernando Ortiz]

Hi Dave:

Several months ago one of ours 4GL programs made a lot of DECLARE
CURSOR/PREPARE without FREEing them, and yes the memory usage was
increasing.

In my case I use onstat -g stm to locate the statements prepared, fgrep the
source to locate the offending code and adding the missing FREE .

HTH

----- Original Message -----
From: <dthacker@omnihotels.com>
To: <informix-list@iiug.org>
Sent: Thursday, September 04, 2003 3:55 PM
Subject: Is gradually increasing memory in long running session normal?

> I've been trying to debug a problem with a constantly running
> application that is
> experiencing a performance degradation over time. Today I set up a
> script to
> run onstat -g ses every 60 seconds and log the results. One of the
> things that caught my eye is that this session's memory use increases
> constantly over time.
> For example,
>
> total
> memory
> 13:38 1265664
> 14:38 1977408
> 15:38 2646016
>
> Will the total memory ever decrease during the lifespan of a session?
>
> Dave Thacker

sending to informix-list

[Roland Wintgen]

Hi Fernando,

I changed our programs to prepare lots of heavily used statements
instead of redeclaring the cursors.

At least in one case it took me several months to identify one prepared
statement which wouldn't free the allocated memory. I used the following
identical syntax for several SQL-statements:

let query = "select ..."
prepare query_prep from query
declare query_curs cursor for query_prep
free query_prep

This works for all but one function. The memory only gets released if
the program ends. After rewriting the code and declaring the cursor
every time it's used, everything works fine.

Can anyone corfirm this?

We're using 4GL RDS 7.30UC6 with IDS 7.30UC10 on SCO Unixware 7.1.1 and this
was reproducable on RedHat Linux 7.3 4GL RDS 7.30UC5 and IDS 7.30UC10.


--
Roland Wintgen (Systemadministrator)

EVG Elektro-Vertriebs-Gesellschaft Martens GmbH & Co KG
Trompeterallee 244-246, D-41189 Moenchengladbach
phone +49 21 66 / 55 08 23, fax +49 21 66 / 55 08 90
[url]www.evg.de[/url] [email]rw@evg.de[/email]


Fernando Ortiz wrote:

> Hi Dave:
>
> Several months ago one of ours 4GL programs made a lot of DECLARE
> CURSOR/PREPARE without FREEing them, and yes the memory usage was
> increasing.
>
> In my case I use onstat -g stm to locate the statements prepared, fgrep the
> source to locate the offending code and adding the missing FREE .
>
> HTH
>
> ----- Original Message -----
> From: <dthacker@omnihotels.com>
> To: <informix-list@iiug.org>
> Sent: Thursday, September 04, 2003 3:55 PM
> Subject: Is gradually increasing memory in long running session normal?
>
>
>

>>I've been trying to debug a problem with a constantly running
>>application that is
>>experiencing a performance degradation over time. Today I set up a
>>script to
>>run onstat -g ses every 60 seconds and log the results. One of the
>>things that caught my eye is that this session's memory use increases
>>constantly over time.
>>For example,
>>
>> total
>> memory
>>13:38 1265664
>>14:38 1977408
>>15:38 2646016
>>
>>Will the total memory ever decrease during the lifespan of a session?
>>
>>Dave Thacker

>
>
> sending to informix-list

[Fernando Ortiz]

Hi Roland:

In our programs we also FREE the cursor

let query = "select ..."
prepare query_prep from query
declare query_curs cursor for query_prep
... open query_curs or foreach query_curs
...
... free query_curs
free query_prep

I use 4GL RDS 7.30UC7, IDS 9.30UC2, On RedHat Linux 7.2

----- Original Message -----
From: "Roland Wintgen" <rw@evg.de>
To: <informix-list@iiug.org>
Sent: Friday, September 05, 2003 5:40 AM
Subject: Re: Is gradually increasing memory in long running session normal?

> Hi Fernando,
>
> I changed our programs to prepare lots of heavily used statements
> instead of redeclaring the cursors.
>
> At least in one case it took me several months to identify one prepared
> statement which wouldn't free the allocated memory. I used the following
> identical syntax for several SQL-statements:
>
> let query = "select ..."
> prepare query_prep from query
> declare query_curs cursor for query_prep
> free query_prep
>
> This works for all but one function. The memory only gets released if
> the program ends. After rewriting the code and declaring the cursor
> every time it's used, everything works fine.
>
> Can anyone corfirm this?
>
> We're using 4GL RDS 7.30UC6 with IDS 7.30UC10 on SCO Unixware 7.1.1 and

this

> was reproducable on RedHat Linux 7.3 4GL RDS 7.30UC5 and IDS 7.30UC10.
>
>
> --
> Roland Wintgen (Systemadministrator)
>
> EVG Elektro-Vertriebs-Gesellschaft Martens GmbH & Co KG
> Trompeterallee 244-246, D-41189 Moenchengladbach
> phone +49 21 66 / 55 08 23, fax +49 21 66 / 55 08 90
> [url]www.evg.de[/url] [email]rw@evg.de[/email]
>
>
> Fernando Ortiz wrote:

> > Hi Dave:
> >
> > Several months ago one of ours 4GL programs made a lot of DECLARE
> > CURSOR/PREPARE without FREEing them, and yes the memory usage was
> > increasing.
> >
> > In my case I use onstat -g stm to locate the statements prepared, fgrep

the

> > source to locate the offending code and adding the missing FREE .
> >
> > HTH
> >
> > ----- Original Message -----
> > From: <dthacker@omnihotels.com>
> > To: <informix-list@iiug.org>
> > Sent: Thursday, September 04, 2003 3:55 PM
> > Subject: Is gradually increasing memory in long running session normal?
> >
> >
> >

> >>I've been trying to debug a problem with a constantly running
> >>application that is
> >>experiencing a performance degradation over time. Today I set up a
> >>script to
> >>run onstat -g ses every 60 seconds and log the results. One of the
> >>things that caught my eye is that this session's memory use increases
> >>constantly over time.
> >>For example,
> >>
> >> total
> >> memory
> >>13:38 1265664
> >>14:38 1977408
> >>15:38 2646016
> >>
> >>Will the total memory ever decrease during the lifespan of a session?
> >>
> >>Dave Thacker

> >
> >
> > sending to informix-list

sending to informix-list

[David Williams]

"Roland Wintgen" <rw@evg.de> wrote in message
news:3F586828.2010002@evg.de...

> Hi Fernando,
>
> I changed our programs to prepare lots of heavily used statements
> instead of redeclaring the cursors.
>
> At least in one case it took me several months to identify one prepared
> statement which wouldn't free the allocated memory. I used the following
> identical syntax for several SQL-statements:
>
> let query = "select ..."
> prepare query_prep from query
> declare query_curs cursor for query_prep

free query_curs

> free query_prep
>
> This works for all but one function. The memory only gets released if
> the program ends. After rewriting the code and declaring the cursor
> every time it's used, everything works fine.
>

free the cursor as well (before the prepared query!

> Can anyone corfirm this?
>
> We're using 4GL RDS 7.30UC6 with IDS 7.30UC10 on SCO Unixware 7.1.1 and

this

> was reproducable on RedHat Linux 7.3 4GL RDS 7.30UC5 and IDS 7.30UC10.
>
>
> --
> Roland Wintgen (Systemadministrator)
>
> EVG Elektro-Vertriebs-Gesellschaft Martens GmbH & Co KG
> Trompeterallee 244-246, D-41189 Moenchengladbach
> phone +49 21 66 / 55 08 23, fax +49 21 66 / 55 08 90
> [url]www.evg.de[/url] [email]rw@evg.de[/email]
>
>
> Fernando Ortiz wrote:

> > Hi Dave:
> >
> > Several months ago one of ours 4GL programs made a lot of DECLARE
> > CURSOR/PREPARE without FREEing them, and yes the memory usage was
> > increasing.
> >
> > In my case I use onstat -g stm to locate the statements prepared, fgrep

the

> > source to locate the offending code and adding the missing FREE .
> >
> > HTH
> >
> > ----- Original Message -----
> > From: <dthacker@omnihotels.com>
> > To: <informix-list@iiug.org>
> > Sent: Thursday, September 04, 2003 3:55 PM
> > Subject: Is gradually increasing memory in long running session normal?
> >
> >
> >

> >>I've been trying to debug a problem with a constantly running
> >>application that is
> >>experiencing a performance degradation over time. Today I set up a
> >>script to
> >>run onstat -g ses every 60 seconds and log the results. One of the
> >>things that caught my eye is that this session's memory use increases
> >>constantly over time.
> >>For example,
> >>
> >> total
> >> memory
> >>13:38 1265664
> >>14:38 1977408
> >>15:38 2646016
> >>
> >>Will the total memory ever decrease during the lifespan of a session?
> >>
> >>Dave Thacker

> >
> >
> > sending to informix-list

>

[Roland Wintgen]

Fernando Ortiz wrote:

> Hi Roland:
>
> In our programs we also FREE the cursor
>
> let query = "select ..."
> prepare query_prep from query
> declare query_curs cursor for query_prep
> ... open query_curs or foreach query_curs
> ...
> ... free query_curs
> free query_prep
>
> I use 4GL RDS 7.30UC7, IDS 9.30UC2, On RedHat Linux 7.2
>

Sure, but this way I have to reprepare the statement to use it again.
And that's no advantage instead of redeclaring the cursor everytime
it's needed.

> ----- Original Message -----
> From: "Roland Wintgen" <rw@evg.de>
> To: <informix-list@iiug.org>
> Sent: Friday, September 05, 2003 5:40 AM
> Subject: Re: Is gradually increasing memory in long running session normal?
>
>
>

>>Hi Fernando,
>>
>>I changed our programs to prepare lots of heavily used statements
>>instead of redeclaring the cursors.
>>
>>At least in one case it took me several months to identify one prepared
>>statement which wouldn't free the allocated memory. I used the following
>>identical syntax for several SQL-statements:
>>
>>let query = "select ..."
>>prepare query_prep from query
>>declare query_curs cursor for query_prep
>>free query_prep
>>
>>This works for all but one function. The memory only gets released if
>>the program ends. After rewriting the code and declaring the cursor
>>every time it's used, everything works fine.
>>
>>Can anyone corfirm this?
>>
>>We're using 4GL RDS 7.30UC6 with IDS 7.30UC10 on SCO Unixware 7.1.1 and

>
> this
>

>>was reproducable on RedHat Linux 7.3 4GL RDS 7.30UC5 and IDS 7.30UC10.
>>
>>
>>--
>> Roland Wintgen (Systemadministrator)
>>
>> EVG Elektro-Vertriebs-Gesellschaft Martens GmbH & Co KG
>> Trompeterallee 244-246, D-41189 Moenchengladbach
>> phone +49 21 66 / 55 08 23, fax +49 21 66 / 55 08 90
>> [url]www.evg.de[/url] [email]rw@evg.de[/email]
>>
>>
>>Fernando Ortiz wrote:
>>

>>>Hi Dave:
>>>
>>>Several months ago one of ours 4GL programs made a lot of DECLARE
>>>CURSOR/PREPARE without FREEing them, and yes the memory usage was
>>>increasing.
>>>
>>>In my case I use onstat -g stm to locate the statements prepared, fgrep

>
> the
>

>>>source to locate the offending code and adding the missing FREE .
>>>
>>>HTH
>>>
>>>----- Original Message -----
>>>From: <dthacker@omnihotels.com>
>>>To: <informix-list@iiug.org>
>>>Sent: Thursday, September 04, 2003 3:55 PM
>>>Subject: Is gradually increasing memory in long running session normal?
>>>
>>>
>>>
>>>
>>>>I've been trying to debug a problem with a constantly running
>>>>application that is
>>>>experiencing a performance degradation over time. Today I set up a
>>>>script to
>>>>run onstat -g ses every 60 seconds and log the results. One of the
>>>>things that caught my eye is that this session's memory use increases
>>>>constantly over time.
>>>>For example,
>>>>
>>>> total
>>>> memory
>>>>13:38 1265664
>>>>14:38 1977408
>>>>15:38 2646016
>>>>
>>>>Will the total memory ever decrease during the lifespan of a session?
>>>>
>>>>Dave Thacker
>>>
>>>
>>>sending to informix-list

>
>
> sending to informix-list

--
Roland Wintgen (Systemadministrator)

EVG Elektro-Vertriebs-Gesellschaft Martens GmbH & Co KG
Trompeterallee 244-246, D-41189 Moenchengladbach
phone +49 21 66 / 55 08 23, fax +49 21 66 / 55 08 90
[url]www.evg.de[/url] [email]rw@evg.de[/email]

[Dave Thacker]

[email]dthacker@omnihotels.com[/email] (Dave Thacker) wrote in message news:<554c618d.0309041255.4b687882@posting.google. com>...

> I've been trying to debug a problem with a constantly running
> application that is
> experiencing a performance degradation over time. Today I set up a
> script to
> run onstat -g ses every 60 seconds and log the results. One of the
> things that caught my eye is that this session's memory use increases
> constantly over time.
> For example,
>
> total
> memory
> 13:38 1265664
> 14:38 1977408A
> 15:38 2646016
>
> Will the total memory ever decrease during the lifespan of a session?
>

A short followup to this question. After we received the feedback in
the previous posts we started looking closely at the code for this
application. We found several cursors that were not freed in the
code. I think it's important to note that the code, however flawed,
had been in production for months and ran under the 7.31UC6 engine
with no problems. When we upgraded to 9.30, the same code would
gradually run slower and slower until it ground to halt. Restarting
the app would fix the problem...for a while.

We had both our programming staff and IBM consulting look at the
offending program and found we had cursors that were declared with
hold and were not freed. According to our consultant this is an issue
with 9.3 but is "fixed" in 9.4 We changed the program to declare the
cursors without hold, as the hold feature was not needed and freed the
cursors. After the changes were made, the memory issue was resolved.

Regards,
Dave Thacker