Xref: utzoo comp.unix.sysv386:2867 comp.unix.questions:27476 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: 10 Dec 90 05:32:14 GMT References: <1990Dec02.001311.16727@virtech.uucp> <1990Dec4.031037.2718@jwt.UUCP> <1990Dec4.162751.12224@bilver.uucp> <319@iphase.UUCP> Sender: news@ux1.cso.uiuc.edu (News) Organization: Center for Reliable and High-Performance Computing University of Illinois at Urbana Champaign Lines: 25 In-Reply-To: floydf@iphase.UUCP's message of 6 Dec 90 22:03:33 GMT >>->>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]