bill@unixland.uucp (Bill Heiser) (11/21/90)
My Esix system is used for some program development (mostly programs
for school), some running VP/ix to run a few DOS apps, USENET News,
and BBS software. The SAR report I have enclosed is fairly typical
of an average day. I'm concerned about the high figures in the
%wio and %sys columns. Is this typical for this kind of system?
The biggest user right now is usenet news, processing between 7 and 12MB
of news per day.
[system description: 80386/25 no cache, 8mb 70ns DRAMS, 300MB SCSI
drive (CDC Wren IV), drive caching turned ON, Adaptec 1542b host adapter,
ATI VGA Wonder, NEC Multisync II)].
If this is atypical, I'm interested in hearing suggestions on which
kernel parameters I might change to improve system performance. For
example, should I increase the amount of buffer cache? If I need
to do things like that, and need more RAM, I can beef it up to 16MB.
Under most circumstances, the system has a couple of megs free, although
of course it drops right down when I run Xwindows.
Thanks in advance for advice on this topic.
(would a "sar -a" be more useful than just this report?)
unixland unixland 3.2 2 i386 11/20/90
00:00:00 %usr %sys %wio %idle
00:20:00 0 0 1 99
00:40:02 0 0 1 99
01:00:03 3 5 2 91
01:20:05 3 39 58 0
01:40:07 6 15 79 0
02:00:01 8 11 38 42
02:20:04 5 35 28 33
02:40:03 1 1 11 86
03:00:00 0 0 1 99
03:20:00 0 0 1 99
03:40:02 0 0 1 99
04:00:00 0 0 1 99
04:20:00 0 0 1 99
04:40:02 0 0 1 99
05:00:01 0 0 1 98
05:20:00 0 0 1 99
05:40:02 2 30 1 68
06:00:00 4 10 35 50
06:20:00 0 0 1 99
06:40:02 0 0 1 99
07:00:01 1 7 1 91
07:20:00 3 14 22 61
07:40:02 0 0 1 98
08:00:02 1 6 5 88
08:20:00 2 2 8 87
08:40:03 2 4 8 86
09:00:00 1 2 4 93
09:20:00 0 0 1 99
09:40:03 1 1 2 96
10:00:00 1 3 3 93
10:20:00 0 0 3 96
10:40:02 0 0 1 98
11:00:00 0 0 1 99
11:20:00 1 1 2 96
11:40:02 1 3 2 94
12:00:00 2 3 4 91
12:20:00 2 1 1 96
12:40:02 4 3 4 90
13:00:01 1 7 3 89
13:20:05 7 34 29 30
13:40:02 2 2 5 90
14:00:01 3 9 3 84
14:20:06 6 19 26 48
14:40:02 2 3 6 89
Average 2 6 9 83
--
home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill
bill@unixland.uucp, bill%unixland.uucp@world.std.com
Public Access Unix - Esix SYSVR3 - (508) 655-3848
other: heiser@world.std.com Public Access Unix (617) 739-9753pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/22/90)
On 20 Nov 90 19:48:29 GMT, bill@unixland.uucp (Bill Heiser) said: bill> My Esix system is used for some program development (mostly bill> programs for school), some running VP/ix to run a few DOS apps, bill> USENET News, and BBS software. The SAR report I have enclosed is bill> fairly typical of an average day. I'm concerned about the high bill> figures in the %wio and %sys columns. Is this typical for this bill> kind of system? The biggest user right now is usenet news, bill> processing between 7 and 12MB of news per day. bill> [system description: 80386/25 no cache, 8mb 70ns DRAMS, 300MB SCSI bill> drive (CDC Wren IV), drive caching turned ON, Adaptec 1542b host adapter, bill> ATI VGA Wonder, NEC Multisync II)]. You are concerned abou disk wait. Well, it is the normal Unix problem, or that of any computer used for time sharing. It is not that abnormal. Do raise the buffer cache; 2MB will be nice, more than 4MB is probably wasted. I would go for 2MB initially. Should give some dramatic improvement. Rule of thumb: devote about 25% of RAM to the buffer cache. Do buy a second disk, and put on the first root+usr+/tmp, on the second put swap+spool+users. Another disk usually gives a very big reduction in disk latency, and especially so with a controller like the AHA1542 that can overlap seeks, transfers, and is a bus master. As a first drive (you wnat in your case the larger drive as the second one) a Quantum ProDrive (the 80MB model would fit your needs very well I think) would do nice, I am told. Both measures above will do wonders for your news processing. A lot of cache will help, and so will having spool and /tmp on different arms. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
tneff@bfmny0.BFM.COM (Tom Neff) (11/26/90)
Also keep in mind that VP/ix consumes ALL your %cpu when it's running. It's niced down so that it doesn't step on anything else -- other processes run fine -- but by sar's standards you're loaded solid.
karl@ficc.ferranti.com (Karl Lehenbauer) (11/28/90)
In article <PCG.90Nov21225304@teachb.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >Do raise the buffer cache; 2MB will be nice, more than 4MB is probably >wasted. I would go for 2MB initially. Should give some dramatic >improvement. Rule of thumb: devote about 25% of RAM to the buffer cache. One annoying thing I've found about having 2 MB of cache is that the system will periodically get incredibly sluggish for a few seconds. This happens right after big compiles and links. I assume it is because "sync" is flushing all the dirty buffers. Anyone have any idea how to reduce these sluggish periods without reducing the cache size and without reducing the reliability of the file system with respect to power outages or the performance? -- -- uunet!sugar!ficc!karl (wk), "Any excuse will serve a tyrant." -- Aesop uunet!sugar!karl (hm)
aglew@crhc.uiuc.edu (Andy Glew) (11/29/90)
One annoying thing I've found about having 2 MB of cache is that the
system will periodically get incredibly sluggish for a few seconds.
This happens right after big compiles and links. I assume it is because
"sync" is flushing all the dirty buffers.
Anyone have any idea how to reduce these sluggish periods without reducing
the cache size and without reducing the reliability of the file system
with respect to power outages or the performance?
Paradoxically, you can increase the synch scan rate, so that synch is
performed more often. If you are mainly a read-only environment this
will result in less "jerkiness".
Or, you can go the other way, and scan less often.
I think that the parameter is called BDFLUSHR.
Btw, I have *measured* these effects... you might be able to lay your
hands on a tuning guide I wrote for a past employer.
Motorola MCD improved on the buffer cache scanning algorithm by
segmenting it, so that it scanned little chunks more frequently. This
produced a dramatically less jerky interactive response. Once again,
measured.
--
Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]pb@idca.tds.PHILIPS.nl (P. Brouwer) (11/29/90)
In article <N7970K8@xds30.ferranti.com> karl@ficc.ferranti.com (Karl Lehenbauer) writes: > >One annoying thing I've found about having 2 MB of cache is that the >system will periodically get incredibly sluggish for a few seconds. > >This happens right after big compiles and links. I assume it is because >"sync" is flushing all the dirty buffers. > The parameter BDFLUSHR specifies the time in seconds the interval between the check of the bdflush process ( part of the kernel ). If the interval is long , bdflush has probably more work to do. On the other hand bdflush has to check the complete cache for dirty buffers so if that has to be done in less activations per minute that will save some cpu time. You seem to suffer from the bdflush having to write a lot to disk. The default setting ( and max according to mtune ) for AT&T SYSV is 1. This constant is kept in a global kernel variable, which makes it possible to modify its value in a running kernel by writing the new value via kmem to the correct address. -- ________________________________________________________________________________ # Peter Brouwer, | Philips Information Systems, # # NET : pb@idca.tds.philips.nl | Department P9000-i Building V2, # # UUCP : ....!mcsun!philapd!pb | P.O.Box 245,7300AE Apeldoorn,The Netherlands#
cpcahil@virtech.uucp (Conor P. Cahill) (12/02/90)
In article <N7970K8@xds30.ferranti.com> karl@ficc.ferranti.com (Karl Lehenbauer) writes: >Anyone have any idea how to reduce these sluggish periods without reducing >the cache size and without reducing the reliability of the file system >with respect to power outages or the performance? You can't. The problem is that the "dirty" blocks sit in the queue for a specified amount of time (unless the block is needed for other uses) before they are forced out by the kernel. The amount of time is controlled by a kernel configuration parameter (NAUTOUP, I think). The problem is that if you increase this variable, you decrease reliability. Even if you set this variable to some high value, it is still possible that at that new time period following a large disk update, the system will slow down momentarily due to many dirty pages that still need to be written out, so you may be in a no-win situation. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/04/90)
On 28 Nov 90 03:02:29 GMT, karl@ficc.ferranti.com (Karl Lehenbauer) said:
karl> In article <PCG.90Nov21225304@teachb.cs.aber.ac.uk>
karl> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
pcg> Do raise the buffer cache; 2MB will be nice, more than 4MB is probably
pcg> wasted. I would go for 2MB initially. Should give some dramatic
pcg> improvement. Rule of thumb: devote about 25% of RAM to the buffer cache.
Also, remember to increase the size of the inode caches (there are at
least two) when you raise the size of the buffer cache; inode caching
can dramatically reduce inode detches, and this is doubly good,
especially with SysV style filesystems, which have regrettably the ilist
tucked away at one end of the partition.
Rule of thumb: have an inode entry every buffer cache block. Or even
more. You want to cache inodes even if none of their blocks is cached.
karl> One annoying thing I've found about having 2 MB of cache is that
karl> the system will periodically get incredibly sluggish for a few
karl> seconds. This happens right after big compiles and links. I
karl> assume it is because "sync" is flushing all the dirty buffers.
Yes and no. There is a new kernel process under SVR3 that does the job
that the periodic sync(2) call from /etc/update used to do under V7 and
derivatives. This is bdflush. The main reason for which the system is
sluggish is that the disk arm scheduler is a bit rigid in its scheduling
policy; this is especially noticeable if you have a single non
multithreaded disk controller. Having two non multithreaded controllers
(MFM, RLL, IDE, ESDI) helps a lot, as having a multithreaded bus
mastering one (Adaptec 1542). When the disc controller is not
multithreaded bursts of disc IO are essentially serialized...
karl> Anyone have any idea how to reduce these sluggish periods without
karl> reducing the cache size and without reducing the reliability of
karl> the file system with respect to power outages or the performance?
There are parameters, like the bdflush scan rate, in [ms]tune, that you
can tweak to make bdflush run more or less frequently. I think that
making it run more frequently will not harm you a lot, and will tend to
make for more frequent smaller bouts of saving;
Bdflush should not be more frequently than every few seconds (I make it
run every thirty, which is quite long). The reason for this is so that
/tmp files, that get created and then deleted rapidly, as during
compilations, can then mostly escape being saved to disk only to be
immediately deleted.
For small compiles, where you have sticky'ed compiler executables
(/bin/cc, /lib/cpp, /lib/ccomp, /lib/optim, /bin/as, /bin/ld) should
result in no disk traffic at all, except to read the .c and write back
the .o files (and indeed one should not even see disk accesses for the
.c file, if one has just finished editing it).
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukjohn@jwt.UUCP (John Temples) (12/04/90)
In article <1990Dec02.001311.16727@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >Even if you set this variable to some high value, it is still possible >that at that new time period following a large disk update, the system >will slow down momentarily due to many dirty pages that still need to >be written out, so you may be in a no-win situation. Is a cached hard disk controller a win in this situation? If you flush a bunch of stuff to disk (but not so much as to overflow the controller's cache), does the system's response still feel "snappy"? What happens when you give the controller a read request while it's flushing its cache to the disk -- does the read take priority? Or must you wait till the controller finishes? The only gripe I have about 386 UNIX is that when you have two or more processes contending for the disk, the system comes to a near halt. Will a cached controller help or eliminate this problem? -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
pb@idca.tds.PHILIPS.nl (P. Brouwer) (12/04/90)
In <1990Dec4.031037.2718@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >Is a cached hard disk controller a win in this situation? If you >flush a bunch of stuff to disk (but not so much as to overflow the >controller's cache), does the system's response still feel "snappy"? My guess is that a cache on a disk controller will probably a write through cache . So this will not change the behaviour if the system during a unix cache flush. -- # Peter Brouwer, | Philips Information Systems, # # NET : pb@idca.tds.philips.nl | Department P9000-i Building V2, # # UUCP : ....!mcsun!philapd!pb | P.O.Box 245,7300AE Apeldoorn,The Netherlands# # PHONE:ext [+31] [0]55 432992, | FAX :ext [+31] [0]55 433488 #
bill@bilver.uucp (Bill Vermillion) (12/05/90)
In article <1990Dec4.031037.2718@jwt.UUCP-> john@jwt.UUCP (John Temples) writes: ->In article <1990Dec02.001311.16727@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: ->>Even if you set this variable to some high value, it is still possible ->>that at that new time period following a large disk update, the system ->>will slow down momentarily due to many dirty pages that still need to ->>be written out, so you may be in a no-win situation. ->Is a cached hard disk controller a win in this situation? If you ->flush a bunch of stuff to disk (but not so much as to overflow the ->controller's cache), does the system's response still feel "snappy"? ->What happens when you give the controller a read request while it's ->flushing its cache to the disk -- does the read take priority? Or ->must you wait till the controller finishes? The only gripe I have ->about 386 UNIX is that when you have two or more processes contending ->for the disk, the system comes to a near halt. Will a cached ->controller help or eliminate this problem? I can't tell you what takes priority in a caching controller, but I will tell you this, it more than makes a system feel snappy. "Sudden" is perhaps a more apt description. That applies systems with the only cache controller I am familiar with, the DPT units from Distributed Processing Technology. They aren't cheap but they are fast. I have a client with a 20MHz '386 with the DPT with 4 Megs of ram, a 330 meg esdi drive (10Mb/sec) and it definately feels a lot fast than my system with no cache, a 25MHz '368 with a 15 Mb/sec esdi. One of the first instances of "sudden" was when I was setting it up and I exited a WP program. I thought I accidentally hit break. Reads through a data base are very fast. I haven't done any timings on the actually speeds, but it's fast enough that I really WANT one myself. -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
james@bigtex.cactus.org (James Van Artsdalen) (12/06/90)
In <1990Dec4.162751.12224@bilver.uucp>, bill@bilver.UUCP (Bill Vermillion) wrote: > I can't tell you what takes priority in a caching controller, but I will > tell you this, it more than makes a system feel snappy. One effect is that writes are no longer synchronous. AT&T's concept of file system hardening is to do the writes in a certain order, waiting for each to finish. A caching controller with a write-back cache makes something like "rm *" much faster since no actual I/O happens until later. You do sacrifice some filesystem recoverability though. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
floydf@iphase.UUCP (Floyd Ferguson ENG) (12/07/90)
>->In article <1990Dec02.001311.16727@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >->>Even if you set this variable to some high value, it is still possible >->>that at that new time period following a large disk update, the system >->>will slow down momentarily due to many dirty pages that still need to >->>be written out, so you may be in a no-win situation. > There was some considerable discussion about this maybe two years ago with regards to the Motorola UNIX product. Their version used a linear search to scan for dirty buffers, which worked well until the total buffer cache exceeded 2 MB, then things would periodically get very slow. I don't know if this was pre- or post- bdflush. The other factor that can really slow things down is a controller (or driver) that does not group writes. For instance, the 3.2.0 SCO driver for the HP Vectra ESDI controller will read about 700 KB/sec, but will only write at 70 KB. Needless to say, writing a lot of dirty buffers out will take a while. In article <1990Dec4.162751.12224@bilver.uucp> bill@bilver.UUCP (Bill Vermillion) writes: >I can't tell you what takes priority in a caching controller, but I will >tell you this, it more than makes a system feel snappy. > ....... >that I really WANT one myself. > I would wait until we find out how they work on the new systems (V.4) that are no longer burdened with the problem of statically defined buffer cache allocation. Cache memory is cache memory, regardless of which side of the host bus it resides. The only difference is the algorithm used to access it. Floyd Ferguson uunet!iphase!floydf
cpcahil@virtech.uucp (Conor P. Cahill) (12/07/90)
In article <1990Dec4.031037.2718@jwt.UUCP> john@jwt.UUCP (John Temples) writes: > >Is a cached hard disk controller a win in this situation? If you >flush a bunch of stuff to disk (but not so much as to overflow the >controller's cache), does the system's response still feel "snappy"? It depends upon the controller. Some caching controllers have a write through cache, so the updates actually go to the disk at the time the os says so. On these controllers you would see the same slow downs when the buffers were flushed. Other controllers (like the DPT Caching controller that we have here) cache both reads and writes. Performance is always snappy unless you try to read or write very large (i.e. greater than the cache size) number of blocks. The drawback to this is that if you suffer a power hit, the ordered writes that the kernel thought were complete, may not have been completed and the writes that were complete may not have been done in the right order. Of course, if you can afford to get the caching controller you should be able to afford a UPS to protect you from this. >What happens when you give the controller a read request while it's >flushing its cache to the disk -- does the read take priority? Or Again, this depends upon the controller, but with the DPT the non-flush activity has priority as long as there are enough non-dirty blocks in the cache to satisify it. >about 386 UNIX is that when you have two or more processes contending >for the disk, the system comes to a near halt. Will a cached >controller help or eliminate this problem? This depends upon the problem that you are seeing. For example, if you have two programs that are essentially reading the entire disk at the same time, there is almost nothing that you can do. If, however you are talking about two compiles of rather large programs, the cached controller should help alot. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
aglew@crhc.uiuc.edu (Andy Glew) (12/10/90)
>>->>Even if you set this variable to some high value, it is still possible >>->>that at that new time period following a large disk update, the system >>->>will slow down momentarily due to many dirty pages that still need to >>->>be written out, so you may be in a no-win situation. >> >There was some considerable discussion about this maybe two years ago >with regards to the Motorola UNIX product. Their version used a linear >search to scan for dirty buffers, which worked well until the total >buffer cache exceeded 2 MB, then things would periodically get very >slow. I don't know if this was pre- or post- bdflush. Urghh. This was fixed while I was at Motorola MCD (not by me, but by a guy working with me -- I'd give him credit, but announcing his name on the net would probably lead to calls from the field that are better handled by customer service -- hi, anyway, Eric!) Motorola UNIX now has a segmented buffer cache scanning algorithm - you define the time period that the whole buffer is to be scanned in, and the maximum number of buffers to be scanned in any step. The effect on the variance of interactive response time was dramatic. I measured it. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
lws@comm.wang.com (Lyle Seaman) (12/12/90)
cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <N7970K8@xds30.ferranti.com> karl@ficc.ferranti.com (Karl Lehenbauer) writes: >>Anyone have any idea how to reduce these sluggish periods without reducing >>the cache size and without reducing the reliability of the file system >>with respect to power outages or the performance? [ ... re MAXTOUP ... ] >Even if you set this variable to some high value, it is still possible >that at that new time period following a large disk update, the system >will slow down momentarily due to many dirty pages that still need to >be written out, so you may be in a no-win situation. On the other hand, the longer you keep them around, the greater the likelihood that they will be changed again. You've just saved a flush. Rule #1 of performance optimization: "Don't do it." Rule #2 of performance optimization: "Do it later." ( "it" doesn't mean performance optimization...) -- Lyle Wang lws@comm.wang.com 508 967 2322 Lowell, MA, USA uunet!comm.wang.com!lws The scum always rises to the top.