Tuning SYSVR3 (Esix Rev D) (LONG!)

[Piercarlo Grandi]

On 28 Nov 90 03:02:29 GMT, karl at ficc.ferranti.com (Karl Lehenbauer) said:

karl> In article <PCG.90Nov21225304 at teachb.cs.aber.ac.uk>
karl> pcg at 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 at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk