Informix and Hyper-threading

Just curious about people's experience with Hyper-Threading. Despite what the vendors say, I have yet to test a dedicated Informix server and find hyper-threading active to be a good thing. Currently battling with sysadmins who refuse to believe me, the documented results or test in their world or ....... They just state the fact the vendor position is it must be on – End Of Story Cheers Paul Paul Watson Oninit www.oninit.com Tel: +1 913 674 0360 Cell: +1 913 387 7529 Oninit® is a registered trademark of Oninit LLC Failure is not as frightening as regret. If you want to improve, be content to be thought foolish and stupid. #Informix

Hey Paul, We were trying to improve performance in our VMs, and having hyperthreading turned off at the hypervisor level (physical host) improved our performance by 10%. A test in a lower environment physical host shouldn't hurt. As always, YMMV. Stay safe! Ramon ------------------------------ Ramon Rey Any opinions I express here are my own and not the views of my employer. ------------------------------

This question does not have a simple answer. However, based on a lot of data from OLTP benchmarks performed on a variety of hardware, one recommendation can be given - use resources (CPU, memory) with maximum degree of affinity to run Informix. In which case enabling HT, SMT, CMT, etc. (+ appropriate adjustment for number of CPUVPS) will show noticeable boost in performance for workloads with high volume of transactions. That is - if everything else in configuration is also optimized - like working set is appropriately cached, Informix logs are fast, etc., etc... Most current hardware is so called NUMA - Non Uniform Memory Architecture - has 2 or more "nodes", usually corresponding to CPU sockets. It's well established fact in the industry that using cross-node resources for certain workload types MAY result in significantly less efficiency or performance per computing unit (core). In that situation enabling Hyper Threading clearly will not provide any benefits. However some workloads may benefit both from running across all nodes and having HT on. Therefore recommendation to always disable HT for Informix is simply wrong. Workload, hardware and other configuration specifics must be taken into account. ------------------------------ Vladimir Kolobrodov ------------------------------

My statement is test it and see ------Original Message------ This question does not have a simple answer. However, based on a lot of data from OLTP benchmarks performed on a variety of hardware, one recommendation can be given - use resources (CPU, memory) with maximum degree of affinity to run Informix. In which case enabling HT, SMT, CMT, etc. (+ appropriate adjustment for number of CPUVPS) will show noticeable boost in performance for workloads with high volume of transactions. That is - if everything else in configuration is also optimized - like working set is appropriately cached, Informix logs are fast, etc., etc... Most current hardware is so called NUMA - Non Uniform Memory Architecture - has 2 or more "nodes", usually corresponding to CPU sockets. It's well established fact in the industry that using cross-node resources for certain workload types MAY result in significantly less efficiency or performance per computing unit (core). In that situation enabling Hyper Threading clearly will not provide any benefits. However some workloads may benefit both from running across all nodes and having HT on. Therefore recommendation to always disable HT for Informix is simply wrong. Workload, hardware and other configuration specifics must be taken into account. ------------------------------ Vladimir Kolobrodov ------------------------------ #Informix

Hi Paul, It would be interesting to know how you are measuring whether it is a good thing. Do you go by the efficiency metric reported by 'onstat -g glo' or other metrics? Do you use processor affinity at all and, if so, how do you configure it? I guess two Informix CPU VPs being scheduled onto each of the two paths to the same processor would be detrimental to performance. I say "guess" because I haven't measured this. Having an affinity set up which avoids using HT (i.e. a list of unique processor numbers without any HT pairs) while still leaving HT on seems sensible. It certainly avoids battling with a customer's sys admins. Ben. ------------------------------ Benjamin Thompson ------------------------------

The basic investigation always starts with a simple what is the current TPS, turn off the HT, and re-measure TPS. Based on the results the discussion goes there. What makes me laugh/scream is when the sysadmins, after testing, agree it is faster and still refuse to turn it HT off Aside: On ex-senior Informix tech guy once told me the efficiency was meaningless. Cheers Paul ------Original Message------ Hi Paul, It would be interesting to know how you are measuring whether it is a good thing. Do you go by the efficiency metric reported by 'onstat -g glo' or other metrics? Do you use processor affinity at all and, if so, how do you configure it? I guess two Informix CPU VPs being scheduled onto each of the two paths to the same processor would be detrimental to performance. I say "guess" because I haven't measured this. Having an affinity set up which avoids using HT (i.e. a list of unique processor numbers without any HT pairs) while still leaving HT on seems sensible. It certainly avoids battling with a customer's sys admins. Ben. ------------------------------ Benjamin Thompson ------------------------------ #Informix

I just have to comment on this .... :-) > The basic investigation always starts with a simple what is the current TPS, turn off the HT, and re-measure TPS yes, and for multiple platforms Intel, AIX, SPARC, I personally have data showing that HT, SMT, CMT gives considerable boost in performance - when configuration uses memory from the same node(s) and there are no other bottlenecks. I also make sure that my benchmark client does not use same CPU resources as Informix, if running on the same hardware. All data was collected on recent processors. > efficiency was meaningless that well may be if we are discussing onstat output (however in some cases it's less meaningless that in others) but if you get same TPS from 18 cores as from 36 cores - there is no doubt that the efficiency has very definite meaning, and that there is no reason to use 36 cores if same performance can be obtained with less resources. > agree it is faster and still refuse to turn it HT off Would not anyone be interested to see WHY it's faster with HT off - and fix configuration to remove possible bottlenecks ? ------------------------------ Vladimir Kolobrodov ------------------------------

Comment away J Just wanted to hear other people experience. >> efficiency was meaningless >that well may be if we are discussing onstat output (however in some cases it's less meaningless that in others) but if you get same TPS from 18 cores as from 36 cores - there is no doubt >that the efficiency has very definite meaning, and that there is no reason to use 36 cores if same performance can be obtained with less resources. I agree, I have always found it useful. Just relaying a comment made to me by an IBM'er >> agree it is faster and still refuse to turn it HT off >Would not anyone be interested to see WHY it's faster with HT off - and fix configuration to remove possible bottlenecks ? Some people are just not interested in finding out J ------Original Message------ I just have to comment on this .... :-) > The basic investigation always starts with a simple what is the current TPS, turn off the HT, and re-measure TPS yes, and for multiple platforms Intel, AIX, SPARC, I personally have data showing that HT, SMT, CMT gives considerable boost in performance - when configuration uses memory from the same node(s) and there are no other bottlenecks. I also make sure that my benchmark client does not use same CPU resources as Informix, if running on the same hardware. All data was collected on recent processors. > efficiency was meaningless that well may be if we are discussing onstat output (however in some cases it's less meaningless that in others) but if you get same TPS from 18 cores as from 36 cores - there is no doubt that the efficiency has very definite meaning, and that there is no reason to use 36 cores if same performance can be obtained with less resources. > agree it is faster and still refuse to turn it HT off Would not anyone be interested to see WHY it's faster with HT off - and fix configuration to remove possible bottlenecks ? ------------------------------ Vladimir Kolobrodov ------------------------------ #Informix