some things in this thread.
1) as Rob pointed out, you are slowing down your linux
server on purpose. A swap device to disk maybe can do 200 swaps
per second, so ok, add 3, and you can do 600.
With vdisk, it could be 40,000 per second - so linux doesn't
notice it is swapping.
2) you do not have t
Rob van der Heij commented:
> On 8/30/06, John Campbell <[EMAIL PROTECTED]> wrote:
>
> > The hell of it is that I *don't* have a zSeries-- or even an
> > instance within z/VM-- where I can run Linux, so I can only do
> > some speculation.
>
> Yes, and that is where it makes a difference. On discret
On 8/30/06, John Campbell <[EMAIL PROTECTED]> wrote:
The hell of it is that I *don't* have a zSeries-- or even an
instance within z/VM-- where I can run Linux, so I can only do
some speculation.
Yes, and that is where it makes a difference. On discrete servers it
may make sense to tune your co
Ken Hall said:
> I tracked down a copy of the actual report from the performance guy,
> and it turns out we've been (partially) barking up the wrong tree.
> Sorry for the confusion.
>
> The real story is that the large swap partition DEVICE was 100% BUSY
> during part of the test. The original sum
006 11:37 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: [LINUX-390] Swap partition "filling up" on RHEL4 - NOT
>
>
> If you're running under VM, make the swap devices a virtual
> disk. They
> can handle a significantly higher load than the real disk.
>
On 8/30/06, Rich Smrcina <[EMAIL PROTECTED]> wrote:
If you're running under VM, make the swap devices a virtual disk. They
can handle a significantly higher load than the real disk.
Sure. And that's where the different priorities make sense to avoid
infinite growth of the footprint of that VD
If you're running under VM, make the swap devices a virtual disk. They
can handle a significantly higher load than the real disk.
Hall, Ken (GTI) wrote:
I tracked down a copy of the actual report from the performance guy, and it
turns out we've been (partially) barking up the wrong tree. Sorr
I tracked down a copy of the actual report from the performance guy, and it
turns out we've been (partially) barking up the wrong tree. Sorry for the
confusion.
The real story is that the large swap partition DEVICE was 100% BUSY during
part of the test. The original summary report said 100
