RE: OT: question about sizing swap for solaris

Another thing to think about is Belady's Anomaly. Remember that from
Operating Systems courses? It's a demonstration of how having more
memory can result in /more/ page faults for systems that use a
first-in-first-out memory management policy.

http://cne.gmu.edu/modules/vm/yellow/anomaly.html


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *

Upcoming events:
- Performance Diagnosis 101: 5/7 Dallas, 5/18 New Jersey, 6/22
Pittsburgh
- SQL Optimization 101: 5/3 Boston, 5/24 San Diego, 6/14 Chicago
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of
dantow@xxxxxxxxxxxxxx
Sent: Monday, May 03, 2004 3:03 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: OT: question about sizing swap for solaris

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?

A: NONE.

Thanks,

Dan Tow
650-858-1557
www.singingsql.com

Quoting zhu chao <chao_ping@xxxxxxxxxxx>:

> 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.

----------------------------------------------------------------
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 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@xxxxxxxxxxxxx
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
-----------------------------------------------------------------

Other related posts: