Right, on a normal load basis, this is correct.  But, in most "normal
load" machines, there are abnormal times.  Such as applying a service
pack, or a runaway program that eats up storage, or some bogus process
(or dumb user) starting up VNCSERVER, over and over (multiple copies
running), or.....

In a memory constrained system, it may be better (definitely for
test/development systems) to have swap go to dasd.  Then, you are only
impacting that machine.  When you have a big impact on the paging
system, almost everyone (including production) can be impacted.

Now, what is a major impact?  If paging is on escon, 100 paging I/O per
second was noticeable.  Now I'm on 200 MB Ficon/2 channels, I've driven
paging up to 1,000 I/O per sec and got no complaints.  I don't know
where that "knee" is, in my particule environment.  But I'm pretty far
away from it.

The point being is, if you are near your "paging knee", swapping to
real disk is better for the overall VM system, then a process  that
starts pounding vdisk and throwing your paging system out of whack.

Actually, Mark, we agree on the basics of vdisk/swap.  But I have never
seen a paging system that couldn't be swamped.  How many times have I
PEEKed a file, should have been 10,000 lines, but it was 1,000,000 lines
(or 10 million lines), and watch the paging system, deal with my error.
<G>

Like anything, vdisk can be abused.

The question I would like to send out to all....

Has anyone else experienced the problem where vdisk abuse causes your
VM paging system high enough activity to impact your other production
machines?  Or am I just lucky?

Tom Duerbusch
THD Consulting


>>> [EMAIL PROTECTED] 2/23/2007 1:33 PM >>>
>>> On Fri, Feb 23, 2007 at  1:48 PM, in message
<[EMAIL PROTECTED]>, Tom Duerbusch
<[EMAIL PROTECTED]> wrote:
> To some extent, I agree with your VM systems programmer.  IF you are
in
> a VM paging state, adding actively used vdisk, may not be the best
thing
> for you to do.

The recommendation to use VDISK for swap is intended to be used in
conjunction with a recommendation to shrink your virtual machines down
as much as possible, thus reducing the degree to which you're
over-committing real storage.  If you exchange virtual/real storage for
an increase in VDISK I/Os, you can usually manage to come out ahead of
the game.  The tolerable level of VDISK I/Os is surprisingly high (at
least to me).


Mark Post

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to