Efficiency of the Informix Virtual Processors

Dear All, IDS 11.50.FC8W2 on Hp-UX 11.23 (12 core - 55 GB mem to informix) No other instance running on this machine. I was reading a post by john on http://www.jfmiii.com/informix/?p=194 It say that if the efficiency drops below 80% (onstat -g glo output) then there seems to be a problem, On my server this is way below 80% Individual virtual processors: vp pid class usercpu syscpu total Thread Eff 1 25998 cpu 596999.56 59735.98 656735.54 1386304.24 47% 2 26022 adm 565.72 242.50 808.22 0.00 0% 3 26023 cpu 760472.90 67782.91 828255.81 1482334.68 55% 4 26024 cpu 753012.02 66183.48 819195.50 1460697.74 56% 5 26025 cpu 728624.77 64313.88 792938.65 1414304.29 56% 6 26026 cpu 700316.87 61741.94 762058.81 1368809.35 55% 7 26027 cpu 681275.04 59123.57 740398.61 1326279.11 55% 8 26028 cpu 658406.09 56558.96 714965.05 1281118.10 55% 9 26029 cpu 640571.90 54235.48 694807.38 1246049.98 55% 10 26034 cpu 623314.34 52530.00 675844.34 1210579.85 55% 11 26035 cpu 609543.16 51168.91 660712.07 1180016.85 55% 12 26036 cpu 596393.14 50163.40 646556.54 1152408.93 56% 13 26037 cpu 590053.51 49154.31 639207.82 1156177.85 55% Please help me understand what next steps should I follow to determine the bottle neck if any Regards, Vikas

