[unixODBC-support] Contention problem

Reza Taheri rtaheri at vmware.com
Fri Apr 7 17:24:46 BST 2017


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/20170407/4667324a/attachment.html>


More information about the unixODBC-support mailing list