Subject | Re: Understanding memory for each connection under classic architecture |
---|---|
Author | peterson77 |
Post date | 2010-02-08T16:07:18Z |
Thanks for your reply. I guess my question is changing as my understanding evolves. What prompted this question was the large difference in performance time between a query processed via JDBC and one processed through ISQL. JDBC time was 180 seconds while ISQL time was 5 seconds. As the result set was quite small, I was assuming that the difference in performance time was related to memory differences.
As reported by 'top', the VIRT memory of an fb_inet_server process created through jdbc is 32meg while isql's fb_inet_server process size is larger at 49meg. I am hoping to track down why the size of an fb_inet_server process created through Jaybird/JDBC would be so different than the size of the an fb_inet_server process created through ISQL. The size of the each process does not change significantly while queries are being performed. How can I make the memory footprint of the JDBC connections more like the ISQL connection?
p.s. While I am using the classic server architecture, there are only 8 connections in a connection pool, so my understanding was that 2048 buffers was not too much -- 8 meg/connection * 8 connections = 64meg devoted to buffers. Is there some other reason besides memory to keep the number of buffers low in this set-up?
- Steve
As reported by 'top', the VIRT memory of an fb_inet_server process created through jdbc is 32meg while isql's fb_inet_server process size is larger at 49meg. I am hoping to track down why the size of an fb_inet_server process created through Jaybird/JDBC would be so different than the size of the an fb_inet_server process created through ISQL. The size of the each process does not change significantly while queries are being performed. How can I make the memory footprint of the JDBC connections more like the ISQL connection?
p.s. While I am using the classic server architecture, there are only 8 connections in a connection pool, so my understanding was that 2048 buffers was not too much -- 8 meg/connection * 8 connections = 64meg devoted to buffers. Is there some other reason besides memory to keep the number of buffers low in this set-up?
- Steve
--- In Firebird-Java@yahoogroups.com, "Mark Rotteveel" <Avalanche1979@...> wrote:
>
> > I need to tune an application using Jaybird 2.1.6/Firebird 2.1 classic in
> > a tomcat application on a 6gig RHEL 5 box.
> >
> > When I run 'top' on the server, each fb_inet_server process created via
> > Jaybird takes around 32meg of VIRT memory and I would like to understand what
> > goes into this memory footprint.
> >
> > 1) The buffers are set to 2048 (gfix -buffers 2048). This means each
> > connection should take 8 meg (2048 x 4k page = 8meg).
> >
> > 2) The TempCacheLimit (formerly SortMemCacheLimit) is not set in
> > firebird.conf, so the default should be 8meg. This means each connection should
> > take an additional 8meg.
> >
> > I am not specifying any connection parameters in the Jaybird connection
> > string. So all told, it looks like each connection should take 16meg. Why
> > then is each connection actually taking 32meg? What am I missing?
>
> This is a totally different question than the one you asked on Firebird-support. This question is one that can better be directed to Firebird-support as it is about the general behaviour of Firebird and has nothing to do with the Java/Jaybird side of things.
>
> To answer your question:
> 1) In general 2048 pages of buffer is considered too much for a classic server. The default is 75 and more pages should only be used if you really need it, otherwise it is better to let the OS filesystem cache handle the caching.
>
> The cache and sortspace is not the only things that take memory in a Firebird process. Think about the data needed to process the statement, connection details, the data actually materialized from the database to send to the client, etc.
>
> Mark
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>