Mr. Miller, I agree please please give us more information. Here is my onstat -g glo output IDS 11.50.FC4 AIX 6.1 100GB Memory This is a dedicated database server with two RSS servers. lparstat -i Entitled Capacity : 6.00 Partition Group-ID : 32771 Shared Pool ID : 0 Online Virtual CPUs : 16 Maximum Virtual CPUs : 40 Minimum Virtual CPUs : 12 Online Memory : 102400 MB Maximum Memory : 391168 MB Minimum Memory : 51200 MB Variable Capacity Weight : 128 Minimum Capacity : 3.00 Maximum Capacity : 24.00 Capacity Increment : 0.01 Maximum Physical CPUs in system : 24 Active Physical CPUs in system : 24 Active CPUs in Pool : 24 Shared Physical CPUs in system : 24 Maximum Capacity of Pool : 2400 Entitled Capacity of Pool : 1400 Unallocated Capacity : 0.00 Physical CPU Percentage : 37.50% Unallocated Weight : 0 Memory Mode : Dedicated onstat -g glo # onstat -z ran 233 hours ago.Individual virtual processors: vp pid class usercpu syscpu total Thread Eff 1 9306260 cpu 61921.09 5929.83 67850.92 1086541.07 6% 2 9371712 adm 69.65 86.84 156.49 0.00 0% 3 9764882 cpu 58075.15 5579.70 63654.85 1000264.80 6% 4 9240686 cpu 42165.60 3941.65 46107.25 786594.57 5% 5 10223730 cpu 32178.53 2576.11 34754.64 575069.70 6% 6 9896030 cpu 22642.97 1781.54 24424.51 399043.91 6% 7 9699452 cpu 15832.24 1192.76 17025.00 271041.72 6% 8 10289268 cpu 10792.72 793.54 11586.26 182091.72 6% 9 7536650 cpu 7345.01 516.29 7861.30 119821.27 6% 10 11403318 cpu 4592.01 338.14 4930.15 81069.26 6% 11 9961648 cpu 2981.45 223.68 3205.13 52533.06 6% 12 9044046 cpu 2003.38 152.03 2155.41 36348.34 5% 13 10354854 cpu 1342.80 105.70 1448.50 28362.36 5% 14 8060994 cpu 823.10 75.60 898.70 19885.19 4% 15 10879094 cpu 596.76 57.27 654.03 15916.24 4% 16 7995558 cpu 499.97 42.31 542.28 13790.68 3% 17 11206748 cpu 411.83 33.13 444.96 12228.72 3% 18 10420348 cpu 295.72 25.56 321.28 9729.11 3% 19 11337872 cpu 213.88 20.33 234.21 5855.20 4% 20 852032 cpu 145.93 16.02 161.95 5567.20 2% 21 8978514 cpu 153.39 13.26 166.65 4255.98 3% 22 9568448 cpu 97.95 11.29 109.24 5871.01 1% 23 8585238 cpu 79.82 9.60 89.42 2464.62 3% 24 8388658 cpu 90.23 8.52 98.75 2402.26 4% 25 9175092 cpu 94.36 9.54 103.90 2808.00 3% ps -ef | grep oninit # from august 7 informix 852032 9371712 0 Aug 07 - 26:45 oninit -jvy informix 7536650 9371712 0 Aug 07 - 543:13 oninit -jvy informix 7995558 9371712 0 Aug 07 - 59:59 oninit -jvy informix 8060994 9371712 0 Aug 07 - 80:32 oninit -jvy informix 8192134 9371712 0 Aug 07 - 107:05 oninit -jvy informix 8257648 9371712 0 Aug 07 - 0:16 oninit -jvy informix 8388658 9371712 0 Aug 07 - 10:25 oninit -jvy informix 8585238 9371712 0 Aug 07 - 8:11 oninit -jvy informix 8978514 9371712 0 Aug 07 - 18:33 oninit -jvy informix 9044046 9371712 0 Aug 07 - 161:11 oninit -jvy informix 9175092 9371712 0 Aug 07 - 16:23 oninit -jvy informix 9240686 9371712 29 Aug 07 - 3382:12 oninit -jvy informix 9306260 1 62 Aug 07 - 4718:18 oninit -jvy informix 9371712 9306260 0 Aug 07 - 10:50 oninit -jvy informix 9568448 9371712 0 Aug 07 - 40:03 oninit -jvy informix 9633854 9371712 0 Aug 07 - 167:56 oninit -jvy informix 9699452 9371712 55 Aug 07 - 1208:47 oninit -jvy informix 9764882 9371712 41 Aug 07 - 4337:44 oninit -jvy informix 9896030 9371712 12 Aug 07 - 1768:03 oninit -jvy informix 9961648 9371712 0 Aug 07 - 235:32 oninit -jvy informix 10223730 9371712 29 Aug 07 - 2495:12 oninit -jvy informix 10289268 9371712 24 Aug 07 - 818:13 oninit -jvy informix 10354854 9371712 0 Aug 07 - 132:58 oninit -jvy informix 10420348 9371712 0 Aug 07 - 46:46 oninit -jvy informix 10682462 9371712 1 Aug 07 - 155:46 oninit -jvy informix 10813532 9371712 0 Aug 07 - 0:16 oninit -jvy informix 10879094 9371712 0 Aug 07 - 64:18 oninit -jvy informix 11206748 9371712 0 Aug 07 - 57:43 oninit -jvy informix 11337872 9371712 0 Aug 07 - 20:18 oninit -jvy informix 11403318 9371712 0 Aug 07 - 379:17 oninit -jvy informix 11534448 9371712 0 Aug 07 - 163:04 oninit -jvy informix 11665516 9371712 0 Aug 07 - 0:39 oninit -jvy informix 11731052 9371712 0 Aug 07 - 170:09 oninit -jvy informix 11796590 9371712 0 Aug 07 - 162:29 oninit -jvy informix 11862128 9371712 2 Aug 07 - 160:17 oninit -jvy informix 11927668 9371712 0 Aug 07 - 0:20 oninit -jvy informix 11993210 9371712 1 Aug 07 - 176:20 oninit -jvy informix 12058746 9371712 0 Aug 07 - 0:20 oninit -jvy informix 12189816 9371712 0 Aug 07 - 158:55 oninit -jvy informix 12320888 9371712 0 Aug 07 - 0:20 oninit -jvy

