Re: LRU writes

On Fri, 3 May 1996, Mickey Mestel wrote: > first of all, have you migrated from another version, where you have > something to compare it with? that is an important point. We came from 5.x > the next question is, have you run update statistics on your > databases, (especially if this was a migration)? when i did my migration, > i forgot to run update statistics on the last batch of databases. queries > that were taking less than one minute on the old system, were now taking > 15-20 minutes, even more, and slowing the system to a crawl. after i ran > update statistics (high, my databases are not that big) the queries were> even faster than on my old 5.01 system. Our weekley update stats looks like: main database dirdb update statistics high database snsdb update statistics high database seamdb update statistics high database limdb update statistics high database findb update statistics high database astdb update statistics high end main It seems like the straightforward way to do things. > > Our % read cache is 99.9x% and writes are 98.x We have 10240 buffers > > then you have enough buffers. I thought so. We had 20K before, but it seemed to be wasted. > > distributed in 20 LRUs. LRUMIN is 5, LRUMAX is 10. Would it make sense to > > increase the number of LRUS, thus having more queues to spread the > > buffering across? Or does queue management start to become an issue. > > Checkpoints, every 30 minutes, are 10 secs. > > queue management does become an issue. for the number of buffers > that you have, you don't need any more. i have 16000 buffers, and 10 queues. > how about the number of CLEANERS? usually it's said that they should equal > the number of devices that you have, but i usually go with the same number > of LRU queues, so there is one cleaner per queue. We have 10 cleaners. Watching presently, it appears to satisfy the needs, i.e. Queues NEVER get over 10%. Now, does it mean that if 90% of our buffers never get dirty, that they are not being used? or does that mean that they are being used for read of an unchanged part of the database? > it doesn't necessarily sound like this is the source of your problem. > the performance problem that relates to this is when every X minutes, the > system freezes for Y seconds while it does a checkpoint, and so users sit > there with their application frozen for those Y seconds. that might not > be tolerable, so you tune the above scenario so that the checkpoint takes > much less time to complete, and so is not noticable, or as noticable. to > seconds every 30 minutes sounds resonable to me. This is what I am afraid of. It seems that everything runs a little slower, and hence there are more things runnning at any given time, since if things are slow, the users put things into the background and start something else, and then logjam! > let me know about the statistics, and we can try to go from there > if this doesn't do it. There you have it. Hope this helps get to what is causing this. We are approaching our company busy season! B. ------------------------------------------------------------------------- |Brian P. Hampson Internet : brian@asl-labs.bc.ca | |System Administrator, Air(2m/70cm): VE7NNW | |Analytical Service Labs Fidonet : Brian Hampson 1:153/733| |Vancouver, BC | |+604-253-4188 | | Specialists in Environmental Chemistry | | | ------------------http://www.asl-labs.bc.ca/-----------------------------