|Subject||Re: [firebird-support] Re: Performance Degrade - HELP|
> Rajesh, what do you mean user connects? Really connects or performThe memory shoots up when the user connects to the server not when the
>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
first statement fires. I ran a timing test to detect this.
There is no application server here. It is a simple client server
application running with Win2K pro clients & RH8 Linux server using
dbxpress drivers with Delphi. I don't use any UDF's. The code was
purposely kept that way so that the app can migrate to any other rdbms
if the need arises ever. No stored procedures too.
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.
>>Can people here share the maximum db sizes that they have used withI presume your db of 6GB is multiple files ... how many files ? How many
>>Has anyone used FB database of more than 500MB without performance
> Personally I - more than 6 Gb with about 30 simultaneosly connected
dbpages per file ? Can you let me know ? Is it hosted on WinNT or Linux
? Maybe I need to split my db into multiple files to solve the problem ?
The server stats show that ibserver task allocated memory keeps rising.
At the end of 5 hours it is at 288 MB. Which does not sound right. The
footprint of fb is supposed to be very small. Maybe the database is
allocating some memory but not deallocating it when the size of the db
file is beyond a certain range on Linux with the specific kernel that I
am using (2.18-4).
Will post the results of my observations about other tasks affecting fb
over the next 48 hours.
At the moment though the problem still continues ...