[unixODBC-support] Contention problem

Reza Taheri rtaheri at vmware.com
Sat Apr 8 03:28:37 BST 2017


We do make a separate call to SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &m_env); and also SQLAllocHandle(SQL_HANDLE_DBC, m_env, &m_dbc); for every thread.  FWIW, we always get 19289 for m_env, and 19290 for m_dbc.  This is even the case when I spread the threads over 5 processes (and get 3X the throughput)

I built with -enable-driver-conf=yes --enable-fastvalidate=yes. It got maybe 10% faster.


From: unixodbc-support-bounces at mailman.unixodbc.org [mailto:unixodbc-support-bounces at mailman.unixodbc.org] On Behalf Of Koenig, Michael
Sent: Friday, April 7, 2017 9:31 AM
To: Support for the unixODBC project <unixodbc-support at mailman.unixodbc.org>
Subject: Re: [unixODBC-support] Contention problem

Hi!

I think he means separate calls to SQLAllocHandle(SQL_HANDLE_ENV, …) (see https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlallochandle-function)<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.microsoft.com_en-2Dus_sql_odbc_reference_syntax_sqlallochandle-2Dfunction-29&d=DwMGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=9_6t06Ke_8Hdt4VRm3Ji_4eVoZ6RMB31woYRzwQ8Yj8&m=QE94P1rGud7zlrKivkugJjuPUXzVlji_Ow4xdlcgiT4&s=yCVoNcwIoF_ia6P4K8Ga5M50mNaD_pw8oFHeqvVzLqg&e=>

Cheers

Michael

From: <unixodbc-support-bounces at mailman.unixodbc.org<mailto:unixodbc-support-bounces at mailman.unixodbc.org>> on behalf of Reza Taheri <rtaheri at vmware.com<mailto:rtaheri at vmware.com>>
Reply-To: Support for the unixODBC project <unixodbc-support at mailman.unixodbc.org<mailto:unixodbc-support at mailman.unixodbc.org>>
Date: Friday, 7. April 2017 at 18:24
To: Support for the unixODBC project <unixodbc-support at mailman.unixodbc.org<mailto:unixodbc-support at mailman.unixodbc.org>>
Subject: Re: [unixODBC-support] Contention problem

On 4/7/17, 8:01 AM, "unixodbc-support-bounces at mailman.unixodbc.org<mailto:unixodbc-support-bounces at mailman.unixodbc.org> on behalf of Nick Gorham" <unixodbc-support-bounces at mailman.unixodbc.org<mailto:unixodbc-support-bounces at mailman.unixodbc.org> on behalf of nick at lurcher.org<mailto:nick at lurcher.org>> wrote:

On 07/04/17 15:57, Reza Taheri wrote:
On 4/7/17, 7:31 AM, Nick Gorham" <unixodbc-support-bounces at mailman.unixodbc.org<mailto:unixodbc-support-bounces at mailman.unixodbc.org> on behalf of nick at lurcher.org<mailto:nick at lurcher.org>> wrote:

Probably worth asking the folk who wrote that driver. Are the threads sharing a connection handle? if they are I would expect that the socket that points to would be a limiting factor and expect it to all become serialised behind that.

If you have a single connection and lots of statements, you could make the handle validation quicker by configuring with --enable-fastvalidate

  1.95%  libodbc.so.2.0.0                 [.] __validate_stmt


OK, I’ll try --enable-fastvalidate. If by driver you mean the PGSQL ODBC driver psqlodbcw.so, boy chasing the PGSQL folks in not the quick fix I was hoping for ☺. FWIW, if I am running with 80 threads of execution in the benchmark driver, I have 80 threads on the client, and there are 80 new postgres processes on the server. So I didn’t expect any sharing of connection data structures, but clearly something is being shared

Thanks,
Reza

Out of interest, try a separate env handle for each thread as well.

--
Nick

Just to make sure: do you mean a separate Data Source Name label?

Thanks,
Reza



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-support/attachments/20170408/54b4b290/attachment.html>


More information about the unixODBC-support mailing list