What were you trying to do that didn't work?

Running Hammedb workload with MS SQL database backend. When the hammedb client is run on Linux, the workload performance drops. See the TPM numbers drop from 40 users to 80 Users.

40U - 3911875
80U - 1946651

What is the impact of this issue to you?

This has performance implications for clients who port MS SQL Server to Linux. MS SQL Server on Linux needs the unixODBC driver for clients to connect to the database. If the client is running on Windows, there is no issue but if they port their application to Linux, they will encounter this performance bottleneck

Please provide the package NVR for which the bug is seen:

How reproducible is this bug?:

This is readily reproducible

Steps to reproduce

1. Run hammerdb client with 40 users and 80 Users on a linux host to a MSSQL Server database backend.
2.  
3.  

Expected results

The TPM numbers should go up as the user count increases or reach a saturation point and flatten off. The performance should not drop

Actual results

The TPM numbers show a huge drop.

We collected perf profiles which shows the libodbc.so. as a hot routine

1. To display the perf.data header info, please use -header/-header-only options.
   #
   #
2. Total Lost Samples: 0
   #
3. Samples: 513K of event 'cycles'
4. Event count (approx.): 114701223384
   #
5. Overhead  Command          Shared Object                           Symbol                                                 
      
6. ........  ...............  ......................................  .......................................................
   ...
   #
       11.58%  tclsh8.6         libodbc.so.2.0.0                        [.] __validate_stmt
        4.42%  tclsh8.6         libodbc.so.2.0.0                        [.] __check_stmt_from_dbc_v
        2.91%  tclsh8.6         libtcl8.6.so                            [.] TEBCresume
        1.99%  tclsh8.6         libodbc.so.2.0.0                        [.] __set_stmt_state
        1.61%  tclsh8.6         [kernel.kallsyms]                       [k] __pv_queued_spin_lock_slowpath
        1.33%  swapper          [kernel.kallsyms]                       [k] lapic_next_deadline