Subject | Re: [Firebird-Java] Re: Understanding memory for each connection under classic architecture |
---|---|
Author | Roman Rokytskyy |
Post date | 2010-02-08T16:31:18Z |
> 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