Re: LRU writes

brian, we should keep this either as private e-mail or just to the list, as i get two messages for everything that gets send out! not a big deal, but kind of a pain. the advantage of the list is that other people can see it and throw in ideas. it can be difficult to diagnose a system sight unseen, but having just gone through a migration, and solving the performance problems, i will try to offer what assistence i can. > We came from 5.x so i assume that things were faster on the 5.0 system? and that is how you are judging that thing are slow? what is your plaform, and what version of informix? how many processors do you have, and how are your variables configured? MULTIPROCESSOR, NUMCPUVPS, SINGLE_CPU_VP, AFF_SPROC and AFF_NPROCS? these can make a big difference, if you have them set incorrectly especially on a single processor machine. what about OPTCOMPIND? when it is not set to 0, and tends to favor hash joins and looking at cost factors, i've heard that this can slow things down. use onstat -g act and rea to see the ready and active threads. do you have a queue or ready threads? is there a user process that is constantly active while everyone else is waiting? what about PDQ stuff? what is your PDQPRIORITY and MAXPDQPRIORITY? use onstat -g sch and glo and look at your vps. are there any that have a lot of busy waits or spin/waits? look at the stats and see if you can tell if there are vp's that are really spending their time doing nothing but looking busy. if a vp has nothing to do it will go into busy wait so that it won't get swapped out, but that can obviously eat up a lot of cpu time. this all is a good start. tracking down why a system is slow can be a lot of work. also, use onstat -g iof and look at your disk i/o. you can also use onperf with the disk tool. are you overloading a disk, so that so much of your i/0 is going there that you have a huge bottleneck? check that aspect out as well. let me know what you come up with. also, have you been on the phone to informix support? while a general problem like this doesn't get a lot of response, sometimes they can be helpful in getting you to see something you overlooked. > 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 mean that they aren't being used. many of the buffers, (hopefully), simply contain database pages that aren't modified. they are in use, but aren't pages that are getting written to, as you stated. that is what makes the system perform like it does, (or can when things go well), is that the next 100 rows the database needs happen to be in a buffer in memory, and not on disk, so you have bypassed the slowest operation in the system, a disk access. by the way, what is the percentage of reads/writes on your system? should be enough for now. mickm