Hello Group,
We are looking at possibly reducing our memory usage and making our SLES9
z/Linux "better". There are different opinions about what to do and
what the costs are.
A). VM Memory Disk (VDISK). Currently we do not use VDISK for our production
zLinux servers on our z/VM 5.2 syst
ave Hansen
Sent: Thursday, February 22, 2007 11:23 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Perceptions of zLinux
Hello Group,
We are looking at possibly reducing our memory usage and making
our SLES9 z/Linux "better". There are different opinions about what to
do and what
>>> On Thu, Feb 22, 2007 at 2:23 PM, in message
<[EMAIL PROTECTED]>,
Dave Hansen <[EMAIL PROTECTED]> wrote:
-snip-
> A). VM Memory Disk (VDISK). Currently we do not use VDISK for our
> production zLinux servers on our z/VM 5.2 system. I see SLES 10 recommends
> two
> VDISKs. Is there a dow
07 01:23 PM
Subject
Perceptions of zLinux
Please respond to
Linux on 390 Port
Hello Group
On 2/22/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
B). Shared Kernel.
[ snip ]
A lot of what you find in documentation is simply out-of-date. Just a few:
* The issues with stand-alone dump for Linux running from NSS have
been sort-of resolved because there are tools now to process a VMDUMP
ins
Rob van der Heij wrote:
* The entire ramdisk thing that modern distributions use is a royal
PITA as far as footprint is concerned. I have tried to make that also
use NSS but could not get that done. So while you carefully save 1 MB
of virtual machine in the kernel, immediately after that the ram
On Feb 22, 2007, at 1:23 PM, Dave Hansen wrote:
A). VM Memory Disk (VDISK). Currently we do not use VDISK for our
production zLinux servers on our z/VM 5.2 system. I see SLES 10
recommends two
VDISKs. Is there a downside to using VDISK? About the only thing
I saw is that VDISK doesn't do ex
07 01:23 PM
Subject
Perceptions of zLinux
Please
On 2/22/07, John Summerfield <[EMAIL PROTECTED]> wrote:
The ramdisk should be able to be put, uncompressed, into a DASD all by
itself, and mounted from there. Or placed, unpacked into /boot along
with the kernel. A DASD probably is simpler, being a near drop-in
replacement for where the initrd g
On Thu, Feb 22, 2007 at 09:47:51PM +0100, Rob van der Heij wrote:
> On 2/22/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
>
> >B). Shared Kernel.
> [ snip ]
>
> * My (yes, indeed!) SAVESYS= option never managed to win the heart of
> those who rule that world so they found something else. There is (or
Rob van der Heij wrote:
On 2/22/07, John Summerfield <[EMAIL PROTECTED]> wrote:
The ramdisk should be able to be put, uncompressed, into a DASD all by
itself, and mounted from there. Or placed, unpacked into /boot along
with the kernel. A DASD probably is simpler, being a near drop-in
replaceme
On Friday, 02/23/2007 at 01:21 ZE9, John Summerfield
<[EMAIL PROTECTED]> wrote:
> I would expect the modules to be copied to (virtual) RAM, but if you're
> using a compressed initrd then they're going to be copied twice.
I think what we'd want is to be able to have initrd in an NSS be an
uncompre
On 2/23/07, Alan Altmark <[EMAIL PROTECTED]> wrote:
> I would expect the modules to be copied to (virtual) RAM, but if you're
> using a compressed initrd then they're going to be copied twice.
I think what we'd want is to be able to have initrd in an NSS be an
uncompressed xip2fs filesystem. x
To
> >
> LINUX-390@VM.MARIST.EDU
> > cc
> > 02/22/2007 01:23 PM
> > Subject
> >
> Perceptions of zLinux
> &
cc
02/23/2007 12:21 AM
Subject
Re:
Perception
On 2/23/07, James Melin <[EMAIL PROTECTED]> wrote:
Sadly, no. I am not joking. I was told to remove it, so I did. Under protest.
Had it working perfectly. I think it's time to re-visit this, however.
Yes, you should. Some VM folks have old thumbs whose rules don't fit
current workload.
Wha
So how does one determine the size, in memory, of the uncompressed kernel
image? That would give me more sense of the savings of doing this. I feel
the savings will be insignificant at the scale we are currently at, but hard
numbers are helpful.
Linux on 390 Port wrote on 02/23/2007 09:45:30 A
On 2/23/07, James Melin <[EMAIL PROTECTED]> wrote:
So how does one determine the size, in memory, of the uncompressed kernel
image? That would give me more sense of the savings of doing this. I feel
the savings will be insignificant at the scale we are currently at, but hard
numbers are helpful
larly scheduled message.
> >
> >
> >
> >
> > Dave Hansen <[EMAIL PROTECTED]>
> > Sent by: Linux on 390 Port
> >
To
> >
> LINUX-390@VM.MARIST.EDU
> >
cc
> > 02/22/2007
>>> 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 t
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.
>>> On Fri, Feb 23, 2007 at 3:21 PM, in message
<[EMAIL PROTECTED]>, Tom Duerbusch
<[EMAIL PROTECTED]> wrote:
> 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 s
On 2/23/07, Tom Duerbusch <[EMAIL PROTECTED]> wrote:
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 produc
>>> On Fri, Feb 23, 2007 at 4:35 PM, in message
<[EMAIL PROTECTED]>, "Tom Duerbusch"
<[EMAIL PROTECTED]> wrote:
> What is the "Linux OOM killer"?
>
> Is it part of the standard Linux install, a product to be installed, or
> a product to be bought?
>
> The problems I had with vdisk abuse, and th
"I claim that "Linux swap to real DASD is good for one thing, and
that's to slow them down" From your post I understand that is your
approach to tuning."
No, that's not true.
My approach is not to hurt the production systems, when a development,
test, or service machine gets in trouble. In a sh
What is the "Linux OOM killer"?
Is it part of the standard Linux install, a product to be installed, or
a product to be bought?
The problems I had with vdisk abuse, and the paging system, was on
SLES8 on the MP3000. Perhaps later favors have OOM?
Tom Duerbusch
THD Consulting
(once shot, twice s
Ok, OOM...yea it has been around.
My experience is once it starts killing processes, it is time to cycle
that image.
The hard part is knowing how much vdisk you need to handle the
exception conditions (like maintenance or compiling or...) but not so
much as that the only time it would be fully us
On Fri, 23 Feb 2007 15:35:09 -0600
Tom Duerbusch <[EMAIL PROTECTED]> wrote:
> What is the "Linux OOM killer"?
>
> Is it part of the standard Linux install, a product to be installed, or
> a product to be bought?
Its the piece of code in the kernel which, when there is no free memory
or swap picks
>>> On Fri, Feb 23, 2007 at 5:22 PM, in message
<[EMAIL PROTECTED]>, Tom Duerbusch
<[EMAIL PROTECTED]> wrote:
> Ok, OOM...yea it has been around.
>
> My experience is once it starts killing processes, it is time to cycle
> that image.
>
> The hard part is knowing how much vdisk you need to hand
Proper tools are a great thing, especially free ones.
But in reality, what percentage of shops have the proper tools? My
guess, is under 25%. Barton has a very large segment to be tapped..
One of the origional posts was on the pros and cons of vdisk. No one
brought up that it is a shared resou
>>> On Sat, Feb 24, 2007 at 10:36 AM, in message
<[EMAIL PROTECTED]>, Tom Duerbusch
<[EMAIL PROTECTED]> wrote:
-snip-
> One of the origional posts was on the pros and cons of vdisk. No one
> brought up that it is a shared resource, in a shared environment.
> Anytime you abuse a shared resource, i
VDISK is different. Actually, it isn't vdisk is different, it is memory
is different.
CP lets me throttle every other shared resource.
I can SET SHARE to throttle or cap CPU.
I can throttle or cap I/O rates for a particular user.
But once I give a user access to virtual storage (max guest machin
>>> On Sat, Feb 24, 2007 at 12:25 PM, in message
<[EMAIL PROTECTED]>, Tom Duerbusch
<[EMAIL PROTECTED]> wrote:
> VDISK is different. Actually, it isn't vdisk is different, it is memory
> is different.
Actually, it's not. It's a shared resource, and the systems programmer has
complete control o
On Feb 24, 2007, at 11:25 AM, Tom Duerbusch wrote:
VDISK is different. Actually, it isn't vdisk is different, it is
memory
is different.
..no, not really.
But once I give a user access to virtual storage (max guest machine
size plus vdisk(s)), I can't throttle his usage. And in the very
You seemed to make my point...
Once you give access to memory (guest size plus vdisk), the System
Programmer doesn't have any control on the use/abuse of that resource.
If the abuse of memory, by an image, causes the CP paging system to
actively paging things out, it isn't the offending user that
Mark Post wrote:
The Out of Memory Killer is a feature of the kernel virtual storage management
function. It's been around for quite a while, but was improved quite a bit for
the 2.6 kernels. The only thing you have to do to activate it is run out of
virtual storage (i.e., what Linux thin
Tom Duerbusch wrote:
Ok, OOM...yea it has been around.
My experience is once it starts killing processes, it is time to cycle
that image.
The hard part is knowing how much vdisk you need to handle the
exception conditions (like maintenance or compiling or...) but not so
much as that the only ti
The advantage of using VM is that you can overcommit resources.
The disadvantage of using VM is that you can overcommit resources.
The trick is to find a balance between these two, and building enough
resiliency into your configuration to handle the occasional bumps in the
road.
Mark L. Wheeler
>>> On Sat, Feb 24, 2007 at 1:26 PM, in message
<[EMAIL PROTECTED]>, Tom Duerbusch
<[EMAIL PROTECTED]> wrote:
-snip-
> And I started to explain why there is a reason for no having vdisk (or
> minimize its use).
Sorry, but there is _no_ valid reason to avoid using VDISK, if the systems
programme
Tom Duerbusch wrote:
VDISK is different. Actually, it isn't vdisk is different, it is memory
is different.
CP lets me throttle every other shared resource.
I can SET SHARE to throttle or cap CPU.
I can throttle or cap I/O rates for a particular user.
But once I give a user access to virtual st
On Sunday, 02/25/2007 at 08:33 ZE9, John Summerfield
<[EMAIL PROTECTED]> wrote:
> btw The rate of paging is fairly unimportant: in the 80s, we had an
> Amdahl 4360 paging at 600 pages/sec. We looked at the numbers, we looked
> at each other, we shrugged our shoulders: "TSO seems okay."
>
> Responsi
Interesting thread. First, MAXWSS is broken as designed. Don't bother.
Will hurt you way more than help you.
Second, trying to manage a complex environment without tools is like
driving across the desert without your gas gage. You might make it
In a mainframe environment, we do expect sign
On Feb 24, 2007, at 5:33 PM, John Summerfield wrote:
I'm wondering how much virtual storage you're handing out; I recall
that
in my early days on this list, folk were bandying about (almost)
unbelievable (to me) small numbers. 64 Mbytes and less in some
cases, I
think.
Linux, with a virtual O
efense can help win the game. Absent performance
data who knows how long the dance would dragged on for?
Collect and report on that data.
David
-Original Message-
From: Linux on 390 Port on behalf of Alan Altmark
Sent: Sun 2/25/2007 10:33 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Pe
What is the specs of you Linux distribution?
>From my tests:
Suse 7 would boot in 16 MB with VCTCA or IUCV connections (little swap
usage at startup and no active swapping when idle.
Suse 9 needed 42 MB when using OSA. Again, little swap usage at
startup and no active swapping when idle.
Both
No problem.
We agree to disagree on this one.
Tom Duerbusch
THD Consulting
>>> [EMAIL PROTECTED] 2/24/2007 2:24 PM >>>
>>> On Sat, Feb 24, 2007 at 1:26 PM, in message
<[EMAIL PROTECTED]>, Tom Duerbusch
<[EMAIL PROTECTED]> wrote:
-snip-
> And I started to explain why there is a reason for not h
@VM.MARIST.EDU
Subject: Re: Perceptions of zLinux
No problem.
We agree to disagree on this one.
Tom Duerbusch
THD Consulting
>>> [EMAIL PROTECTED] 2/24/2007 2:24 PM >>>
>>> On Sat, Feb 24, 2007 at 1:26 PM, in message
<[EMAIL PROTECTED]>, Tom Duerbusch
<[EMAIL PROTE
02/26/2007 02:04 PM
Subject
Re:
Perceptions of zLinux
P
Of
James Melin
Sent: Monday, February 26, 2007 2:29 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Perceptions of zLinux
Lea, just curious what sizes of vdisk did you use, and how much central
and expanded storage do you have?
"Stahr, Lea" <[EMAIL PROTECTED]>
49 matches
Mail list logo
