Many thanks to the folks who responded;
Anthony A.D.Talltree
John P.Speno
Jim Belonis
Sean Harding
alan_at_nabeth.cxo.dec.com
My original question is immediately below, with the various reponses below
that.
In SUMMARY: Yes, usually, with some caveats such as the disk function,
location of the swap on the disk and the number of buses(sp?).
__________
>When partitioning a system with multiple disks is there any advantage
>for efficiency, or otherwise, to set up a separate swap space on each
>disk?
>If so, are there any general guidelines for more efficient operation
>with AdvFs?
----------
Anthony A.D.Talltree:
There are those who advocate putting swap space on every disk, but my
take on this question is that it depends on how one uses swap space, and
on how busy the other disks are. IIRC, DEC is like most vendors, and
uses all swap partitions equally. HP-UX has the neat feature of
assigning priorities to swap partitions, so that less desirable ones can
only be used if the need is dire.
So, if you configure swap on one end of a disk that also holds a very
busy user data filesystem, and the system is paging moderately to
heavily, you'll slow down the user data filesystem by diverting the head
from the user data part of the disk. So, I would advise configuring
secondary swap on disks that aren't the most heavily used.
-----
John P. Speno:
Yes, the swapper will use each swap space in a round-robin fashion. I
think all of your swap spaces should be about the same size for this
reason (though my own vary from system to system)
_____
Jim Belonis:
Yes. most operating systems evenly use multiple swap files so there is
a speed increase proportional to the number of swap disks.
(but speed problems if multiple swap spaces scattered on the same disk).
But you should beware of putting swap space on otherwise active disks
since your swap and normal file accesses will compete, slowing both.
On the other hand, if you are actually doing enough swapping to slow
things down, you probably don't have enough RAM.
_____
Sean Harding:
Most OSes (Tru64 included) will interleave swap between multiple swap
areas. So, you can get improved performance by spreading it across
multiple disks. If possible, spread the swap areas across controllers too.
_____
alan_at_nabeth.cxo.dec.com:
Page/swap space tends to be lightly used when the system
isn't paging. When that's the case, the physical organization
doesn't matter as much. As the page/swap space is more
heavily accessed, organization is important. Spreading
the space out over multiple device will at least allow
multiple I/O requests to the device to be overlapped,
even if only to have multiple devices seeking independently.
Since most I/O busses only allow a single tranfer at a time,
putting all the devices on a single bus, may limit the
performance. If the paging system can have multiple
I/Os in progress, then spreading the I/O out over multiple
adapters allows more I/O capacity.
But, you'll rarely be able to improve paging performance
more from I/O tuning than from getting more memory, when
that is an option...
Another things that can severely affect I/O performance
is seeking. The I/O performance of a disk becomes limited
when the data it needs is (relatively) far away from where
the head is at the moment. Having multiple requests to
the disks allows it to oppurtunistically transfer data
on the way from one point to another, but having to
stop and settle increases the average seek time even
more.
This isn't particular AdvFS, though AdvFS may suffer more
than UFS. The AdvFS journal is probably a write-intensive
part of the file system, since changes have to be committed
there. If the log uses enough cache, reading back may not
take much I/O. However, if the log for a particular domain
is on a busy disk, then certain I/O loads that use the log
heavily will be affected. When congestion becomes a problem
with the log it may be wise to move it to a different device
which has better I/O characteristics; a solid state disk,
a less busy disk, a RAID-1 or RAID-0+1 devices, etc. I
suppose one could even pick a device that was just big
enough for the log to minimize the data allocated to it.
_____
Received on Wed Mar 22 2000 - 00:05:44 NZST