This reminds me very much of a story that Barton Robinson still tells in
his presentations. When they were first running Linux for S/390, they
defined a somewhat large virtual machine (thinking was necessary) and
ran some long compile. This was on a machine with 128M of real storage
(I think). The compile took forevvvvver and the machine was running
very hot (CPU and disk I/O) during the process. I don't know how long
it took to come up with this, but they eventually backed off the Linux
virtual machine to 24M and some Vdisk. The compile ran significantly
faster with a minimal load on the system.
If any of my facts are clouded, I'm sure Barton will correct them. But
the moral is, that Vdisk can be a big help even in a memory constrained
system. How much Vdisk and how much help is an answer for testing and
measurement.
Tom Duerbusch wrote:
Don't wait.
If you are not storage constrained then vdisk for swap should almost
never be a problem. My complaint was about vdisk in a storage
constrained system, being abused by some memory hog process.
How much vdisk? That's a tuning/monitoring process. I use 3 vdisks,
16 MB, 32 MB and 64 MB with different priorities. I think that is
overkill for some of my machines, but hasn't been insufficient for any
of them (yet). But my point has been, if you define it, expect that it
may be totally used at some point (in my case, increasing the working
set size by 112 MB, had a major impact on my production machines). I
was in a 1 GB lpar, that was memory constrained, so a bump of 10% in
working set size, was an issue. VS having a 16 MB vdisk, and a 3390
pack for second level swap.
We have only been discussing a very minor set of circumstances, that, I
agree, we shouldn't be in anyway. But, when in the trenches, you have
to deal with, what you have.
Think about, but don't worry about the 2 GB storage relief in 5.2. The
storage problem was mostly in large, heavy I/O shops, as all I/O had to
be done below the 2 GB line. With 5.2, that is no longer the case.
Now, if your Linux images are going to be large, such as 4 GB Oracle,
or DB2/UDB, and they become heavy I/O contenders, then you need to
think/rethink/watch out, for that problem.
Tom Duerbusch
THD Consulting
[EMAIL PROTECTED] 2/26/2007 1:51 PM >>>
All, looking for comments (situation below) on VDISK implementation
for
linux swap. After having read all the recent posts on use of VDISK
(including layers) which we intend to do, mainly interested in timing
of
same?
1. "proceed vs. wait" with implementing VDISK swap space for RHEL
guests running on z/VM Version 5 Release 1.0, Service Level 0601
(64-bit). We have had zVM5.2 on standby awaiting a DASD subsystem
replacement (now zVM5.3 is available :-) ) & no space for 2nd level
installation/testing. Current LPAR's (on redundant z9's) are not
currently storage constrained - 1st at 40% of 12G & 2nd at 60% of 8G
(each defined less 1G as XSTORE).
Note: aware of many Conference Presentations indicating much better
memory management (ie. above 2G line) with 5.2 or above; hence wanting
advise/opinions on proceeding at 5.1 vs. waiting. We had hoped to
have
the DASD subsystem upgraded in Jan, but still waiting - and best guess
would be late April early May before VM upgrade could be done, so
wondering if I would have any negative affects of proceeding with
VDISK
swap areas at 5.1?
Opinions please! Thanks
--
[EMAIL PROTECTED]
ITS/CS Network Systems Programmer
State of North Carolina
Office of Information Technology Services
-----
E-mail correspondence to and from this address may be subject to the
North Carolina Public Records Law and may be disclosed to third parties
by an authorized state official.
-----
----------------------------------------------------------------------
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
--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service: 360-715-2467
rich.smrcina at vmassist.com
Catch the WAVV! http://www.wavv.org
WAVV 2007 - Green Bay, WI - May 18-22, 2007
----------------------------------------------------------------------
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
