Subject Re: [Firebird-Java] Re: Understanding memory for each connection under classic architecture
Author Roman Rokytskyy
> 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?

I wonder if iSQL and Java process use different connection parameters.
The default DPB should be the same, and it should consume then the same
amount of memory.

But I have another question - how do you connect to your database with
iSQL? Is on the same host? What is your CONNECT string looks like?

> 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?

When you update record, a page gets invalidated among all Classic
instances and will be reloaded. So with update-intensive application you
will just waste your memory. In a SuperServer you have a shared cache,
so an update will not cause page reload from the disk.

Roman