At 03:40 PM 12/10/2003 +0530, you wrote:

> > Rajesh, what do you mean user connects? Really connects or perform
> >first statement? If second, what UDFs do you use? Usually source of
> >memory leaks on server is UDF which don't free used memory or use
> >malloc not from ib_util and FREE_IT directive. You mentioned thin
> >client (I'm not familiar with DBExpress), is'nt application server
> >resident on the same machine and if so can't it buffer large results
> >or forget to free memory? Are datasets on application server
> >unidirectional? In general - don't knowing what your program do we
> >can't help.
> >
> >
>
>The memory shoots up when the user connects to the server not when the
>first statement fires. I ran a timing test to detect this.

Rajesh,
At the beginning of this thread you told us your server was SS. Yet, in
another posting, you supplied your isc_config file and it showed

#DATABASE_CACHE_PAGES 75

Are you sure you are not running Classic? If you had SS there, your
isc_config should show this figure as 2048. Check you /bin directory and
see what executables you have there.

Now, CS would account for your seeing memory usage shoot up when a user
connects. Classic runs a separate process and cache for each
connection. You have 8Kb page size, so each user gets allocated 600Kb of
cache.

I think you said you have plenty of RAM on the server, so these connections
shouldn't slow things down. As Paul commented, it's your application doing
that, not legit memory usage by the server. This has the classic
hallmarks of IBX apps either not committing, or using Autocommit and never
doing hard commits.

It would be interesting to know what kind of operations are slow, too. You
have a large number of really dreadful indexes there.

>I am now running tests shutting down tasks one by one on the server to
>detect if another application is causing a memory leak that is being
>aggravated by FB.

?????????????????????? Have you checked with ps to see whether these
"leaks" are in fact clients that are staying attached for some reason, e.g.
because big-time garbage collection starts up once the client finally
hard-commits something when the user hits the application's Exit button?

It would make sense to get all the users out of that IBX application and
try some connections using isql, so you can get some serious numbers.

heLen