Be careful when using 11.50.xC4 and 111.50.xC5. If you run onstat -z it does not clear some counters that are used to calculate the efficiency. it should be resolved in FC6. Regards On Mon, Sep 17, 2012 at 2:36 PM, KERNOAL STEPHENS <informixdba@gmail.com>wrote: > Mr. Miller, I agree please please give us more information. > Here is my onstat -g glo output > IDS 11.50.FC4 AIX 6.1 100GB Memory > This is a dedicated database server with two RSS servers. > > lparstat -i > Entitled Capacity : 6.00 > Partition Group-ID : 32771 > Shared Pool ID : 0 > Online Virtual CPUs : 16 > Maximum Virtual CPUs : 40 > Minimum Virtual CPUs : 12 > Online Memory : 102400 MB > Maximum Memory : 391168 MB > Minimum Memory : 51200 MB > Variable Capacity Weight : 128 > Minimum Capacity : 3.00 > Maximum Capacity : 24.00 > Capacity Increment : 0.01 > Maximum Physical CPUs in system : 24 > Active Physical CPUs in system : 24 > Active CPUs in Pool : 24 > Shared Physical CPUs in system : 24 > Maximum Capacity of Pool : 2400 > Entitled Capacity of Pool : 1400 > Unallocated Capacity : 0.00 > Physical CPU Percentage : 37.50% > Unallocated Weight : 0 > Memory Mode : Dedicated > > onstat -g glo # onstat -z ran 233 hours ago.> Individual virtual processors: > vp pid class usercpu syscpu total Thread Eff > 1 9306260 cpu 61921.09 5929.83 67850.92 1086541.07 6% > 2 9371712 adm 69.65 86.84 156.49 0.00 0% > 3 9764882 cpu 58075.15 5579.70 63654.85 1000264.80 6% > 4 9240686 cpu 42165.60 3941.65 46107.25 786594.57 5% > 5 10223730 cpu 32178.53 2576.11 34754.64 575069.70 6% > 6 9896030 cpu 22642.97 1781.54 24424.51 399043.91 6% > 7 9699452 cpu 15832.24 1192.76 17025.00 271041.72 6% > 8 10289268 cpu 10792.72 793.54 11586.26 182091.72 6% > 9 7536650 cpu 7345.01 516.29 7861.30 119821.27 6% > 10 11403318 cpu 4592.01 338.14 4930.15 81069.26 6% > 11 9961648 cpu 2981.45 223.68 3205.13 52533.06 6% > 12 9044046 cpu 2003.38 152.03 2155.41 36348.34 5% > 13 10354854 cpu 1342.80 105.70 1448.50 28362.36 5% > 14 8060994 cpu 823.10 75.60 898.70 19885.19 4% > 15 10879094 cpu 596.76 57.27 654.03 15916.24 4% > 16 7995558 cpu 499.97 42.31 542.28 13790.68 3% > 17 11206748 cpu 411.83 33.13 444.96 12228.72 3% > 18 10420348 cpu 295.72 25.56 321.28 9729.11 3% > 19 11337872 cpu 213.88 20.33 234.21 5855.20 4% > 20 852032 cpu 145.93 16.02 161.95 5567.20 2% > 21 8978514 cpu 153.39 13.26 166.65 4255.98 3% > 22 9568448 cpu 97.95 11.29 109.24 5871.01 1% > 23 8585238 cpu 79.82 9.60 89.42 2464.62 3% > 24 8388658 cpu 90.23 8.52 98.75 2402.26 4% > 25 9175092 cpu 94.36 9.54 103.90 2808.00 3% > > ps -ef | grep oninit # from august 7 > informix 852032 9371712 0 Aug 07 - 26:45 oninit -jvy > informix 7536650 9371712 0 Aug 07 - 543:13 oninit -jvy > informix 7995558 9371712 0 Aug 07 - 59:59 oninit -jvy > informix 8060994 9371712 0 Aug 07 - 80:32 oninit -jvy > informix 8192134 9371712 0 Aug 07 - 107:05 oninit -jvy > informix 8257648 9371712 0 Aug 07 - 0:16 oninit -jvy > informix 8388658 9371712 0 Aug 07 - 10:25 oninit -jvy > informix 8585238 9371712 0 Aug 07 - 8:11 oninit -jvy > informix 8978514 9371712 0 Aug 07 - 18:33 oninit -jvy > informix 9044046 9371712 0 Aug 07 - 161:11 oninit -jvy > informix 9175092 9371712 0 Aug 07 - 16:23 oninit -jvy > informix 9240686 9371712 29 Aug 07 - 3382:12 oninit -jvy > informix 9306260 1 62 Aug 07 - 4718:18 oninit -jvy > informix 9371712 9306260 0 Aug 07 - 10:50 oninit -jvy > informix 9568448 9371712 0 Aug 07 - 40:03 oninit -jvy > informix 9633854 9371712 0 Aug 07 - 167:56 oninit -jvy > informix 9699452 9371712 55 Aug 07 - 1208:47 oninit -jvy > informix 9764882 9371712 41 Aug 07 - 4337:44 oninit -jvy > informix 9896030 9371712 12 Aug 07 - 1768:03 oninit -jvy > informix 9961648 9371712 0 Aug 07 - 235:32 oninit -jvy > informix 10223730 9371712 29 Aug 07 - 2495:12 oninit -jvy > informix 10289268 9371712 24 Aug 07 - 818:13 oninit -jvy > informix 10354854 9371712 0 Aug 07 - 132:58 oninit -jvy > informix 10420348 9371712 0 Aug 07 - 46:46 oninit -jvy > informix 10682462 9371712 1 Aug 07 - 155:46 oninit -jvy > informix 10813532 9371712 0 Aug 07 - 0:16 oninit -jvy > informix 10879094 9371712 0 Aug 07 - 64:18 oninit -jvy > informix 11206748 9371712 0 Aug 07 - 57:43 oninit -jvy > informix 11337872 9371712 0 Aug 07 - 20:18 oninit -jvy > informix 11403318 9371712 0 Aug 07 - 379:17 oninit -jvy > informix 11534448 9371712 0 Aug 07 - 163:04 oninit -jvy > informix 11665516 9371712 0 Aug 07 - 0:39 oninit -jvy > informix 11731052 9371712 0 Aug 07 - 170:09 oninit -jvy > informix 11796590 9371712 0 Aug 07 - 162:29 oninit -jvy > informix 11862128 9371712 2 Aug 07 - 160:17 oninit -jvy > informix 11927668 9371712 0 Aug 07 - 0:20 oninit -jvy > informix 11993210 9371712 1 Aug 07 - 176:20 oninit -jvy > informix 12058746 9371712 0 Aug 07 - 0:20 oninit -jvy > informix 12189816 9371712 0 Aug 07 - 158:55 oninit -jvy > informix 12320888 9371712 0 Aug 07 - 0:20 oninit -jvy > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --20cf302ef94aef1daf04c9e79620

