Xref: utzoo comp.unix.sysv386:2501 comp.unix.questions:27183 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@crhc.uiuc.edu (Andy Glew) Newsgroups: comp.unix.sysv386,comp.unix.questions Subject: Re: Tuning SYSVR3 (Esix Rev D) (LONG!) Message-ID: Date: 28 Nov 90 17:03:32 GMT References: <1990Nov20.194829.6977@unixland.uucp> Sender: news@ux1.cso.uiuc.edu (News) Organization: Center for Reliable and High-Performance Computing University of Illinois at Urbana Champaign Lines: 28 In-Reply-To: karl@ficc.ferranti.com's message of 28 Nov 90 03:02:29 GMT 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]