> Locking pages for performance is normally a Very Bad Idea (TM). Don't
> do that. If you really want, you could steer CP a bit with SET
> RESERVED but you probably need to look at other options.
vm has 2gb storage, there is only one linux guest with 1gb storage defined, no other guests
(except some system stuff like tcpip etc. and some administration users).
before i locked the pages of the linux guest i saw paging rates between 200 and 800 per
second, mdc size was about 1.2gb (if i remember right).
my first action was to reduce mdc to 600mb, which reduced paging, but vm still paged out
some pages of the linux guest so i still had some paging when the linux was busy.
because there is no other linux guest to serve i decided to lock the pages of the guest,
now paging is amlost zero. (i wanted to use V=R but because this is no longer supported
with vm 5.2 (we will migrate some day) i did not want to use it, so i thought locking the
pages is almost the same as V=R).
I thought this was a "very good" setup when you only have to serve one guest to serve,
and not a "very bad" one?!?
Regards, stefan.
| Rob van der Heij <[EMAIL PROTECTED]>
Sent by: VM/ESA and z/VM Discussions <[email protected]> 02.02.2006 12:00
|
|
On 2/2/06, Stefan Raabe <[EMAIL PROTECTED]> wrote:
We should probably take the Linux discussion to the LINUX390 list...
> i thought it could be possible to lock the v-disk because the performact toolkit shows
> "residend" "locked" and "dasd" page numbers on the vdisk display.
Yes, the pages of a VDISK life in the z/VM paging subsystem and rmay
reside in main memory, expanded memory, on disk or nowhere... I
expect pages are locked only when they are involved in an active I/O.
> I already locked the pages of the linux guests because i found it was fighting for
> the storage with the MDC. (i know i can limit the MDC too, but i decided to lock
> the linux guest pages). this reduced paging from several hundred pages per second
> to almost zero. there is only one linux guest in this vm system.
Locking pages for performance is normally a Very Bad Idea (TM). Don't
do that. If you really want, you could steer CP a bit with SET
RESERVED but you probably need to look at other options.
Yes, the defaults for CP typically give too much main memory to MDC.
My preference is to adjust the BIAS on the SET SRM command but some
others set a maximum on MDC.
> i am afraid that this fight for storage starts again when i use v-disk for linux swap (V-DISK vs MDC)
MDC is not effective for swap because Linux will normally not read a
page a 2nd time. Why do you think you have a "fight" for memory?
> Whats the best practice for this? limit MDC size so there is enough "free" storage for the v-disk?
You should probably limit MDC in main memory by a maximum or with a
bias. Set the maximum MDC for XSTORE at 0M.
> While i am on this: what is the recommendation for the linux swap size? same as linux storage size? half of
> linux storage size?
That number is a myth. From what I know it stems from the days where a
bug in BSD prevented you from having more swap space than half the
memory size, so you'd aim for the maximum.
What you want is sufficient "memory" (virtual machine plus swap) to
allow the concurrent processes to allocate virtual memory. The tuning
option you have is to decide what portion of memory you allocate as
virtual machine size. This really depends on the application workload
and the importance (and somewhat on the physical resources that you
have). You probably need to measure that for each type of system and
adjust accordingly.
YMMV I know people who run their 1G virtual machine with 16G of swap space.
Rob
--
Rob van der Heij rvdheij @ gmail.com
Velocity Software, Inc
Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte
Informationen.
Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte
sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte
Kopieren
dieser E-Mail oder die unbefugte Weitergabe der enthaltenen
Informationen
ist nicht gestattet.
The information contained in this message is confidential or protected
by
law. If you are not the intended recipient, please contact the sender
and
delete this message. Any unauthorised copying of this message or
unauthorised distribution of the information contained herein is
prohibited.
