Xref: utzoo comp.unix.sysv386:2694 comp.unix.questions:27358 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.sysv386,comp.unix.questions Subject: Re: Tuning SYSVR3 (Esix Rev D) (LONG!) Message-ID: Date: 3 Dec 90 16:23:02 GMT References: <1990Nov20.194829.6977@unixland.uucp> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 57 Nntp-Posting-Host: odin In-reply-to: karl@ficc.ferranti.com's message of 28 Nov 90 03:02:29 GMT On 28 Nov 90 03:02:29 GMT, karl@ficc.ferranti.com (Karl Lehenbauer) said: karl> In article 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.uk