When the session is established, we'll assign some PGA memory to it.
SQL> conn mcdonac/*******
Connected.
SQL> select s.name, st.value
2 from v$statname s, v$mystat st
3 where st.STATISTIC# = s.STATISTIC#
4 and s.name = 'session pga memory max';
NAME VALUE
-------------------------------------------------- ----------
session pga memory max 2556824
As you do operations (SQL etc) you will then consume perhaps more pga memory depending on what you are doing, eg
SQL> select s.name, st.value
2 from v$statname s, v$mystat st
3 where st.STATISTIC# = s.STATISTIC#
4 and s.name = 'session pga memory max';
NAME VALUE
-------------------------------------------------- ----------
session pga memory max 2950040
so I used up a couple of hundred kilobytes to parse, execute and fetch from this query. If I so something that needs a LOT of pga (eg a big sort)
SQL> create table xxx1 as select * from dba_objects order by 1,2,3,4;
Table created.
SQL> select s.name, st.value
2 from v$statname s, v$mystat st
3 where st.STATISTIC# = s.STATISTIC#
4 and s.name = 'session pga memory max';
NAME VALUE
-------------------------------------------------- ----------
session pga memory max 40174488
1 row selected.
then you can see it bump up. But also, once that operation is completed, that figure is a high water mark - you can see that my *current* memory drops back down again as below:
SQL> select s.name, st.value
2 from v$statname s, v$mystat st
3 where st.STATISTIC# = s.STATISTIC#
4 and s.name = 'session pga memory';
NAME VALUE
-------------------------------------------------- ----------
session pga memory 6030232
Whether that is released back to the OS is dependent on platform and version.
So a couple of things:
a) It seems a little high that you are burning 30meg per connection the moment those sessions start. You can see my example is around 2.5meg, and to get to 40meg, I had to do a nice big sort. That perhaps raises questions about the code in your application.
b) With a fixed number of connections (ie 50 in your pool), the ram allocation would be expected to go up to a "limit", ie the required pga to handle 50 sustained connections, and then level off. If its continuing to grow and grow, that would suggest an application fault of some kind, because that is one of the things a connection pool is designed to avoid.
Hope this helps.