[unixODBC-support] Contention problem

Reza Taheri rtaheri at vmware.com
Tue Apr 11 19:28:08 BST 2017


On 4/9/17, 9:32 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 09/04/17 15:59, Reza Taheri wrote:
Sorry Nick, I don’t know what that means. Can you please spell out what I need to do?

Its not always possible or easy, but move the libodbc.so that your app is linked to to a different name, and copy the driver lib to libodbc.so so the app calls the driver directly without the driver manager in the way.

May not work, but is one way of seeing where the bottleneck is.

--
Nick

I have narrowed the degradation down to accesses to the stmt returned by SQLAllocHandle(SQL_HANDLE_STMT, ,). If I avoid calling SQLBindCol(stmt, ), SQLFetch(stmt, ), etc., then performance with a single process and multiple threads approaches performance when I run each thread of execution in a separate process. Each thread has its own private copy of “stmt”, its own connection to the database, etc. But we still have contention

FWIW, the actual execution of queries is not serialized. I can see many transactions in flight on the postgres backend. The contention appears to be for accesses to data structures. Also, SQLBindCol(stmt, ), SQLFetch(stmt, ), etc are fast with a small number of threads, or when we run them in different processes

It seems to me that your original suggestion of using different handles would have avoided all this. But it looks like the driver insists on giving me the same environment/connection/statement handles for all the threads in a process

Thanks,
Reza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-support/attachments/20170411/4db02235/attachment.html>


More information about the unixODBC-support mailing list