Now you mention it, I have seen some other
operating system use a reference to 'large'
(4MB) pages.
I have heard some comments, though, about
one of the Solaris versions not being able
to use shared page tables (ISM) when the
SGA goes over a critical limit - but this could
be highly
: Big SGA...
... large burlap sack and a small bat
-Original Message-From: Loughmiller, Greg
[mailto:[EMAIL PROTECTED]Sent: Tuesday, March 04,
2003 7:39 AMTo: Multiple recipients of list
ORACLE-LSubject: RE: Big SGA...
duct tape
Linux has two patches to deal with that. One is the highpte patch which
allows page table entries in high memory (i.e. after 1Gb). The other is
bigpages which allows larger pages (i.e. 4mb instead of 4kb), thus fewer
page table entries. Both patches are for Red Hat AS 2.1. I imagine that
the
duct
tape
-Original Message-From: Tim Gorman
[mailto:[EMAIL PROTECTED]Sent: Monday, March 03, 2003 5:10
PMTo: Multiple recipients of list ORACLE-LSubject: Re:
Big SGA...
Sybase, Schmybase, Oracle, Schmoracle -- the
concepts are still the same. Developers create
... large burlap sack and a small bat
-Original Message-From: Loughmiller, Greg
[mailto:[EMAIL PROTECTED]Sent: Tuesday, March 04, 2003
7:39 AMTo: Multiple recipients of list ORACLE-LSubject:
RE: Big SGA...
duct
tape
-Original Message-From: Tim
A late-breaking thought - but it's not my area
of expertise, so others may laugh.
If you have a very large SGA, don't you end
up with a very large 'page table' at the O/S
level to map virtual memory to real memory.
And if you do, doesn't this affect the speed
and cost of a context switch. If
Title: RE: Big SGA...
... applied to the parent who spoiled the child ...
Jerry Whittle
ASIFICS DBA
NCI Information Systems Inc.
[EMAIL PROTECTED]
618-622-4145
-Original Message-
From: Kevin Lange [SMTP:[EMAIL PROTECTED]
... large burlap sack and a small bat
This will help end-user performance *only* if a significant proportion of their
response time is presently consumed doing physical disk I/O
(e.g., either db file scattered read or db file sequential
read events).
Its possible that your strategy
might help, but in my estimation, its not
We have SGA's as large as 22 Gb. I don't know that this solves any of the
inherent application problems, but it doesn't appear to cause any problems.
OS here is Tru64.
-Original Message-
One could suggest that they could cache some very large tables in the SGA;
but there seems to be
Please start using STATSPACK now to gather and keep
statistics. You are certainly going to need "before" and "after"
statistics to analyze.
Some questions:
Why does the development group think that I/O is
the problem? Have they been gathering data? Have you seen
it? Do you concur
One additional consideration on this topic is the politics of the situation.
If your shop is one where development has undue influence on upper
management decisions (i.e. the tail wagging the dog), the politics might be
such that garbage is deployed and it's expected that the support people
(i.e.
I know of one system where it would have been
beneficial to have an 8GB buffer_pool_keep
(as you might guess, this was a specialised
telecomms system); but I think the general rule
should be to consider very large memory as a
requirement that has to be proved, rather than
an obvious easy option.
: Tim Gorman
[mailto:[EMAIL PROTECTED]Sent: Monday, March 03, 2003 2:02
PMTo: Multiple recipients of list ORACLE-LSubject: Re:
Big SGA...
Please start using STATSPACK now to gather and
keep statistics. You are certainly going to need "before" and "after"
s
Title: RE: Big SGA...
BINGO!!
The politics is definitely a key contributor to all projects here in this shop:-)
greg
-Original Message-
From: Stephen Lee [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 03, 2003 3:39 PM
To: Multiple recipients of list ORACLE-L
Subject: RE
in public. How do you quiet the child?
:-)
- Original Message -
From:
Loughmiller, Greg
To: Multiple recipients of list ORACLE-L
Sent: Monday, March 03, 2003 2:28
PM
Subject: RE: Big SGA...
one
little piece of information..(considered critical
probably
? :-)
- Original Message -
From: Loughmiller, Greg
To: Multiple recipients of list ORACLE-L
Sent: Monday, March 03, 2003 2:28 PM
Subject: RE: Big SGA...
one little piece of information..(considered
critical probably:-) )
There isn't an opportunity
Subject: RE: Big SGA...
one little piece of information..(considered
critical probably:-) )
There isn't an opportunity to use statspack... The
current application is running on sybase:-)
I do have other teams researching the questions
you mention. its a real fun
17 matches
Mail list logo
