After running two or three weeks with 50-200 active sessions the Elevate 32-bit server crashes with EOutOfMemory exceptions. We use the server app. out of the box.   

Arno Garrels

Arno,

What version are you using, with what OS server ?

--
Fernando Dias
[Team Elevate]

> What version are you using, with what OS server ?

I'm not in the office right now (week end) so I guess elevate version is not older than two months.
OS is Win7 64-bit.

Since you are asking, were there any fixes of memory leaks within the past two months?

--
Arno

Arno Garrels wrote:
>>Since you are asking, were there any fixes of memory leaks within the past two months?

There has been a few releases in last 2 months : EDB 2.13 in June 20 and EDB 2.13 B3 end of july.

Neither specifically lists any memory issues but there have been quite a few fixes otherwise: http://www.elevatesoft.com/incident?action=addressed&category=edb&release=2.13

In general have not heard of memory leaks issues with EDB so this is something i would suggest you contact Elevate Support directly and they can help you troubleshoot quicker.

Raul

Arno,

As Raul already said, not in 2.13 but there was a fix in version 2.12 that could be related, but only if you are using in-memory databases.

--
Fernando Dias
[Team Elevate]

Arno Garrels wrote:

> After running two or three weeks with 50-200 active sessions the Elevate 32-bit server crashes with EOutOfMemory > exceptions. We use the server app. out of the box.   

I might not be correct when I say "EOutOfMemory". My workmate told me that while he was checking server's memory usage with Taskmanager he suddenly noticed a significant jump from 1.6 GB to 1.8 GB followed by the crash. So actually we just assume the reason was "not enough memory". Although today I noticed the LargeAddressAware PeFlag set in server source code and I'm pretty sure that Win7 is a 64-bit version (however have to check that on Monday as well as the EDB-version).

--
Arno

Arno Garrels wrote:
>I might not be correct when I say "EOutOfMemory". My workmate told me that while he was checking server's
>memory usage with Taskmanager he suddenly noticed a significant jump from 1.6 GB to 1.8 GB followed by the
>crash. So actually we just assume the reason was "not enough memory". Although today I noticed the
>LargeAddressAware PeFlag set in server source code and I'm pretty sure that Win7 is a 64-bit version (however >have to check that on Monday as well as the EDB-version).

I don't recall EDB being LAA aware at all - it's not just a matter of LAA flag in the image header but i thought code has to take advantage of 3GB of virtual address space as well. Then again my knowledge of this is weak.

Since your crash happens very close to 2GB limit (1.8GB observed) of a normal 32bit app virtual address space it might just be that EDB runs out of ram.

If you have lot of session and tables open (like you do) this might be just internal buffering and not any leakage - you can query the ServerSessionStatistics table of a running instance (http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=ServerSessionStatistics_Table) to see how much space is being used for buffering.

One option that comes to mind is just run 64bit version of the EDB server. It will work with 32bit clients and would remove the 2GB virtual address space limit. Your OS was 64bit so this should work fine.

Raul

Arno Garrels wrote:

> however have to check that on Monday as well as the EDB-version.

The version we use is 2.13 Build 2.
And the VM is Win7 64-bit with just small 4 GB RAM.
Today (early Monday morning) there where 13 active sessions and they used 800 MB private bytes.
That IMO looks far too much to me, what do you think?

--
Arno

On 9/9/2013 11:54 AM, Arno Garrels wrote:
> Arno Garrels wrote:
> The version we use is 2.13 Build 2.

There is a newer build 3 though i think your issue might be low memory
problem.

> And the VM is Win7 64-bit with just small 4 GB RAM.
> Today (early Monday morning) there where 13 active sessions and they used 800 MB private bytes.
> That IMO looks far too much to me, what do you think?

it depends on your usage scenario - i would not consider 800MB too much
though with large databases.

How big are the databases and tables these users access?
Does your app keep the tables open all the time?
Have you checked ServerSessionStatistics  table to see if most of this
is due to tables being open and buffered or something else ?

Raul

Arno,

<< After running two or three weeks with 50-200 active sessions the Elevate
32-bit server crashes with EOutOfMemory exceptions. We use the server app.
out of the box. >>

There are no known memory leaks in the EDB Server.  Please don't state
things that aren't true before verifying what the actual situation is.

My guess, based upon the limited information that you provide, is that
you're using more process address space than the 32-bit EDB Server can
handle.  The solution is to use the 64-bit EDB Server, which will fix the
issue.

EDB sessions can be memory-intensive, depending upon how many tables you
keep open, how many configuration/information schema queries you make, etc.
You can also run into issues by having too many dead sessions hanging around
in the EDB Server, although those would be visible in the sessions list so
you should be able to see those.

Tim Young
Elevate Software
www.elevatesoft.com