| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: OT: question about sizing swap for Solaris
Swap on Solaris is so much more fun than other systems. Roughly 50% to 75% of physical memory is considered swap space. If you don't believe me check the swap information output from a "top | grep Memory" command and compare it to the "swap -l" output. You should see that your swap space is larger than what the total disk space allocated to swap is......fun stuff. I haven't been on another Unix in years (AIX, HP, Etc.) so I can't say if the others have converted to what Solaris did to swap back in release 2.1 (Sun OS 5.1) or something like that.
What Bob Larson's papers are really saying about a hard-pageout is that this is when a page is moved from the swap memory on the chip to the swap memory on the disk. To much of this will kill your response time the next time something is called, and anybody that says that isn't true isn't paying attention. So in reality, having swapped sized to large means you are relying on disk swap to much and that you don't have enough on chip memory swap......IE: Buy more chip memory.
References:
http://www.sun.com/bigadmin/content/documents/SolarisPerfAdmin.paper.pdf
http://www.sun.com/solutions/blueprints/1202/817-1054.pdf
http://citeseer.ist.psu.edu/chartock91virtual.html
dantow_at_singingsql.
com To: oracle-l_at_freelists.org
Sent by: cc:
oracle-l-bounce_at_fr Subject: Re: OT: question about sizing swap for solaris
eelists.org
05/03/2004 01:02
PM
Please respond to
oracle-l
It makes no sense to me. An analogous statement would be "Buying a large
gas
tank may prevent you from realizing what a gas-guzzler you are driving." At
the
point where you use so much swap that physical ("hard") page-outs to swap
space
(or, more accurately, the hard page-ins that could follow) would become a
problem, the alternative, if you had sized swap more modestly, would be
out-of-memory errors (like running out of gas). The only possible advantage
of
that alternative is that it is harder to ignore out-of-memory errors than
to
ignore poor performance attributable to excessive paging. The real problem
(in
theory), whether you get poor performance, or prevent it by triggering even
worse errors by making swap run out before poor performance sets in, is
that
you don't have enough memory to run the application without excessive
paging/swapping.
That's the theory. In practice, memory is *cheap* and there is virtually
always
*plenty* of it, so if you are getting out-of-memory errors, you are
probably
nowhere near having paging problem and should just increase swap (which can
often be justified to be as much as 5 times the size of real memory, *if
memory
wasn't over-sized* (not that over-sizing memory is so bad - it *is*
cheap)).
(The average real-world application has an immense amount of virtual memory
dedicated to very idle processes and very idle pages of processes, such
that
paging and swapping out these idle parts of virtual memory bears almost no
cost
to performance at all, contrary to popular belief. I have seen busy
produciton
systems with fully half their processes swapped out, and much of the
remainder
paged out, with very low actual activity on the swap disks, translating to
very
little actual performance impact on the end users.)
Q: In almost 15 years of work on performance, how many times have I seen a system with paging and swapping performance costs that were high, without a special cause such as a bug in the swapping algorithm?
Dan Tow
650-858-1557
www.singingsql.com
Quoting zhu chao <chao_ping_at_vip.163.com>:
> Hi,
> I am reading sun performance paper: Performance Oriented System
> Administration and see the following setense:
> "However, sizing swap to be too large can cause hard-pageout to occur too
> easily"
> I do not understand what on earth this mean, can some one kindly
explain
> this? And why it will make hard-pageout occur?Is there documents talking
> about this feature?
> Thanks.
> Zhu Chao.
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Mon May 03 2004 - 17:46:21 CDT
 |
 |