Skip to Content.
Sympa Menu

freetds - Re: [freetds] FreeTDS on Core 2 Duo problem

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Medvidek Pu <Pu.Medvidek AT seznam.cz>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] FreeTDS on Core 2 Duo problem
  • Date: Mon, 19 Feb 2007 10:37:15 +0100 (CET)


> ------------ Původní zpráva ------------
> Od: James K. Lowden <jklowden AT freetds.org>
> Předmět: Re: [freetds] FreeTDS on Core 2 Duo problem
> Datum: 16.2.2007 15:08:26
> ----------------------------------------
> ZIGLIO, Frediano, VF-IT wrote:
> > Perhaps it can be a problem related to server configuration. There is an
> > autoclose flag that force server to close a single database when there
> > are no activity on db. Perhaps executing queries from 2 console keeps
> > database open while executing from a single console keeps opening and
> > closing database.
>
> Whether you are waiting for the server or a bottleneck in the client might
> be made clear by logging. The fields printed to a TDSDUMP log are
> controlled by the debug flags in freetds.conf; 0x2000 turns on the time.
> I think that would help verify/disprove Frediano's theory.
>
> HTH.
>
> --jkl

Thank you for your hints. The issue is that it does not matter to which
database the sql-test script connects when running the two simultaneous
sql-test scripts. If the first sql-test script connects to db A and the
second sql-test script connects to db B, the effect is the same as if they
both connected to the same db. Here, A and B run on the same server.
Unfortunately, it is not easy for me to test two different servers. But I
think this could be helpful, so I'll try to make it.

I've tested the dumps and here is the result. The connect is fast, the use
command is fast, the query is slow. You can see the part of the dump in the
following listing. It shows the 5s time between sending the query and
receiving header. Let me remind you that 0.1s is reasonable for this query.
it is this time that keeps growing longer and longer with subsequent queries
sometimes dropping to reasonable time but then again raising.

09:10:19.987646 ct_send() succeeded
09:10:19.987670 ct_results()
09:10:24.259829 Received header

Can it be related to some locking/releasing?

Thanks to all of you again

Pu




Archive powered by MHonArc 2.6.24.

Top of Page