From: bill@bill.ab.umd.edu (Bill Bame)
Newsgroups: vmsnet.networks.desktop.pathworks
Subject: Re: Performance Problems with File Services
Keywords: Pathworks
Date: 2 Oct 92 18:31:13 GMT
Reply-To: bill@office.ab.umd.edu
Organization: M.I.E.M.S.S.

>Server:
>Microvax 3100-80
>V6 Mb RAM
>Pathworks Disk RZ25 426 MB
>System Disk RZ24 209 MB
>VMS 5.5-1 (with various patches)
>Pathworks 4.1
> 
>Clients:
>60 386sx PCs (4Mb RAM)
>7 IBM PS/2 Model 70s
>10 486sx PCs (4Mb RAM)
>all remote boot
> 
>1. Remote boot works quite well. Actually this part is fast.

We decided (with pathworks 2.2) that remote booting is a BAD idea.  It works
very nicely, but puts a lot of strain on the server.  We attempted to train
everyone to leave their PCs on all the time, but it just didn't work.  Power
failures were a nightmare - the server would grind to a halt as 50+ PCs tried
to grab the same files at the same time.

>2. Connecting to application disk services and loading those appications are
>also quite fast.

Yeah.

>3. Mounting a file service takes quite a long time (between 5 and 10 minutes)
>when performance gets bad (somewhere after 15 to 20 active users).

5-10 minutes!  I have 30 active users on a 3100-40 (as I am writing this)...
Mounting a file service just took me ~2 secs.

>4. The same performance is observed as in point 3 whenever there is any
>sort of file activity on a file service (dir list, save, retrieve).
> 

Just to give you an idea of performance, I just timed the following...

1) Load WordPerfect (from a file service, not a disk service)
2) Browse through 50-60 WP files
3) Load a file (7.5K)
4) Save it under another name
5) Exit WordPerfect

The whole thing (with typos and hesitations as I tried to remember arcane
WP commands) took about a minute.

>The file service performance is unacceptable. One option would be to drop
>any form of file service and make users rely on diskettes only. However,
>this kind of lobotomization is really something we would not like to do.
>Right now DEC is helping us, they' ve reccomended more memory (32 Mb is
>coming any day) and they've been tweeking the standard system/pcfs parameters
>(ie. page files, caching etc.). Our own system people have been monitoring
>the thing and they feel that the bottleneck is Disk IO. Will extra memory
>solve this?? Has anybody else tried to set up a facility of this size
>with anything less than a CRAY? Our current plan of action is to set up
>another VaxStation and let it handle all the remote booting and the disk
>services. The original machine will have the disk server disabled and
>will be dedicated to providing only file services. The step after that
>if matters don't improve will be to have the two servers dedicated
>to handling 2 smaller groups of clients as opposed to one large group.
>Any help or hints as to what to look further in to would greatly be
>appreciated.
> 

I think your system people are right, your problem is Disk I/O.  I would
place most of the blame of your RZ24 and RZ25 disk drives.  The access times
are OK, but the transfer rates are terrible.  I have a couple of Fujitsu
(520mb, 3.5") in my 3100/40, and it runs very nicely.  Here are a few hints
on speeding up file server performance...

1) Put hard disks in your PCs - use them for "personal" files and possibly
   booting.  Depending on your applications, this could cut way down on
   server I/O.
2) Get some faster disks and try to split the I/O load over as many
   spindles as possible.
3) Get some good software to help you out.  A cacheing product like
   I/O Express should help out - and how about DEC's disk striping driver?
4) Keep a close watch on the PCFS parameters.  Tune them to "peak" usage
   rather than "average" - same goes for SYSGEN parameters.  Depending on
   patterns of usage, experiment with open file cacheing.
5) You can never have too much RAM on a server, but be careful to allocate
   it properly.  It IS possible to make your file server cache too big.
6) Keep an eye on your network.  If your overload it, you will be forced to
   take drastic action (like splitting the network into two bridged segments,
   each with it's own file server).  Certain kinds of network errors can also
   be killers - like network boards that continuously vomit garbage when a
   component get's fried, or having heartbeat turned on somewhere it shouldn't
   be.

If you can afford it, get another server and cluster them together.  Not only
do you get a big boost in performance, you also get a certain measure of
redundancy.

There are lots of other things you can check/play with/worry about too -
hopefully I have given you an idea or two that will help.
> 
>--
>Mike Babin
>Computing Services       Concordia University      Montreal, Quebec, Canada
>mikeb@maxwell.concordia.ca     Tel:  (514) 848-7646     FAX:  (514) 848-7622
>

--
--------------------------------------------------------------------------------
William P. Bame                    | sneakernet: William P. Bame
internet: bill@bill.ab.umd.edu     |             M.I.E.M.S.S.
          bbame@achi1.ab.umd.edu   |             22 South Greene Street
AT&T    : [Work] (410) 328-3062    |             Baltimore, MD 21201
CIS     : 71620,425                |             Room: T1R55
--------------------------------------------------------------------------------

Newsgroups: vmsnet.networks.desktop.pathworks