Re: HELP: Informix Online on HP-K460 is NOT-SCALABLE?

James Francis asks: > We have an HP-K460 server running HP-UX 10.20 attached to an EMC high-speed > disk array. > Our database is around 100GB. > > When we run our application with one user everything performs lightning > fast. > As more users degrade, the performance continues to degrade. > > The relevant parameters from the onconfig file: > MULTIPROCESSOR 1 > NUMCPUVPS 3 > NETTYPE ipcshm,2,300,CPU While some may argue this one with me, I see no need for 2 poll threads for local connections with even as many as 200 users (or 300 as you have it tuned for). Will you have that many users connecing locally? If so, you will have another big problem as that many users try running apps on the same box as the server. If, on the other hand, your users are running client/server, then you can bump this down a lot. It will at least reduce the amount of shared memory you are using. > NETTYPE soctcp,1,100 ,NET > BUFFERS 7200 As others have commented, this is rather low, esp for a machine with a gig of memory. Read cache rates are not the whole story on this. > PDQPRIORITY 0 So you are not fragmenting any tables? If you are, you want this to at least be 1 to get parallel table scans. > OPTCOMPIND 0> > onstat -g rea shows consistently around 10 entries. The ready queue can be deceiving. Often times, server threads are sitting on an smread (if memory serves) which means they are just waiting for the client to send a request. Are you sure you are *driving* the server hard enough? Are all the users doing work when the degradation occurs? How are they realizing the degradation, long wait times for query results? What is the client tool/app being used? Some clients are a source of problems. You also really need to get some Unix stats, i.e. sar, to see how much cpu resource is being burned. If you are seeing significant idle time, then the server is not properly using available resources. If you are getting a lot of i/o wait, you need to look at your disk/controller config. I as the same question as others: are you using kaio? If not, what are your online i/o queues looking like? How many aio vps? > onstat -p shows a high number of bufwaits and lchwaitsTypically an indication of poor database design, e.g.. everyone needs the exact same small set of records. The bufwaits could also indicate some buffer starvation (do you zero your stats? if not, the high cache rates could be historical and thus mask some problems), though it is rather uncommon. Want better answers? Provide more details. -- Dave "That's just my opinion - I could be wrong." - Dennis Miller