Re: How to trace what is happening inside the stored procedure
- From: Tanel Põder <tanel.poder.003@xxxxxxx>
- To: "Oracle L (E-mail)" <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 7 Feb 2005 00:18:08 -0000
> What, from 32 bytes? In this day and age of multi-Gb memories even in PC=
> 's?
Well, the structure containing session information is a fixed array as far
as I know, with fixed data element offsets, so you need to pre-allocate the
max amount of memory needed for for all elements, for each session record,
so in large number of sessions this might take several(tens) of megabytes.
Yep, I don't argue with you, memorywise it's nothing in todays servers, but
trying to understand, why Oracle has gone with such figures - for old-school
low-level kernel developers in Oracle this 32 and 48 bytes may have seemed
to be more than enough, because historically they have done well with less
than 10 byte abbreviated variable and function names in kernel (like
ksusegst, ksmsp, kglob, ktuxe etc..).
Another reason why keeping these structures small I can think of is that if
your session structures start to span several virtual memory page
boundaries, more soft page faults will occur and since these structures are
accessed quite often, it might mean more CPU usage due VM engine servicing
in systems using small pagesizes such 4kB.
I think this is unlikely the reason, since additional CPU usage will be
marginal, especially with modern CPUs with more usable TLB cache slots and
large pagesizes, but the point is that it's sometimes about more than just
memory usage, but also memory usage performance.
Tanel.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