I agree too , more information about the "cautions" of this efficiency versus OS (and hardware processor) will help a lot... I'm have "trouble" with this too , running ifx 11.50 FC9X6 / AIX 6.1 Running over P7 with smt4 active (I'm not able to change this...) Before I have the CPU VPs = 50% Virtual CPUs configured at LPAR... and the efficency stay in +- 58% After read the article , I decided try get better efficiency , without much information about this, my guess was I have to much CPUs VPs . So than I drop 50% of CPU VPs (to keep 1 to 1 , VPs to CPU Core) , and have no effect over this efficiency %. (drop CPUs executed with onmode -p ) Not sure if my case the SMT4 can influence over this % . (and as murphy law, after this change, coincidentally or not , start occur a delay at the synchronization with the secondary RSS we have... I already back the original configuration, with "onmode -p", but the delay just keep occurring........ ) Individual virtual processors: vp pid class usercpu syscpu total Thread Eff 1 10551656 cpu 132706.76 8656.04 141362.80 248690.25 56% 2 13762800 adm 28.76 18.99 47.75 0.00 0% 3 4063256 cpu 120849.68 8091.60 128941.28 226326.39 56% 4 6094914 cpu 154062.98 5091.50 159154.48 272209.02 58% 5 10092874 cpu 140383.18 4337.14 144720.32 247128.23 58% 6 8847682 cpu 125294.04 3641.25 128935.29 220377.38 58% 7 4915308 cpu 108976.18 2967.08 111943.26 190530.60 58% 8 3932614 cpu 94901.89 2357.15 97259.04 165851.22 58% 9 3801578 cpu 75074.01 2000.38 77074.39 133304.05 57% 10 6160450 cpu 60000.93 1619.67 61620.60 106861.15 57% 11 6225988 cpu 48347.76 1105.54 49453.30 85851.22 57% 12 4063612 cpu 38805.02 802.80 39607.82 69669.11 56% 13 6291526 cpu 36468.80 769.14 37237.94 65888.62 56% 14 6357064 cpu 27033.82 553.98 27587.80 48921.86 56% 15 4194636 cpu 22312.50 476.64 22789.14 40905.80 55% 16 4260178 cpu 19096.00 342.96 19438.96 35710.58 54% 17 4391256 cpu 20980.78 315.93 21296.71 39054.33 54% On 17/9/2012 04:02, VIKAS HIVARKAR wrote: > Dear All, > > IDS 11.50.FC8W2 on Hp-UX 11.23 (12 core - 55 GB mem to informix) > No other instance running on this machine. > > I was reading a post by john on http://www.jfmiii.com/informix/?p=194 > > It say that if the efficiency drops below 80% (onstat -g glo output) then > there seems to be a problem, > > On my server this is way below 80% > > Individual virtual processors: > vp pid class usercpu syscpu total Thread Eff > 1 25998 cpu 596999.56 59735.98 656735.54 1386304.24 47% > 2 26022 adm 565.72 242.50 808.22 0.00 0% > 3 26023 cpu 760472.90 67782.91 828255.81 1482334.68 55% > 4 26024 cpu 753012.02 66183.48 819195.50 1460697.74 56% > 5 26025 cpu 728624.77 64313.88 792938.65 1414304.29 56% > 6 26026 cpu 700316.87 61741.94 762058.81 1368809.35 55% > 7 26027 cpu 681275.04 59123.57 740398.61 1326279.11 55% > 8 26028 cpu 658406.09 56558.96 714965.05 1281118.10 55% > 9 26029 cpu 640571.90 54235.48 694807.38 1246049.98 55% > 10 26034 cpu 623314.34 52530.00 675844.34 1210579.85 55% > 11 26035 cpu 609543.16 51168.91 660712.07 1180016.85 55% > 12 26036 cpu 596393.14 50163.40 646556.54 1152408.93 56% > 13 26037 cpu 590053.51 49154.31 639207.82 1156177.85 55% > > Please help me understand what next steps should I follow to determine the > bottle neck if any > > Regards, > Vikas > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hi Cesar, Are you using processor affinity? Do you have one CPU VP for each logical CPU that SMT is presenting (e.g. four times the number of physical cores)? Do you observe that your actual CPU performance is poor, or are you just trying to understand the numbers in this output? The actual usr/sys/wio/idle stats from the CPUs need to be considered. Is it high in sys or wio? Other settings that come to mind are the number and location of poll threads, other VPs such as AIO, and process aging. It is interesting that your VPs, from about #10 on, have significantly less utilization that the other CPU VPs. Each one has less than half the utilization of the first 6 or so. I'll also note that the Kernoal's AIX output in this discussion shows the CPU usage tailing off too, but the OP's HP-UX output is quite balanced. I don't know what could cause the delay with RSS, or if it is related to this. Cheers, Jason

Hi Jason, No Affinity. The configuration what we work the lasts months is 2 CPU VPs for each CORE (where have 4 smt), so... 50% of the virtual AIX CPUs. My change is exactly over this, I try work with 1 CPU VPs for 1 CORE CPU, but I not seen effect over the efficient (onstat -g glo) and get into the problem with my RSS. At the moment, no problem with CPU performance. Is more trying understand the numbers and try make it better. Than identify if this change can have some effect with the performance. No, ultimately we don't have high usr/sys/wio . the AVG of one day is close of 60/1/0% No agging , using KAIO (so , just fews AIO VPs). The delay with RSS , I have some clues, appear be the checkpoint synchronization between primary/secondary. When the primary execute a checkpoint , the RSS transmition change to Blocked state until the secondary execute they checkpoint, what never is at the same time..... always have a delay of few minutes. So, this create the delay what I'm detecting (delay avg of 7 minutes normally, what is too much of our businesses). I just not understand why this start occur after I change the CPU VPs (my theory is about KAIO, less CPU = less I/O throughput, worst disk flush, but I revert the configuration and the delay/blocking state still occurring) On 19/9/2012 23:56, JASON HARRIS wrote: > Hi Cesar, > > Are you using processor affinity? Do you have one CPU VP for each logical CPU > that SMT is presenting (e.g. four times the number of physical cores)? > > Do you observe that your actual CPU performance is poor, or are you just > trying to understand the numbers in this output? > > The actual usr/sys/wio/idle stats from the CPUs need to be considered. Is it > high in sys or wio? > > Other settings that come to mind are the number and location of poll threads, > other VPs such as AIO, and process aging. > > It is interesting that your VPs, from about #10 on, have significantly less > utilization that the other CPU VPs. Each one has less than half the > utilization of the first 6 or so. > > I'll also note that the Kernoal's AIX output in this discussion shows the CPU > usage tailing off too, but the OP's HP-UX output is quite balanced. > > I don't know what could cause the delay with RSS, or if it is related to this. > > Cheers, > > Jason > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hi Cesar, It may seem odd, but I have found that Informix works better with SMT if you use affinity. Otherwise, SMT tries to push every thread of one oninit processes to a different logical processor. We want them all to stay on the same one, setting processor affinity does that. I don't recall off hand, but when you add a CPU VP does it get a KIO thread? And if the ones you dropped had poll threads on them, do the ones you add get new ones? These could affect the performance. To understand thread efficiency, ask yourself this question: Why does it take so long (thread time) to get so little (CPU time) done? Typically, slow I/O either network or disk can contribute, contention with other processes on the server, lock of memory/swapping, too much context switching. Consider a system with slow disk, the threads won't do much work sitting around waiting for data to come it. This will result in a low effective percent. A low effective percent is not always something that can be fixed with simple configuration changes, or even something that needs to be fixed. It does indicate that there is room there for improvement. It probably indicates that adding CPU won't improve the performance. Hopefully, John will write some more about it in the future. Cheers, Jason

Hi Jason, Well, about the proc affinity , I have a complete inverse experience... when defined the affinity the performance goes down. But this was with Sun T2 processor (ugh!), not tried with this IBM P7 + SMT4. Your questioning about KAIO , drop/add CPU VPs keep the KIO thread working, I can say what happen here : after drop/add cpu dynamically, looking with "onstat -g ioa" , the kio appears for this new CPU VPs added and the numbers to show they working "properly". (if can affect others "parts" of the engine , is other mystery). About the efficiency versus I/O wait, Networking , memory and etc, I believed this is not an issue in our environment. We have a good I/O throughput with our storage , network and about memory we are using large pages and there is no problem with the amount already allocated (this LPAR have only the database working over it, so no concurrency with others softwares). The context switching is something what is hard says if you have a good number or not (or exists some formula? for database dedicated environments). I have all historical (sar) since we using other production machine (Power 6) and the point of view the proportional growth of the context switch VS # of Procs (where the new/actual machine have 3 times more CPUs/COREs) , the number is good because they grew less of 60% . I will think about test the affinity , just not sure when... Thanks for this tip. On 20/9/2012 20:45, JASON HARRIS wrote: > Hi Cesar, > > It may seem odd, but I have found that Informix works better with SMT if you > use affinity. Otherwise, SMT tries to push every thread of one oninit > processes to a different logical processor. We want them all to stay on the > same one, setting processor affinity does that. > > I don't recall off hand, but when you add a CPU VP does it get a KIO thread? > And if the ones you dropped had poll threads on them, do the ones you add get > new ones? These could affect the performance. > > To understand thread efficiency, ask yourself this question: Why does it take > so long (thread time) to get so little (CPU time) done? Typically, slow I/O > either network or disk can contribute, contention with other processes on the > server, lock of memory/swapping, too much context switching. > > Consider a system with slow disk, the threads won't do much work sitting > around waiting for data to come it. This will result in a low effective > percent. > > A low effective percent is not always something that can be fixed with simple > configuration changes, or even something that needs to be fixed. > > It does indicate that there is room there for improvement. It probably > indicates that adding CPU won't improve the performance. > > Hopefully, John will write some more about it in the future. > > Cheers, > > Jason > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hi Cesar, It sounds like your system is fine. The CPU percent with only 1% sys is pretty good. My experience was on P6 not P7, so YMMV. If you are going to try it, its worth checking the way the logical CPUs are sequenced. Your earlier onstat -g glo output showed that the top CPU VPs are the busiest. You don't wont them all ending up on the same core. e.g. aff=(0,4,8,12,1,5,9,13,...) instead of aff=(0-17). Or just check it after and move if required. Good luck, Jason

Does anyone know if enabling KAIO will cause a drop in CPU VP efficiency in the onstat -g glo output? Seems to make sense since previously the AIO VPs would have been doing all of the IO waiting and if you switch to KAIO the kaio threads will run on the CPU VPs and the waiting they do will be included in the CPU VP efficiency calculations. Thanks, Andrew