Re: NUMCPUVPS

Does this still apply using 7.31.UC4? Check the FAQ at www.smooth1.demon.co.uk martyn.ayshford@orange.co.uk wrote in message <8o1grh$j0t$1@nnrp1.deja.com>... >mmmmm > >In addtion to what the others said.... > >Are you running KAIO? > >If you are do the following > >echo "_ncols/D"|adb -k /stand/vmunix /dev/kmem > >If this going up at all be worried, if it's going up real fast be very >worried. It measures the number of collisions ie the number of times >all your CPUVP's have been woken up to perform IO (if your using KAIO) >the high end HP's seem to hit a brick wall at certain load levels >because of this, switch to AIO VP's and the problem goes away. > >cheers > >mja > > > > >In article <39A40185.2C236948@wholefoods.com>, > Phillip <tienp@wholefoods.com> wrote: >> According to the manuals, NUMCPUVPS should be one less than actual >physical >> CPUs. If you have 6 physical CPUs, set NUMCPUVPS to 5. You should >check the >> cache hit ratios for both read and write when you do an onstat -p as >this will >> tell you if you're having a lot of I/O. For OLTP environments, read >ratios >> should be >=95% and write ratios should be >=85%. If numbers are >less than >> this, that means too much activity is going to and from disk rather >than being >> done in memory. If that's the case, you should tune your shared >memory >> parameters (BUFFERS, LRUs, CLEANERS, etc.). >> >> Masa wrote: >> >> > We have a two server cluster environment. Another server is for Baan >> > application and another is for Informix database. >> > Informix version is 7.31 FC2. Both servers are HP N 4000 (6 CPU) >with HP-UX >> > 11.0. >> > >> > Now users are reported to us that application is getting slower. >> > >> > Application server runs 50-60% Idle time almost whole day. Database >server >> > runs only 10-15 % Idle time during rush ours. >> > Oninit processes are first on top listing. >> > >> > >************************************************************************ >**** >> > >> > What is the right value for parameter NUMCPUVPS ? >> > >> > Now is is same as physical processor number (6) >> > >> > There are two onstat listings. (measuring interval 3670 sec) >> > Onstat -p >> > >> > Up 2 days 23:58:56 >> > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes >> > 0 0 0 39043.25 109627.06 1957 4274 >> > >> > Up 3 days 01:00:06 >> > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes >> > 0 0 0 41719.61 121013.40 1987 4334 >> > >> > Thanks for your advice! >> >> -- >> Phillip Tien >> Database Administrator >> Whole Foods Market, Inc. >> >> "I always wanted to be the last guy on Earth just to see if all those >women were >> lying to me." >> >> > > >Sent via Deja.com http://www.deja.com/ >Before you buy.

Pass. 7.31UC2XT certainly exhibits the problem. My guess though from discussions with HP tech Support is that it does. HP are no-longer recommending use of KAIO. Consult your support contacts for the official line. The symtoms of hitting this wall are slow socket connects (shared memory fast), lots of mutex waits on Network NSF. High cpu utilization in system (unfortunatley you see that even on OK performing nodes with KAIO). By far the best metric is the collisions. HP describe it as the 'thundering herd' ask for their white paper for a full description. Basically all CPUVP's have a handle on a chunk. When IO action is requested all are woken up to service it. Only one can, so the others are locked. Get enough CPUVP's and enough IO and you bring HP big Iron to it's knees, I've seen the effect on a 32 Way V class running just 14 CPUVP's and doing nothing else. In article <39a5950d_1@news1.vip.uk.com>, "smooth1" <smooth1@iclway.co.uk> wrote: > > Does this still apply using 7.31.UC4? > Check the FAQ at www.smooth1.demon.co.uk > > martyn.ayshford@orange.co.uk wrote in message > <8o1grh$j0t$1@nnrp1.deja.com>... > >mmmmm > > > >In addtion to what the others said.... > > > >Are you running KAIO? > > > >If you are do the following > > > >echo "_ncols/D"|adb -k /stand/vmunix /dev/kmem > > > >If this going up at all be worried, if it's going up real fast be very > >worried. It measures the number of collisions ie the number of times > >all your CPUVP's have been woken up to perform IO (if your using KAIO) > >the high end HP's seem to hit a brick wall at certain load levels > >because of this, switch to AIO VP's and the problem goes away. > > > >cheers > > > >mja > > > > > > > > > >In article <39A40185.2C236948@wholefoods.com>, > > Phillip <tienp@wholefoods.com> wrote: > >> According to the manuals, NUMCPUVPS should be one less than actual > >physical > >> CPUs. If you have 6 physical CPUs, set NUMCPUVPS to 5. You should > >check the > >> cache hit ratios for both read and write when you do an onstat -p as > >this will > >> tell you if you're having a lot of I/O. For OLTP environments, read > >ratios > >> should be >=95% and write ratios should be >=85%. If numbers are > >less than > >> this, that means too much activity is going to and from disk rather > >than being > >> done in memory. If that's the case, you should tune your shared > >memory > >> parameters (BUFFERS, LRUs, CLEANERS, etc.). > >> > >> Masa wrote: > >> > >> > We have a two server cluster environment. Another server is for Baan > >> > application and another is for Informix database. > >> > Informix version is 7.31 FC2. Both servers are HP N 4000 (6 CPU) > >with HP-UX > >> > 11.0. > >> > > >> > Now users are reported to us that application is getting slower. > >> > > >> > Application server runs 50-60% Idle time almost whole day. Database > >server > >> > runs only 10-15 % Idle time during rush ours. > >> > Oninit processes are first on top listing. > >> > > >> > > >*********************************************************************** * > >**** > >> > > >> > What is the right value for parameter NUMCPUVPS ? > >> > > >> > Now is is same as physical processor number (6) > >> > > >> > There are two onstat listings. (measuring interval 3670 sec) > >> > Onstat -p > >> > > >> > Up 2 days 23:58:56 > >> > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > >> > 0 0 0 39043.25 109627.06 1957 4274 > >> > > >> > Up 3 days 01:00:06 > >> > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > >> > 0 0 0 41719.61 121013.40 1987 4334 > >> > > >> > Thanks for your advice! > >> > >> -- > >> Phillip Tien > >> Database Administrator > >> Whole Foods Market, Inc. > >> > >> "I always wanted to be the last guy on Earth just to see if all those > >women were > >> lying to me." > >> > >> > > > > > >Sent via Deja.com http://www.deja.com/ > >Before you buy. > > Sent via Deja.com http://www.deja.com/ Before you buy.