#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
------------------------------

------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
------------------------------

------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
------------------------------

Original Message:
Sent: Thu April 16, 2020 08:49 AM
From: Paul Watson
Subject: Informix and Hyper-threading

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

------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