Re: Keeping clean pages in shared memory

In article <3j5crk$566@infmx.informix.com>, davek@informix.com (David Kosenko) writes: |>Path: informix.com!davek |>From: davek@informix.com (David Kosenko) |>Newsgroups: comp.databases.informix |>Subject: Re: Keeping clean pages in shared memory |>Date: 2 Mar 1995 21:20:52 GMT |>Organization: Informix Software, Inc. |>Lines: 41 |>Distribution: world |>Message-ID: <3j5crk$566@infmx.informix.com> |>References: <D4qoDo.1s0@cix.compulink.co.uk> <D4rB7s.CCv@cix.compulink.co.uk> <3j51am$shs@infmx.informix.com> |>Reply-To: davek@informix.com (David Kosenko) |>NNTP-Posting-Host: somerset.informix.com |> I am aware of the fact that flushed pages are not removed from the cache but what I was trying to say that the effectiveness of the cache is lost for writes (flushes) while it still works for page reads (lookups). This is because the number of IOs have been increased significantly because of frequent flushes of the working set of pages. Generally a low MAX_DIRTY value is good for OLTP appliations & an high MAX_DIRTY value is good for batch/DSS (with some update) type of applications. I don't think one can suggest a value like 10% for all types of applications, then why have a configurable parameter LRU_MAX_DIRTY. I agree with your logic for OLTP type of environment. Also, one must look at the number of LRU queues to see if one can benefit from increasing the number of LRU queues and the number of page cleaners. As it is on most databases servers, the system is IO bound as opposed to CPU bound and hence it is imperative that we *minimize* and *spread* IO to get maximum performance of a system. Finally, I don't think Informix uses sorted writes for LRU page writes even in 7.1 as the cost of sorting randomly updated pages may be worth it. Anyway I will check on it sometime soon. Regarding the term synch. writes during checkpts, all I was trying to say that the cache is flushed synchronously i.e. all activities are stopped till all modified pages are flushed to the disk. -raj /* * standard disclaimers. */ |>This rides on the FALSE assumption that "flushing" a page removes it from |>the buffer cache. In fact, it simply updates the page on disk to reflect |>the state of the page in memory. LRU cleaning has no discernable effect |>on cacheing. Rather, the point is to reduce checkpoint duration, which is |>directly related to the number of dirty pages in the cache. The more pages |>that are dirty, the longer the checkpoint will take. By setting LRU_MAX_DIRTY, |>you are essentially defining the maximum number of pages that would ever have |>to be written during a checkpoint. Since a checkpoint causes all other |>activity to halt until it is complete, it has a MAJOR impact on performance. |>For max performance relative to this, set LRU_MAX_DIRTY low (no higher than |>10%), make your physical log as large as you can, and set your checkpoint |>interval to be huge. Let filling up the physlog drive the checkpoints. The |>major downsides to this are: 1) the length of time it will take to perform |>fast recivery in the case of a crash; and 2) how long it will take for |>logical logs to be freed (assuming you are doing logging). These two |>costs can be used to decine exactly how large your plog should be. |> |>|> Secondly, page cleaner flushes are not sorted but asynch. writes. |>|> |>|> On the other hand, checkpoints are sorted, synchronous writes. |> |>As of 7.10, LRU writes are also sorted. All writes are asynchronous to the |>user. If aync i/o (that is, kernel async i/o) is used for your port, all |>i/o is async in that respect. |> |>Dave Kosenko |>Disclaimer: All opinions expressed in this message are well-reasoned and |>insightful; needless to say, they are not those of Informix Software, its |>partners or lackeys. Anyone who says otherwise is itching for a fight. |>**************************************************************************** |>"I look back with some satisfaction on what an idiot I was when I was 25, |> but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney |>