Re: IDS 9.4 multithread help with new hardware

"Art S. Kagel (Oninit)" <art@oninit.com> wrote in message news:mailman.906.1207749171.20610.informix-list@iiug.org... > > As far as how can you tune IDS to take best advantage of multiple > processor and multi-core processors? You can start more CPU VPs. I did > some testing back in the days of 400-500 MHZ processors. On Sun > processors faster than 450MHZ 2 CPU VPs per processor works well. With > the more recent 1.2GHZ single core processors I've seen as many as 3 CPU > VPs per processor run with good results. On the dual core 2.2GHZ Ultra > Sparc IV processors, I have not known anyone to try running more than 4 > per core - though using my old benchmark tests as a guide - each core > could support up to five CPU VPs (IBM believes that Sparc dual core > processors are equivalent to about 1.5 cores at the rated speed so that > would mean the ability to support up to 7 CPU VPs per processor or 3-4 per > core). > > Art S. Kagel > Oninit Not to contradict Art's empirical experience above, but just to point out that in theory one should not run more than one CPUVP per CPU core. I have not done a lot of testing on different platforms and configurations, but in the few tests I have done, my results are in line with the theory, i.e. increasing CPUVPs up to (or sometimes not quite up to) the number of cores can improve performance, but going beyond that starts to degrade it. If you are truly seeing increased performance with more CPUVPs than cores, I would guess there is some other tunable that is out of whack, and by adding more CPUVPs you are alleviating that problem indirectly. In theory one CPUVP should be able to completely saturate one CPU core, and in CPU-bound workloads that is what I have seen. Having more CPUVPs than cores mainly causes more context switching between CPUVP processes at the OS level. If a core does not scale up to the equivalent of a full CPU, then we'd expect some number fewer CPUVPs than cores to be optimal. Also if you have a lot of stuff going on that gets handled by VPs other than CPUVPs, sometimes it is beneficial to have fewer CPUVPs than cores to leave some cores free for those other VPs without causing undue context switching. (This seems to be less true if the workload is 100% saturating the CPUs. In that case, the CPUVPs dominate. Still we would not ever expect that having more CPUVPs than cores would be optimal.) -- Kevin Cherkauer Software Engineer IBM Informix Dynamic Server -- Database Kernel

"Kevin Cherkauer" <invalid_address@nowhere.com> wrote in message news:ftjlk5$bki$1@aioe.org... > "Art S. Kagel (Oninit)" <art@oninit.com> wrote in message > news:mailman.906.1207749171.20610.informix-list@iiug.org... >> >> As far as how can you tune IDS to take best advantage of multiple >> processor and multi-core processors? You can start more CPU VPs. I did >> some testing back in the days of 400-500 MHZ processors. On Sun >> processors faster than 450MHZ 2 CPU VPs per processor works well. With >> the more recent 1.2GHZ single core processors I've seen as many as 3 CPU >> VPs per processor run with good results. On the dual core 2.2GHZ Ultra >> Sparc IV processors, I have not known anyone to try running more than 4 >> per core - though using my old benchmark tests as a guide - each core >> could support up to five CPU VPs (IBM believes that Sparc dual core >> processors are equivalent to about 1.5 cores at the rated speed so that >> would mean the ability to support up to 7 CPU VPs per processor or 3-4 >> per core). >> >> Art S. Kagel >> Oninit > > Not to contradict Art's empirical experience above, but just to point out > that in theory one should not run more than one CPUVP per CPU core. I have > not done a lot of testing on different platforms and configurations, but > in the few tests I have done, my results are in line with the theory, i.e. > increasing CPUVPs up to (or sometimes not quite up to) the number of cores > can improve performance, but going beyond that starts to degrade it. If > you are truly seeing increased performance with more CPUVPs than cores, I > would guess there is some other tunable that is out of whack, and by > adding more CPUVPs you are alleviating that problem indirectly. In theory > one CPUVP should be able to completely saturate one CPU core, and in > CPU-bound workloads that is what I have seen. Having more CPUVPs than > cores mainly causes more context switching between CPUVP processes at the > OS level. > > If a core does not scale up to the equivalent of a full CPU, then we'd > expect some number fewer CPUVPs than cores to be optimal. Also if you have > a lot of stuff going on that gets handled by VPs other than CPUVPs, > sometimes it is beneficial to have fewer CPUVPs than cores to leave some > cores free for those other VPs without causing undue context switching. > (This seems to be less true if the workload is 100% saturating the CPUs. > In that case, the CPUVPs dominate. Still we would not ever expect that > having more CPUVPs than cores would be optimal.) > > -- > Kevin Cherkauer > Software Engineer > IBM Informix Dynamic Server -- Database Kernel P.S. One situation in which more CPUVPs than cores might seem to improve performance is in a case where the machine running IDS is being shared with other non-IDS work. For optimizing performance I always assume the server machine is dedicated to IDS, and that is what my prior post was based on. But if you are sharing a box between IDS and other things, then by proliferating your CPUVPs you are essentially tricking the OS into giving more timeslices to IDS and fewer to the non-IDS work. In other words, if the OS is sharing the time of the machine "fairly" over all the processes, both IDS and non-IDS, then by flooding the system with more IDS processes, IDS will be granted more of the total available time overall. Imagine if there are 4 CPUVPs and 4 non-IDS CPU-heavy processes on a machine. In this case, IDS would get roughly half of the total cycles on the machine. But if you increased to 8 CPUVPs, now IDS would get 2/3 of the total cycles on the machine (8 CPUVPs + 4 other processes, so IDS gets 8/12 of the available timeslices). When IDS is running by itself on a machine, then we would not expect that more CPUVPs than cores would be optimal. But if IDS is competing with other workload on the box, then the number of CPUVPs becomes a back-door knob by which the IDS DBA can determine what percentage of total machine resources are consumed by IDS. For the machine as a whole, more cycles are being wasted in context switching if CPUVPs are increased, but for IDS viewed in isolation it may manage to "steal" more cycles from other processes than are being lost to the additional context switches, so IDS performance would go up, while the performance of everything else on the machine would go down (more). -- Kevin Cherkauer Software Engineer IBM Informix Dynamic Server -- Database Kernel