beyond the
MySQL offerings.
> -Original Message-
> From: walter harms [mailto:wha...@bfs.de]
> Sent: Monday, July 23, 2012 9:31 AM
> To: mysql@lists.mysql.com
> Subject: Re: restrict Connect Time
>
>
>
> Am 23.07.2012 17:38, schrieb Reindl Harald:
> >
> &g
Am 23.07.2012 17:38, schrieb Reindl Harald:
>
>
> Am 23.07.2012 17:35, schrieb walter harms:
>>
>>
>> Am 23.07.2012 16:58, schrieb Ananda Kumar:
>>> so. its more of inactive connections, right.
>>> What do you mean by NEVER LOGOUT
>>>
>>
>> The programms watch certain states in the database,
>>
not very clear. You use connection pooling, right.
If the same session/thread is held for long time, it means the thread is
not getting closed even after doing its job, and adding to execution time.
On Mon, Jul 23, 2012 at 9:05 PM, walter harms wrote:
>
>
> Am 23.07.2012 16:58, schrieb Ananda Ku
Am 23.07.2012 17:35, schrieb walter harms:
>
>
> Am 23.07.2012 16:58, schrieb Ananda Kumar:
>> so. its more of inactive connections, right.
>> What do you mean by NEVER LOGOUT
>>
>
> The programms watch certain states in the database,
> the connect automatic at db startup, disconnecting
> is a
Am 23.07.2012 16:58, schrieb Ananda Kumar:
> so. its more of inactive connections, right.
> What do you mean by NEVER LOGOUT
>
The programms watch certain states in the database,
the connect automatic at db startup, disconnecting
is an error case.
re,
wh
> On Mon, Jul 23, 2012 at 8:17 PM, w
so. its more of inactive connections, right.
What do you mean by NEVER LOGOUT
On Mon, Jul 23, 2012 at 8:17 PM, walter harms wrote:
>
>
> Am 23.07.2012 16:37, schrieb Ananda Kumar:
> > why dont u setup a staging env, which is very much similar to your
> > production and tune all long running sql
Am 23.07.2012 16:37, schrieb Ananda Kumar:
> why dont u setup a staging env, which is very much similar to your
> production and tune all long running sql
>
They are tuned and they are fast :) but the never logout and therefore
the time get accumulated.
re,
wh
> On Mon, Jul 23, 2012 at 8:02
why dont u setup a staging env, which is very much similar to your
production and tune all long running sql
On Mon, Jul 23, 2012 at 8:02 PM, walter harms wrote:
>
>
> Am 23.07.2012 16:10, schrieb Ananda Kumar:
> > you can check the slow query log, this will give you all the sql's which
> > are t
Am 23.07.2012 16:10, schrieb Ananda Kumar:
> you can check the slow query log, this will give you all the sql's which
> are taking more time to execute
>
Yes but you will see the results only when the query is finished.
my first idea was to use something like this:
select * from information_sch
you can check the slow query log, this will give you all the sql's which
are taking more time to execute
On Mon, Jul 23, 2012 at 7:38 PM, walter harms wrote:
>
>
> Am 23.07.2012 15:47, schrieb Ananda Kumar:
> > you can set this is in application server.
> > You can also set this parameter in my.
Am 23.07.2012 15:47, schrieb Ananda Kumar:
> you can set this is in application server.
> You can also set this parameter in my.cnf
> wait_timeout=120 in seconds.
> But the above parameter is only for inactive session
>
acutualy i want to catch scripts running wild.
re,
wh
>
> On Mon, Jul
you can set this is in application server.
You can also set this parameter in my.cnf
wait_timeout=120 in seconds.
But the above parameter is only for inactive session
On Mon, Jul 23, 2012 at 6:18 PM, walter harms wrote:
> Hi list,
> is there a switch where i can restrict the connect/execution t
12 matches
Mail list logo
