Newsgroups: comp.sys.encore
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!melissa
From: melissa@cunixf.cc.columbia.edu (Melissa Metz)
Subject: dump really slow
Message-ID: <1991Apr2.185610.29598@cunixf.cc.columbia.edu>
Keywords: dump
Sender: melissa@cunixf.cc.columbia.edu (Melissa Metz)
Reply-To: melissa@cunixf.cc.columbia.edu
Organization: Columbia University
Date: Tue, 2 Apr 1991 18:56:10 GMT

My question: why does dump run so slow and use so many CPU seconds?

We have an Encore 510 with 4 processors and 12 disks (25 filesystems).
The disks are all attached to an MSC rather than simply on the EMC
board.  We run weekly full backups four nights a week, meaning about 3
full disks backed up per night (minus some "read-only" partitions)
plus incrementals on everything else.  We have two 9-track tape drives
on a Sun-4/280 that we access remotely (running two dump sets at a
time -- with the default of 22 processes each).

Lately, we've been having a lot of trouble finishing the backups
overnight.  (We used to have three tape drives available.)  Since the
two backups running simultaneously bring the load up to as much as 20
(and the system to a crawl), we need to avoid running the backups
while our users are logged in.

A couple of months ago, the dumps would run really slow, and then
hang, with "netstat -m" reporting more than 20,000 mbufs in use --
apparently we were running out. ("Normal" seems to be 2000/4000.)  To
make this go away, we rebooted and started running the backups
serially -- only one filesystem dumped at a time.  Unfortunately, this
meant the backups weren't finished until 11am, severely impinging on
the performance our users saw.

After a few weeks like this, we returned to running the backups in
parallel (two at a time), and have not seen a recurrence of the mbufs
problem.  However, the backups are still slow, lasting from a 1am
start till 9 or 10am.

To get some hard numbers, I did some benchmarking last week.  I used
our Encore 310 (4 processors, 2 disks on the EMC board) for comparison
purposes.

Command: rdump 0bdfs 50 54000 sun:/dev/nrst1 6000 /dev/mdxx

CPU type    real time   CPU time     size     real speed   CPU speed
  510x4      2:34:53     8007.1     477,923      51           60
  310x4      1:06:26     1256.8     372,055      93          296

(where "speed" is size/time (real or CPU) -- kilobytes per second, I guess)

Now I'd like to know why my wimpy 310 can write dumps 2-5 times as
"fast" as the "more powerful" 510.  Note that the 510 had 25 users on
it and a load of 5 (which went up to 10 with the dumps running), while
the 310 had 2 users and a load of 0.5, which increased only to about
1.  However, this shouldn't have such an incredible effect on the CPU
usage of the processes...  And why was the load impact greater on the
510? 

Anyone out there have any ideas?  Am I missing something obvious (that
would be a relief...)?

Please reply by mail to me, and I will summarize if it seems
appropriate. 

					Melissa Metz
					Unix Systems Group

Internet: melissa@columbia.edu		BITNET: melissa@cunixc
UUCP: ...!rutgers!columbia!melissa