I've just realised that I prepared this summary well over a week ago
but forgot to send it to the list. Sorry for the delay:
I wrote:
>I want to add another SCSI bus to our heavily overloaded 2100. It's
>currently fully stocked with (narrow) disks in the main cabinet and
>three more shelves or disks in an HSZ40 connected to the 2100 via a
>Fast/Wide KSPSA. It looks to me as though the mail disk (sitting on
>a wide shelf in the HSZ40) and the spool disk (a narrow disk driven
>by the internal SCSI adapter in the main cabinet) are bottlenecks.
>
>I want to get two new (wide 10K RPM) disks and put them in an external
>box connected to a new SCSI adapter. Now for the question part. Since
>the 2100 is now obsolete, the "supported hardware" list hasn't been
>kept up to date and the latest SCSI adapter that it supports appears
>to be the KZPSA, Fast/Wide/Differential (we already have one
>connected to the HSZ40). What I'd like to know is whether the KZPDA-AA
>(Fast/Wide/Single-Ended) or KZPBA-CA (Ultra/Wide/Single-Ended) SCSI
>adapters will work properly in the 2100?
I received a reply from Alan Rollow saying he was pretty sure the
KZPDA is supported in the 2100 and that a KZPBA wasn't recognised in
his 2100 despite the version of Digital UNIX supporting it. The lack
of support appeared to be at the firmware level. Mike Herrera replied
saying he believes the KZPBA should work with firmware 5.3 or higher.
Wendy Fong replied saying she has used a KZPBA-CA in a 2100A.
> (In fact, what I'd *really*
>like to do is simply put in a Mylex/BusLogic BT958 Ultra/Wide adapter
>but I guess DUX doesn't have a driver for it.) If there are any other
>possibilities (e.g. widely available Fast/Wide or Ultra/Wide SCSI
>adapters that DUX *does* have a driver for) then I'd like to hear of
>those too.
No replies mentioned any attempts with non-DEC SCSI adapters, so I
guess I'm stuck with paying through the nose for a DEC one. Probably a
KZPDA for safety,
>While I'm asking questions: does anyone know if there's any way of
>querying disk subsystem statistics in more details than plain iostat?
>iostat doesn't even give transfers-per-second figures (for our RZ28
>and RZ29 disks in the HSZ40, on SWXCR controllers or on the internal
>bus) let alone things like tagged queue depths, break-down of disk
>reads/writes by size and such like.
A few people replied thinking that I hadn't realised that iostat could
be persuaded to show more than the standard disks. Sorry for the
ambiguous phrasing: I did realise this and have already hacked
together a little perl script to take the output of iostat for all 27
disks but it still only shows bps figures (the tps columns were all 0
so I stripped them out). Here's the script in case anyone finds it
useful (after tweaking the names and numbers, of course):
------------------------------ cut here ------------------------------
#!/usr/local/bin/perl
use strict;
$| = 1;
my $interval = shift || 1;
my _at_disks = ("re0" .. "re7",
"rz0" .. "rz3",
<z{a,b,c,d}16>,
<z{a,b,c,d}17>,
<z{a,b,c,d,e,f,g}18>);
my _at_disk_specs = ("re0" .. "re7", "rz0" .. "rz3", "rz16", "rz17", "rz18");
my $fmt = ("%4d " x _at_disks) . "\n";
my $head_fmt = ("%4.4s " x _at_disks) . "\n";
my _at_ixes = map(2 * $_, 0..$#disks);
open(IOSTAT, "iostat _at_disk_specs $interval|") or die "iostat: $!\n";
while (<IOSTAT>) {
substr($_, 0, 10) = ''; # remove tin/tout columns which can run together
s/^\s*//;
if (/^\d/) {
my _at_f = split;
printf $fmt, _at_f[_at_ixes];
} else {
printf $head_fmt, _at_disks if /^bps/;
}
}
------------------------------ cut here ------------------------------
There were also some good ideas for getting more detailed statistics.
An ex-colleague rang up to point me at the TBL_DKINFO subfunction of
table(2), although experimentation shows that many fields are zero.
Alan Rollow writes:
>Monitor can tell the difference and I have patches
>that fix the previous version's inability to collect queue depth.
>The basic system interface for getting disk performance data doesn't
>split reads and writes. The SCSI driver might, but you have to go
>wandering around in kernel data structures directly to get that
>information.
Mike Herrera replied with a pointer to
ftp://raven.alaska.edu/pub/sois/UA_DUtools.tar.Z
and says about one of the tools therein:
>'uaio' provides a wealth of I/O information. Also, there are a few other
>tools you get with the toolset but we only use 'uaio'
Paul Thompson replied saying that the HSZ40 itself has a utility to
show transfer statistics:
HSZ> RUN VTDPY
Unfortunately the man page for hszterm says it never allows running of
VTDPY via that means so I'd be stuck with running it on the serial
console of the HSZ40 which would make data munging impossible.
Gary Menna replied recommending "collect" (current version
collect111.tar.gz) which you can leave running the whole day and
it generates stats on CPU, disks, net, lsm, procs, etc. and presents
them with a GUI and does graphs.
Many thanks for all the replies. Full attributions are as follows:
Alan Rollow <alan_at_nabeth.cxo.dec.com>
Mike Herrera <Mike.Herrera_at_mitchell.com>
Paul Thompson <paul.thompson_at_unitedhealth.org>
Wendy Fong <wfong_at_synacom.com>
Gary Menna <G.Menna_at_isu.usyd.edu.au>
--Malcolm
--
Malcolm Beattie <mbeattie_at_sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services
Received on Tue Jun 01 1999 - 11:43:17 NZST