Re: Online 7.x performance on a single CPU machine

Hmmmm....I would think that PDQPRIORITY wouldn't have much use on unie, assuming it functions according to its definition (as a percentage of maxpdqpriority which is also a percentage of "resources"....). No matter how low PDQPRIORITY is, you'll get about 1 CPU's worth of cycles if available. Setting PDQPRIORITY to anything of substance will kill OLTP response though. I've never found a way to get them to peacefully coexist on the same instance, on a six CPU Sun box anyway. If it's doable at all, it would probably need to be a very large machine, 10+ CPU's I'd guess, with MAXPDQPRIORITY 70ish or less. On a unie, I'd set PDQPRIORITY to one, and concentrate on getting good indexes in place for my nastier queries. > 1 is pretty useless unless you have lots of CPU's, disks and fragmented tables, and will just hose OLTP users. I have tried CPUVPS > # CPU's, and it doesn't hurt anything, probably does help in some cases. Don't be afraid to try it. This is one area you probably shouldn't take the doc too seriously. Greg Jason Harris wrote: snip.... snip.... > > > >While the merits of multi-threading can be argued back and forth, it is > >clear that for the above scenario it does not work out so well. On a > >single CPU machine, even a single "big" query sends OLTP performance down > >the tubes. Has anyone found a reasonable work-around to this problem? I > >have tried experimenting by setting the PDQPRIORITY of the "big" query to > >various numbers above 2 in order to have them treated as DSS queries. > >(Based on the implication in the manuals that PDQPRIORITY 0 queries -- non > >DSS queries -- are give a higher priority by the engine than DSS queries.) > >This seems to sometimes help a little bit, in that the OLTP queries don't > >suffer quite as much, but the improvement is still not enough to make the > >performance acceptable in most situations. Are there any other parameters > >that might help? > > > >In general, it would be nice if Informix provided some means of setting > >thread priorities other than PDQPRIORITY, or at least forced "big" queries > >to yield more often depending on PDQPRIORITY or some other setting. snip...