Re: Capacity Planner from OEM VS Statspack
- From: Mladen Gogala <mladen@xxxxxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Fri, 6 Feb 2004 15:12:20 -0500
On 02/06/2004 01:28:08 PM, babette.turnerunderwood@xxxxxxxxxxxxxxx
wrote:
> I think the real issue is some form of swapping / paging going on.
> However, because of the way the mainframe handles the swapping /
> paging,
> It reports that it is not happening.=20
>
> I believe we have 2GB of REAL memory in this machine. We also have 10
> =
> instances with 300-600M of irtual memory each. Each Oracle process,
> =20
> runs in an Oracle service that can use up to 2GB of virtual memory=20
> for everything (eg SGA, PGA, sort..). The number is supposed to be
> 2GB,=20
> but in reality it is more like 1.8GB.
>
> This is TOTALLY different than UNIX. In UNIX the SGA sits in memory.
> In mainframe, only the active pages reside in memory. There is a=20
> "working set" that must be able to be loaded into real, expanded or =
> "disk swap area". The O/S decides which pages are active and they are
> in =
> memory.
> So when I startup an instance with 300M SGA, it might only load 80K
> of
Actually, it is not so different. I don't know whether you've ever
worked on a VAX/VMS, but everything below so called "virtual=real
memory line" on IBM mainframe is equivalent to the VAX/VMS "non-paged
pool". You don't want to load many things there because this area
is usually reserved for CICS control blocks DB/2 stuff and alike.
So called "virtual memory" is the normal, paged RAM with page tables,
TLB, L1,L2 and L3 caches. Then there is something called "channel
memory", which is, essentially, attached to disk controllers and is
analogous to the cache you can find on Symmetrix arrays.
You see, the difference between a mainframe and a minicomputer is
architectural. Minicomputer is interrupt-driven, which means that
periferals communicate with CPU(s) using interrupts. Mainframe
has "channels", which means that disks are atteched to the memory
and do not have direct communication with the CPU. When you want to
perform I/O on a maninframe, you fill in the form (called IORB) and
put it to certain memory location. So called "channel processor"
monitors that location, takes the "form" , performs the request and
puts the result in memory. When that is done, a single interrupt,
possibly piggybacking several I/O requests is sent to the CPU.
When a minicomputer wants to perform I/O, it generates a slew
of interrupts: CPU-> Controller: "are you ready?"
Controller->CPU "ready".
CPU-> Controller "setup DMA channel to buffer".
Controller->CPU "Set".
CPU->Controller "Read sector # into buffer".
Controller->CPU "Done."
Instead of all these messages, mainframe CPU gets only a single
interrupt for I/O done. That saves time and context switching.
Architecture like that is being explored on the minicomputers
and it's called "I2O". Advatnages of the channel architecture
are numerous, but the most obvious is much better CPU utilization.
The obvious thing to do is not to perform many task switches as
with time sharing option (TSO) but to have a single program run
all the time and perform transactions on behalf of the users.
Such programs are called "TP monitors" and on IBM, it's CICS.
Here I will conclude the computer architecture lesson for today.
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
