Re: Single cpu vp woe

Andrew Hamm wrote: > Art S. Kagel wrote: > >>Andrew, that will only seem to happen when the other activity on the >>system is not CPU intensive, which is quite common. Most business >>applications are IO bound not CPU bound. > > > very true, and in the systems we play on, the competing processes are 4GL > so they generally yield to wait on results from the engine. This is always > the perspective I come from. I was going to ask yours, and from what I > know of your system, I expected you to say that it's virtually dedicated > DSS, so this posting of yours is quite a surprise actually. Our environment looks most like a typical OLTP system, even though except for Trading Systems there are few real 'transactions' going on. The typical queries are small involving one to 4 tables with many repeated querie results cached in middleware. > Still, without NOAGE my type of system somehow manages to starve cpuvps > even when the competing processes are only 4GL and the usual standard O/S > processes. I'm guessing that Neil's customer is similar. Right. Because without NOAGE set the oninits are declared long-running and their priorities are degraded over time. The timeslices of such processes become fewer and longer when what Informix needs is more frequent slices. >>We don't see it on our >>systems because out servers, much to my chagrin, are sharing the >>machine with the entire Bloomberg environment which includes our >>homegrown global IPC mechanism, Bloomberg developed database servers, >>middleware servers, and application servers all of which are CPU >>bound. What we see are the oninits spiking into the 90%+ zone and >>dropping down when not needed. > > > and you still use NOAGE, or not, to try to gain some edge? The next step > is to explicitly mess with the priority settings to give it extra oomph - > if you're allowed to of course :-) > > I'd be interested to see how long the cpuvp queues are during your spikes, > and also the quiet periods. Queue lengths are typically short. > Anyway, in summary, I'm not surprised that Neil's customer is finding > better performance with more than one cpuvp on a single processor box. I > use that config as a legitimate design. Setting three seems to max out the > effects, and is borderline compared to setting two. Trial and error. About what I'd expect to see also. Art S. Kagel