Re: Aborted clients

2012-06-13 Thread Johan De Meersman

- Original Message -
 From: Claudio Nanni claudio.na...@gmail.com
 
 @Johan, you say I'm having trouble with clients aborting, but for
 some reason they don't get logged.

Ah, it *did* start logging, now, and they come from multiple applications, too.

120612 12:19:09 [Warning] Aborted connection 13019149 to db: 'music' user: 
'music' host: 'viaprod1' (Got an error reading communication packets)
120612 13:13:52 [Warning] Aborted connection 13020111 to db: 'epg' user: 'epg' 
host: 'viaprod1' (Got timeout reading communication packets)
120612 14:21:10 [Warning] Aborted connection 13021624 to db: 'music' user: 
'music' host: 'viaprod1' (Got an error reading communication packets)

Am I wrong in thinking this looks more like a hardware/network problem?


-- 
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql



Re: Aborted clients

2012-06-13 Thread Claudio Nanni
2012/6/13 Johan De Meersman vegiv...@tuxera.be


 - Original Message -
  From: Claudio Nanni claudio.na...@gmail.com
 
  @Johan, you say I'm having trouble with clients aborting, but for
  some reason they don't get logged.

 Ah, it *did* start logging, now, and they come from multiple applications,
 too.

 120612 12:19:09 [Warning] Aborted connection 13019149 to db: 'music' user:
 'music' host: 'viaprod1' (Got an error reading communication packets)
 120612 13:13:52 [Warning] Aborted connection 13020111 to db: 'epg' user:
 'epg' host: 'viaprod1' (Got timeout reading communication packets)
 120612 14:21:10 [Warning] Aborted connection 13021624 to db: 'music' user:
 'music' host: 'viaprod1' (Got an error reading communication packets)

 Am I wrong in thinking this looks more like a hardware/network problem?



Not at all.
Just to close completely the code 'option', are you sure the codebase is
completely different? since they still come from the same host.
In this way so we can totally exclude code 'bad' habit.

Then network can be a problem for sure, usually when there are firewalls in
between,
also when I had similar problems a network change took place, like changing
switches or some configuration.

Can you count the hops between MySQL and the app server?

Dank Je Wel ;)

Claudio






 --
 Bier met grenadyn
 Is als mosterd by den wyn
 Sy die't drinkt, is eene kwezel
 Hy die't drinkt, is ras een ezel




-- 
Claudio


Re: Aborted clients

2012-06-13 Thread Ananda Kumar
is iptables service running on db server, if yes, trying stopping it and
check

On Wed, Jun 13, 2012 at 5:04 PM, Claudio Nanni claudio.na...@gmail.comwrote:

 2012/6/13 Johan De Meersman vegiv...@tuxera.be

 
  - Original Message -
   From: Claudio Nanni claudio.na...@gmail.com
  
   @Johan, you say I'm having trouble with clients aborting, but for
   some reason they don't get logged.
 
  Ah, it *did* start logging, now, and they come from multiple
 applications,
  too.
 
  120612 12:19:09 [Warning] Aborted connection 13019149 to db: 'music'
 user:
  'music' host: 'viaprod1' (Got an error reading communication packets)
  120612 13:13:52 [Warning] Aborted connection 13020111 to db: 'epg' user:
  'epg' host: 'viaprod1' (Got timeout reading communication packets)
  120612 14:21:10 [Warning] Aborted connection 13021624 to db: 'music'
 user:
  'music' host: 'viaprod1' (Got an error reading communication packets)
 
  Am I wrong in thinking this looks more like a hardware/network problem?
 
 
 
 Not at all.
 Just to close completely the code 'option', are you sure the codebase is
 completely different? since they still come from the same host.
 In this way so we can totally exclude code 'bad' habit.

 Then network can be a problem for sure, usually when there are firewalls in
 between,
 also when I had similar problems a network change took place, like changing
 switches or some configuration.

 Can you count the hops between MySQL and the app server?

 Dank Je Wel ;)

 Claudio






  --
  Bier met grenadyn
  Is als mosterd by den wyn
  Sy die't drinkt, is eene kwezel
  Hy die't drinkt, is ras een ezel
 



 --
 Claudio



Re: Aborted clients

2012-06-13 Thread Johan De Meersman
- Original Message -

 From: Claudio Nanni claudio.na...@gmail.com

Sigh. Because the application gets unstable when the connection falters, the 
Unix boys have a kill-and-restart script in place - so any number of the 
messages in the log may be due to that. Don't you love these complex 
environments :-) 

/me is off to correlate MySQL and killscript logs. Thank Darwin's beard for NTP 
synchronisation. 

-- 

Bier met grenadyn 
Is als mosterd by den wyn 
Sy die't drinkt, is eene kwezel 
Hy die't drinkt, is ras een ezel 


Aborted clients

2012-06-12 Thread Johan De Meersman
Yo, 

I'm having trouble with clients aborting, but for some reason they don't get 
logged. 

The documentation at http://preview.tinyurl.com/27w9a4x clearly states If a 
client successfully connects but later disconnects improperly or is terminated, 
the server increments the Aborted_clients status variable, and logs an Aborted 
connection message to the error log. 

The log_warnings variable has been set; originally to 1 and later to 2 because 
another bit of the doc says  If the value is greater than 1, aborted 
connections are written to the error log. 

The error.log I'm looking at is the one that is currently opened by the MySQL 
daemon, as shown by lsof - and does have entries about non-replication-safe 
queries I'd been doing several days ago. 

And, yet, I see the Aborted_clients counter increase, but never find any 
entries in the errorlog - which is annoying, because now I don't even know 
which application is misbehaving. 

This is MySQL 5.1.50-community-log on Suse 11.1 64-bit. 

Does anyone have an idea why the aborted clients don't get logged, and how to 
fix it? 

thx, 
Johan 

-- 

Bier met grenadyn 
Is als mosterd by den wyn 
Sy die't drinkt, is eene kwezel 
Hy die't drinkt, is ras een ezel 


Re: Aborted clients

2012-06-12 Thread Claudio Nanni
Johan,

Print out warnings such as Aborted connection... to the error log.
the dots are not telling if they comprise Aborted clients as well.
I find the MySQL error log extremely poor, as far as I know it is one of
the MySQL features (like authentication) stuck to the dawn of MySQL times.
Very hard to debug non basic things like your issue.
From what I have experienced usually Aborted connection  means wrong
credentials while Aborted clients means the client (typically PHP) did not
close the connection properly.
Do you have any chance to check if the code is closing the connections to
the mysql database?

Cheers

Claudio

2012/6/12 Johan De Meersman vegiv...@tuxera.be

 Yo,

 I'm having trouble with clients aborting, but for some reason they don't
 get logged.

 The documentation at http://preview.tinyurl.com/27w9a4x clearly states
 If a client successfully connects but later disconnects improperly or is
 terminated, the server increments the Aborted_clients status variable, and
 logs an Aborted connection message to the error log.

 The log_warnings variable has been set; originally to 1 and later to 2
 because another bit of the doc says  If the value is greater than 1,
 aborted connections are written to the error log.

 The error.log I'm looking at is the one that is currently opened by the
 MySQL daemon, as shown by lsof - and does have entries about
 non-replication-safe queries I'd been doing several days ago.

 And, yet, I see the Aborted_clients counter increase, but never find any
 entries in the errorlog - which is annoying, because now I don't even know
 which application is misbehaving.

 This is MySQL 5.1.50-community-log on Suse 11.1 64-bit.

 Does anyone have an idea why the aborted clients don't get logged, and how
 to fix it?

 thx,
 Johan

 --

 Bier met grenadyn
 Is als mosterd by den wyn
 Sy die't drinkt, is eene kwezel
 Hy die't drinkt, is ras een ezel




-- 
Claudio


Re: Aborted clients

2012-06-12 Thread Ananda Kumar
is there anything you can see in /var/log/messages

On Tue, Jun 12, 2012 at 5:08 PM, Claudio Nanni claudio.na...@gmail.comwrote:

 Johan,

 Print out warnings such as Aborted connection... to the error log.
 the dots are not telling if they comprise Aborted clients as well.
 I find the MySQL error log extremely poor, as far as I know it is one of
 the MySQL features (like authentication) stuck to the dawn of MySQL times.
 Very hard to debug non basic things like your issue.
 From what I have experienced usually Aborted connection  means wrong
 credentials while Aborted clients means the client (typically PHP) did not
 close the connection properly.
 Do you have any chance to check if the code is closing the connections to
 the mysql database?

 Cheers

 Claudio

 2012/6/12 Johan De Meersman vegiv...@tuxera.be

  Yo,
 
  I'm having trouble with clients aborting, but for some reason they don't
  get logged.
 
  The documentation at http://preview.tinyurl.com/27w9a4x clearly states
  If a client successfully connects but later disconnects improperly or is
  terminated, the server increments the Aborted_clients status variable,
 and
  logs an Aborted connection message to the error log.
 
  The log_warnings variable has been set; originally to 1 and later to 2
  because another bit of the doc says  If the value is greater than 1,
  aborted connections are written to the error log.
 
  The error.log I'm looking at is the one that is currently opened by the
  MySQL daemon, as shown by lsof - and does have entries about
  non-replication-safe queries I'd been doing several days ago.
 
  And, yet, I see the Aborted_clients counter increase, but never find any
  entries in the errorlog - which is annoying, because now I don't even
 know
  which application is misbehaving.
 
  This is MySQL 5.1.50-community-log on Suse 11.1 64-bit.
 
  Does anyone have an idea why the aborted clients don't get logged, and
 how
  to fix it?
 
  thx,
  Johan
 
  --
 
  Bier met grenadyn
  Is als mosterd by den wyn
  Sy die't drinkt, is eene kwezel
  Hy die't drinkt, is ras een ezel
 



 --
 Claudio



Re: Aborted clients

2012-06-12 Thread Ananda Kumar
or you can check application logs to see why the client lost connectivity
from the app

On Tue, Jun 12, 2012 at 5:12 PM, Ananda Kumar anan...@gmail.com wrote:

 is there anything you can see in /var/log/messages


 On Tue, Jun 12, 2012 at 5:08 PM, Claudio Nanni claudio.na...@gmail.comwrote:

 Johan,

 Print out warnings such as Aborted connection... to the error log.
 the dots are not telling if they comprise Aborted clients as well.
 I find the MySQL error log extremely poor, as far as I know it is one of
 the MySQL features (like authentication) stuck to the dawn of MySQL times.
 Very hard to debug non basic things like your issue.
 From what I have experienced usually Aborted connection  means wrong
 credentials while Aborted clients means the client (typically PHP) did not
 close the connection properly.
 Do you have any chance to check if the code is closing the connections to
 the mysql database?

 Cheers

 Claudio

 2012/6/12 Johan De Meersman vegiv...@tuxera.be

  Yo,
 
  I'm having trouble with clients aborting, but for some reason they don't
  get logged.
 
  The documentation at http://preview.tinyurl.com/27w9a4x clearly states
  If a client successfully connects but later disconnects improperly or
 is
  terminated, the server increments the Aborted_clients status variable,
 and
  logs an Aborted connection message to the error log.
 
  The log_warnings variable has been set; originally to 1 and later to 2
  because another bit of the doc says  If the value is greater than 1,
  aborted connections are written to the error log.
 
  The error.log I'm looking at is the one that is currently opened by the
  MySQL daemon, as shown by lsof - and does have entries about
  non-replication-safe queries I'd been doing several days ago.
 
  And, yet, I see the Aborted_clients counter increase, but never find any
  entries in the errorlog - which is annoying, because now I don't even
 know
  which application is misbehaving.
 
  This is MySQL 5.1.50-community-log on Suse 11.1 64-bit.
 
  Does anyone have an idea why the aborted clients don't get logged, and
 how
  to fix it?
 
  thx,
  Johan
 
  --
 
  Bier met grenadyn
  Is als mosterd by den wyn
  Sy die't drinkt, is eene kwezel
  Hy die't drinkt, is ras een ezel
 



 --
 Claudio





Re: Aborted clients

2012-06-12 Thread Johan De Meersman
- Original Message -

 From: Claudio Nanni claudio.na...@gmail.com
  Print out warnings such as Aborted connection... to the error log.
 the dots are not telling if they comprise Aborted clients as well.
Hah, how's that for selective blindness. Totally missed that :-) 

 I find the MySQL error log extremely poor, as far as I know it is one
 of the MySQL features (like authentication) stuck to the dawn of
 MySQL times.
 Very hard to debug non basic things like your issue.
 From what I have experienced usually Aborted connection means wrong
 credentials while Aborted clients means the client (typically PHP)
 did not close the connection properly.
Yep, that's it; but indeed, since aborted clients aren't logged, then, I seem 
to be in a ditch. 

 Do you have any chance to check if the code is closing the
 connections to the mysql database?
Oh, yes, millions upon billions of lines of wonderfully obscure Java 
stacktraces that reveal little more than Lost connection to database for 
every couple of thousand lines. 

Everything works fine most of the time, then randomly some queries will get 
slow, and eventually the connections will drop. Rinse and repeat. 

Oh well. Thanks for pointing out my reading error, I'm off to lart the devs 
into profiling their code to figure out *what* causes the slowness. Guess I'll 
have to set up some tcpdumps, too. 

-- 

Bier met grenadyn 
Is als mosterd by den wyn 
Sy die't drinkt, is eene kwezel 
Hy die't drinkt, is ras een ezel 


Re: Aborted clients

2012-06-12 Thread Johan De Meersman
No logging happens to /var/log/syslog|messages - I prefer and enable mysql's 
own errorlog. The app logs are pretty much useless due to Java. Guess I'll just 
have to badger the developers into profiling and at the same time set up 
tcpdump schedules to analyze what happens on the wire. 

For all I know it could just as well be an intermittently faulty network 
device. Should be another interesting little war against the computers. 

- Original Message -

 From: Ananda Kumar anan...@gmail.com
 To: Claudio Nanni claudio.na...@gmail.com
 Cc: Johan De Meersman vegiv...@tuxera.be, mysql
 mysql@lists.mysql.com
 Sent: Tuesday, 12 June, 2012 1:43:03 PM
 Subject: Re: Aborted clients

 or you can check application logs to see why the client lost
 connectivity from the app

 On Tue, Jun 12, 2012 at 5:12 PM, Ananda Kumar  anan...@gmail.com 
 wrote:

-- 

Bier met grenadyn 
Is als mosterd by den wyn 
Sy die't drinkt, is eene kwezel 
Hy die't drinkt, is ras een ezel 


Re: Aborted clients

2012-06-12 Thread Howard Hart

On 06/12/2012 05:10 AM, Johan De Meersman wrote:

- Original Message -


From: Claudio Nanniclaudio.na...@gmail.com
 Print out warnings such as Aborted connection... to the error log.
the dots are not telling if they comprise Aborted clients as well.

Hah, how's that for selective blindness. Totally missed that :-)


I find the MySQL error log extremely poor, as far as I know it is one
of the MySQL features (like authentication) stuck to the dawn of
MySQL times.
Very hard to debug non basic things like your issue.
 From what I have experienced usually Aborted connection means wrong
credentials while Aborted clients means the client (typically PHP)
did not close the connection properly.

Yep, that's it; but indeed, since aborted clients aren't logged, then, I seem 
to be in a ditch.


Do you have any chance to check if the code is closing the
connections to the mysql database?

Oh, yes, millions upon billions of lines of wonderfully obscure Java stacktraces that 
reveal little more than Lost connection to database for every couple of 
thousand lines.

Everything works fine most of the time, then randomly some queries will get 
slow, and eventually the connections will drop. Rinse and repeat.

Oh well. Thanks for pointing out my reading error, I'm off to lart the devs 
into profiling their code to figure out *what* causes the slowness. Guess I'll 
have to set up some tcpdumps, too.

Watch out for this one, especially if the Aborted connections are all 
getting charged against a single client. Per the URL below and a 
misbehaving application not closing connections correctly, I've seen 
this spontaneously blacklist a client IP. Only way to unblacklist after 
is to run flush-hosts on the mysql server.


Also, didn't see a one-to-one correspondence between the global  
max_connect_errors setting and Aborted_connects (from show global status 
like '%abort%';), so hard to tell when you're approaching the per client 
blacklist limit.


http://dev.mysql.com/doc/refman/5.0/en/blocked-host.html

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql



Re: Aborted clients

2012-06-12 Thread Claudio Nanni
Howard,

a client can be blacklisted, but in that case is   Aborted connection  to
be increased since the connection request is refused upfront.

@Johan, you say I'm having trouble with clients aborting, but for some
reason they don't get logged.

could you please tell which exactly is the problem?

1) Aborted clients counter gets increased
2) Increasing Aborted clients has a measurable impact on the application
3) ...

Thanks

Claudio

2012/6/12 Howard Hart h...@ooma.com

 On 06/12/2012 05:10 AM, Johan De Meersman wrote:

  - Original Message -

  From: Claudio Nanniclaudio.na...@gmail.com**
  Print out warnings such as Aborted connection... to the error log.
 the dots are not telling if they comprise Aborted clients as well.

 Hah, how's that for selective blindness. Totally missed that :-)

  I find the MySQL error log extremely poor, as far as I know it is one
 of the MySQL features (like authentication) stuck to the dawn of
 MySQL times.
 Very hard to debug non basic things like your issue.
  From what I have experienced usually Aborted connection means wrong
 credentials while Aborted clients means the client (typically PHP)
 did not close the connection properly.

 Yep, that's it; but indeed, since aborted clients aren't logged, then, I
 seem to be in a ditch.

  Do you have any chance to check if the code is closing the
 connections to the mysql database?

 Oh, yes, millions upon billions of lines of wonderfully obscure Java
 stacktraces that reveal little more than Lost connection to database for
 every couple of thousand lines.

 Everything works fine most of the time, then randomly some queries will
 get slow, and eventually the connections will drop. Rinse and repeat.

 Oh well. Thanks for pointing out my reading error, I'm off to lart the
 devs into profiling their code to figure out *what* causes the slowness.
 Guess I'll have to set up some tcpdumps, too.

  Watch out for this one, especially if the Aborted connections are all
 getting charged against a single client. Per the URL below and a
 misbehaving application not closing connections correctly, I've seen this
 spontaneously blacklist a client IP. Only way to unblacklist after is to
 run flush-hosts on the mysql server.

 Also, didn't see a one-to-one correspondence between the global
  max_connect_errors setting and Aborted_connects (from show global status
 like '%abort%';), so hard to tell when you're approaching the per client
 blacklist limit.

 http://dev.mysql.com/doc/**refman/5.0/en/blocked-host.**htmlhttp://dev.mysql.com/doc/refman/5.0/en/blocked-host.html

 --
 MySQL General Mailing List
 For list archives: http://lists.mysql.com/mysql
 To unsubscribe:http://lists.mysql.com/mysql




-- 
Claudio


Re: Aborted clients status variable seems increasing -how to tune the server to reduce the same

2006-06-19 Thread Brent Baisley
Like I said, 5 seconds I thought was kind of low, but there may be a reason for it set that low. I would need to know more about how 
your application works to make a guess on a good setting. If your application is long running or spawns lots of threads, it may be 
that the timeout was set low to reduce the number of connections. Perhaps due to poor coding, just a possibility.


Generally, persistant connections were designed for when creating a connection to a database is expensive. Like having to go 
outside your own network. Generally, it is suggested to NOT use persistent connections. Although I recall when I first learned 
PHP/MySQL I read that I should. I never use persistent connections anymore.
There is a whole bunch of issues with using persistent connections if you are interacting with various databases in the same script 
or using transactions, which you probably are not. If you are using PHP read this:

http://us2.php.net/manual/en/features.persistent-connections.php

You can actually switch persistent connections for regular connections without a problem. Again, unless there is a good reason 
persistent connections are used. If you can give a brief overview of how you app works, perhaps I can make some guesses on what's 
going on and how it's working. Also the full results of show variables and show status would be helpful.


- Original Message - 
From: Lakshmi [EMAIL PROTECTED]

To: Brent Baisley [EMAIL PROTECTED]
Cc: mysql@lists.mysql.com; [EMAIL PROTECTED]
Sent: Friday, June 16, 2006 6:22 AM
Subject: Re: *SPAM* Re: Aborted clients status variable seems 
increasing -how to tune the server to reduce the same



Thanks Brent.

I increased my wait_timeout.But now also my aborted clients seems increasing than connections.As u said most of my front end code 
use mysql persistent connect only.Can u clarify my one more doubt that when to use persistent connect and when to use 
mysql_connect and their advantages and disadvantages.

Now my connections is  1509317 and my aborted clients  is 1747365.Is it a 
problem?Please let me know.

-Lakshmi.M.P.

Brent Baisley wrote:
You have your wait_timeout set to 5 seconds. Which means a client connection will be aborted after 5 seconds of inactivity. Since 
your aborted connects is 0, you don't seem to having a problem connecting, just staying connected. 5 seconds is kind of low 
(default is 28800 I think), but is fine if you have a reason for setting it so low. Your threads_created number is fairly low, so 
you're not having a problem of constantly creating threads to handle connections, which can really hurt.


I don't know what your front end is written in. But you may want to increase the wait_timeout or call mysql_close when you are 
done with your database connection. I'm guessing that since your aborted clients number is higher than the number of connections, 
you're using persistant connections. Which means connections are reused if still available.


- Original Message - From: Lakshmi [EMAIL PROTECTED]
To: mysql@lists.mysql.com
Cc: [EMAIL PROTECTED]
Sent: Thursday, June 15, 2006 3:42 AM
Subject: Aborted clients status variable seems increasing -how to tune the 
server to reduce the same



Hi,
The aborted clients seems to be increasing than the connections made. Any 
solution
Aborted_clients 67529 where as the connection made is 60462 .

Here is my server details,

Server : Red Hat Enterprise Linux AS 
release 4 (Nahant)
Mysql Server version  : 4.1.15-log

*my.cnf  variables:*
key_buffer=350M
max_allowed_packet=32M
table_cache=1024
thread_cache_size=400
sort_buffer=64K
net_buffer_length=64K
read_buffer_size = 64K
thread_stack=96K
query_cache_size=64M
max_connections=1000
max_connect_errors=100
max_user_connections=900
wait_timeout=5
record_buffer=5M
thread_concurrency=8
myisam_sort_buffer_size=64M
set-variable = innodb_buffer_pool_size=200M
set-variable = innodb_additional_mem_pool_size=2M
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50

*Status Variables:
*Aborted_clients 67529
Aborted_connects0
Connections 60462
Key_blocks_unused   275836
Key_blocks_used 42002
Key_read_requests   1836872
Key_reads   42002
Key_write_requests  3704
Key_writes  3701
Max_used_connections205
Open_tables 84
Opened_tables   90
Qcache_free_blocks  4451
Qcache_free_memory  54838840
Qcache_hits 18034
Qcache_inserts  66383
Qcache_lowmem_prunes0
Qcache_not_cached   11320
Qcache_queries_in_cache 11792
Questions   269605
Threads_cached  81
Threads_connected   124
Threads_created 205
Threads_running 4*

-Lakshmi.M.P.
MYSQL DBA,
Sify Limited.

** DISCLAIMER **
Information contained and transmitted by this E-MAIL is proprietary to Sify Limited and is intended for use only by the 
individual or entity to which it is addressed, and may contain information that is privileged, confidential

Re: *****SPAM***** Re: Aborted clients status variable seems increasing -how to tune the server to reduce the same

2006-06-16 Thread Lakshmi

Thanks Brent.

I increased my wait_timeout.But now also my aborted clients seems 
increasing than connections.As u said most of my front end code use 
mysql persistent connect only.Can u clarify my one more doubt that when 
to use persistent connect and when to use mysql_connect and their 
advantages and disadvantages.
Now my connections is  1509317 and my aborted clients  is 1747365.Is it 
a problem?Please let me know.


-Lakshmi.M.P.

Brent Baisley wrote:
You have your wait_timeout set to 5 seconds. Which means a client 
connection will be aborted after 5 seconds of inactivity. Since your 
aborted connects is 0, you don't seem to having a problem connecting, 
just staying connected. 5 seconds is kind of low (default is 28800 I 
think), but is fine if you have a reason for setting it so low. Your 
threads_created number is fairly low, so you're not having a problem 
of constantly creating threads to handle connections, which can really 
hurt.


I don't know what your front end is written in. But you may want to 
increase the wait_timeout or call mysql_close when you are done with 
your database connection. I'm guessing that since your aborted clients 
number is higher than the number of connections, you're using 
persistant connections. Which means connections are reused if still 
available.


- Original Message - From: Lakshmi [EMAIL PROTECTED]
To: mysql@lists.mysql.com
Cc: [EMAIL PROTECTED]
Sent: Thursday, June 15, 2006 3:42 AM
Subject: Aborted clients status variable seems increasing -how to tune 
the server to reduce the same




Hi,
The aborted clients seems to be increasing than the connections made. 
Any solution

Aborted_clients 67529 where as the connection made is 60462 .

Here is my server details,

Server : Red Hat Enterprise Linux 
AS release 4 (Nahant)

Mysql Server version  : 4.1.15-log

*my.cnf  variables:*
key_buffer=350M
max_allowed_packet=32M
table_cache=1024
thread_cache_size=400
sort_buffer=64K
net_buffer_length=64K
read_buffer_size = 64K
thread_stack=96K
query_cache_size=64M
max_connections=1000
max_connect_errors=100
max_user_connections=900
wait_timeout=5
record_buffer=5M
thread_concurrency=8
myisam_sort_buffer_size=64M
set-variable = innodb_buffer_pool_size=200M
set-variable = innodb_additional_mem_pool_size=2M
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50

*Status Variables:
*Aborted_clients 67529
Aborted_connects0
Connections 60462
Key_blocks_unused   275836
Key_blocks_used 42002
Key_read_requests   1836872
Key_reads   42002
Key_write_requests  3704
Key_writes  3701
Max_used_connections205
Open_tables 84
Opened_tables   90
Qcache_free_blocks  4451
Qcache_free_memory  54838840
Qcache_hits 18034
Qcache_inserts  66383
Qcache_lowmem_prunes0
Qcache_not_cached   11320
Qcache_queries_in_cache 11792
Questions   269605
Threads_cached  81
Threads_connected   124
Threads_created 205
Threads_running 4*

-Lakshmi.M.P.
MYSQL DBA,
Sify Limited.

** DISCLAIMER **
Information contained and transmitted by this E-MAIL is proprietary 
to Sify Limited and is intended for use only by the individual or 
entity to which it is addressed, and may contain information that is 
privileged, confidential or exempt from disclosure under applicable 
law. If this is a forwarded message, the content of this E-MAIL may 
not have been sent with the authority of the Company. If you are not 
the intended recipient, an agent of the intended recipient or a  
person responsible for delivering the information to the named 
recipient,  you are notified that any use, distribution, 
transmission, printing, copying or dissemination of this information 
in any way or in any manner is strictly prohibited. If you have 
received this communication in error, please delete this mail  
notify us immediately at [EMAIL PROTECTED]


Watch India vs. England LIVE, Hot videos and more only on Sify Max! 
Click Here. www.sifymax.com


Get to see what's happening in your favourite City on Bangalore Live! 
www.bangalorelive.in



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
http://lists.mysql.com/[EMAIL PROTECTED]







--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Aborted clients status variable seems increasing -how to tune the server to reduce the same

2006-06-15 Thread Lakshmi

Hi,
The aborted clients seems to be increasing than the connections made. 
Any solution

Aborted_clients 67529 where as the connection made is 60462 .

Here is my server details,

Server : Red Hat Enterprise Linux AS 
release 4 (Nahant)

Mysql Server version  : 4.1.15-log

*my.cnf  variables:*
key_buffer=350M
max_allowed_packet=32M
table_cache=1024
thread_cache_size=400
sort_buffer=64K
net_buffer_length=64K
read_buffer_size = 64K
thread_stack=96K
query_cache_size=64M
max_connections=1000
max_connect_errors=100
max_user_connections=900
wait_timeout=5
record_buffer=5M
thread_concurrency=8
myisam_sort_buffer_size=64M
set-variable = innodb_buffer_pool_size=200M
set-variable = innodb_additional_mem_pool_size=2M
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50

*Status Variables:
*Aborted_clients 67529
Aborted_connects0
Connections 60462
Key_blocks_unused   275836
Key_blocks_used 42002
Key_read_requests   1836872
Key_reads   42002
Key_write_requests  3704
Key_writes  3701
Max_used_connections205
Open_tables 84
Opened_tables   90
Qcache_free_blocks  4451
Qcache_free_memory  54838840
Qcache_hits 18034
Qcache_inserts  66383
Qcache_lowmem_prunes0
Qcache_not_cached   11320
Qcache_queries_in_cache 11792
Questions   269605
Threads_cached  81
Threads_connected   124
Threads_created 205
Threads_running 4*

-Lakshmi.M.P.
MYSQL DBA,
Sify Limited.

** DISCLAIMER **
Information contained and transmitted by this E-MAIL is proprietary to 
Sify Limited and is intended for use only by the individual or entity to 
which it is addressed, and may contain information that is privileged, 
confidential or exempt from disclosure under applicable law. If this is a 
forwarded message, the content of this E-MAIL may not have been sent with 
the authority of the Company. If you are not the intended recipient, an 
agent of the intended recipient or a  person responsible for delivering the 
information to the named recipient,  you are notified that any use, 
distribution, transmission, printing, copying or dissemination of this 
information in any way or in any manner is strictly prohibited. If you have 
received this communication in error, please delete this mail  notify us 
immediately at [EMAIL PROTECTED]


Watch India vs. England LIVE, Hot videos and more only on Sify Max! Click Here. 
www.sifymax.com

Get to see what's happening in your favourite City on Bangalore Live! 
www.bangalorelive.in


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Aborted clients status variable seems increasing -how to tune the server to reduce the same

2006-06-15 Thread Brent Baisley
You have your wait_timeout set to 5 seconds. Which means a client connection will be aborted after 5 seconds of inactivity. Since 
your aborted connects is 0, you don't seem to having a problem connecting, just staying connected. 5 seconds is kind of low (default 
is 28800 I think), but is fine if you have a reason for setting it so low. Your threads_created number is fairly low, so you're not 
having a problem of constantly creating threads to handle connections, which can really hurt.


I don't know what your front end is written in. But you may want to increase the wait_timeout or call mysql_close when you are done 
with your database connection. I'm guessing that since your aborted clients number is higher than the number of connections, you're 
using persistant connections. Which means connections are reused if still available.


- Original Message - 
From: Lakshmi [EMAIL PROTECTED]

To: mysql@lists.mysql.com
Cc: [EMAIL PROTECTED]
Sent: Thursday, June 15, 2006 3:42 AM
Subject: Aborted clients status variable seems increasing -how to tune the 
server to reduce the same



Hi,
The aborted clients seems to be increasing than the connections made. Any 
solution
Aborted_clients 67529 where as the connection made is 60462 .

Here is my server details,

Server : Red Hat Enterprise Linux AS 
release 4 (Nahant)
Mysql Server version  : 4.1.15-log

*my.cnf  variables:*
key_buffer=350M
max_allowed_packet=32M
table_cache=1024
thread_cache_size=400
sort_buffer=64K
net_buffer_length=64K
read_buffer_size = 64K
thread_stack=96K
query_cache_size=64M
max_connections=1000
max_connect_errors=100
max_user_connections=900
wait_timeout=5
record_buffer=5M
thread_concurrency=8
myisam_sort_buffer_size=64M
set-variable = innodb_buffer_pool_size=200M
set-variable = innodb_additional_mem_pool_size=2M
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50

*Status Variables:
*Aborted_clients 67529
Aborted_connects0
Connections 60462
Key_blocks_unused   275836
Key_blocks_used 42002
Key_read_requests   1836872
Key_reads   42002
Key_write_requests  3704
Key_writes  3701
Max_used_connections205
Open_tables 84
Opened_tables   90
Qcache_free_blocks  4451
Qcache_free_memory  54838840
Qcache_hits 18034
Qcache_inserts  66383
Qcache_lowmem_prunes0
Qcache_not_cached   11320
Qcache_queries_in_cache 11792
Questions   269605
Threads_cached  81
Threads_connected   124
Threads_created 205
Threads_running 4*

-Lakshmi.M.P.
MYSQL DBA,
Sify Limited.

** DISCLAIMER **
Information contained and transmitted by this E-MAIL is proprietary to Sify Limited and is intended for use only by the individual 
or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under 
applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the 
Company. If you are not the intended recipient, an agent of the intended recipient or a  person responsible for delivering the 
information to the named recipient,  you are notified that any use, distribution, transmission, printing, copying or dissemination 
of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please 
delete this mail  notify us immediately at [EMAIL PROTECTED]


Watch India vs. England LIVE, Hot videos and more only on Sify Max! Click Here. 
www.sifymax.com

Get to see what's happening in your favourite City on Bangalore Live! 
www.bangalorelive.in


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]




--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Aborted clients status variable seems increasing -how to tune the server to reduce the same

2006-06-15 Thread Daniel da Veiga

On 6/15/06, Lakshmi [EMAIL PROTECTED] wrote:

Hi,
The aborted clients seems to be increasing than the connections made.
Any solution
Aborted_clients 67529 where as the connection made is 60462 .


A client is aborted after wait_timeout seconds of inactivity, but as
your app seem to be working OK, the aborted_clients is increasing
because you are not closing the connection properly after dealing with
data with that connection. The low number of seconds explains why you
have no trouble at all, because MySQL simply kills that connection
after you use it and leave it there hanging.

Try closing your connections after you've used them in a proper way
(that depends on the language you're using for your frontend) and that
number should not increase anymore.

--
Daniel da Veiga
Computer Operator - RS - Brazil
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V-
PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++
--END GEEK CODE BLOCK--

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Aborted clients

2003-07-25 Thread Jeff McKeon
Ver 3.23 on RH Linux.

We came in this morning and were greeted by our DB server rejecting
connections to the db from our application.  There seems to be a high
number of Aborted_clients.  How can we tell what clients/connections are
causing this?

mysql show status;
+--++
| Variable_name| Value  |
+--++
| Aborted_clients  | 149|
| Aborted_connects | 122|
| Bytes_received   | 422801700  |
| Bytes_sent   | 3604618252 |
| Connections  | 7375   |
| Created_tmp_disk_tables  | 885|
| Created_tmp_tables   | 20331  |
| Created_tmp_files| 509|
| Delayed_insert_threads   | 0  |
| Delayed_writes   | 0  |
| Delayed_errors   | 0  |
| Flush_commands   | 2  |
| Handler_delete   | 5252   |
| Handler_read_first   | 35028  |
| Handler_read_key | 95425837   |
| Handler_read_next| 2978256304 |
| Handler_read_prev| 0  |
| Handler_read_rnd | 7727972|
| Handler_read_rnd_next| 3143081074 |
| Handler_update   | 45487  |
| Handler_write| 2010283|
| Key_blocks_used  | 7793   |
| Key_read_requests| 585802473  |
| Key_reads| 18261  |
| Key_write_requests   | 3740894|
| Key_writes   | 254091 |
| Max_used_connections | 100|
| Not_flushed_key_blocks   | 0  |
| Not_flushed_delayed_rows | 0  |
| Open_tables  | 64 |
| Open_files   | 109|
| Open_streams | 0  |
| Opened_tables| 252|
| Questions| 5171955|
| Select_full_join | 881|
| Select_full_range_join   | 0  |
| Select_range | 22 |
| Select_range_check   | 0  |
| Select_scan  | 280668 |
| Slave_running| ON |
| Slave_open_temp_tables   | 0  |
| Slow_launch_threads  | 0  |
| Slow_queries | 138|
| Sort_merge_passes| 254|
| Sort_range   | 474|
| Sort_rows| 40227394   |
| Sort_scan| 22550  |
| Table_locks_immediate| 5695456|
| Table_locks_waited   | 8278   |
| Threads_cached   | 0  |
| Threads_created  | 7373   |
| Threads_connected| 97 |
| Threads_running  | 2  |
| Uptime   | 317854 |
+--++



Jeff McKeon
IT Manager
Telaurus Communications LLC
[EMAIL PROTECTED]
(973) 889-8990 ex 209 

***The information contained in this communication is confidential. It
is intended only for the sole use of the recipient named above and may
be legally privileged. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this communication, or any of its contents or attachments,
is expressly prohibited. If you have received this communication in
error, please re-send it to the sender and delete the original message,
and any copy of it, from your computer system. Thank You.***


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Aborted clients

2003-07-25 Thread Ken Menzel
Hi Jeff,

The two telling line for your aborted clients are
 *** 39. row ***
 Variable_name: max_connections
 Value: 100
and
   | Max_used_connections | 100|

This means that you hit the limit.
Are saying you don't believe you should have 100 connections? If you
do SHOW PROCESSLIST are they all valid connections?  Do you need more
than 100? Did you perhaps copy an example config file or are you not
using any config file?

Have to run to a meeting now.  Hope this bring some ideas to the
table.
Ken
- Original Message - 
From: Jeff McKeon [EMAIL PROTECTED]
To: Ken Menzel [EMAIL PROTECTED]
Sent: Friday, July 25, 2003 9:54 AM
Subject: RE: Aborted clients


 No, no changes to the max_connections.  What we did discover is that
 although this is a master db and not a slave of any, it was trying
to
 replicate to an unknown server (nothing in the master.info file)
with
 user test.  Nobody here recalls doing anything to set this up...

 FYI Variables

 mysql show variables \G;
 *** 1. row ***
 Variable_name: back_log
 Value: 50
 *** 2. row ***
 Variable_name: basedir
 Value: /usr/local/mysql/
 *** 3. row ***
 Variable_name: binlog_cache_size
 Value: 32768
 *** 4. row ***
 Variable_name: character_set
 Value: latin1
 *** 5. row ***
 Variable_name: character_sets
 Value: latin1 dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7
 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr
greek
 win1250 croat cp1257 latin5
 *** 6. row ***
 Variable_name: concurrent_insert
 Value: ON
 *** 7. row ***
 Variable_name: connect_timeout
 Value: 5
 *** 8. row ***
 Variable_name: datadir
 Value: /home/data/mysql/data/
 *** 9. row ***
 Variable_name: delay_key_write
 Value: ON
 *** 10. row ***
 Variable_name: delayed_insert_limit
 Value: 100
 *** 11. row ***
 Variable_name: delayed_insert_timeout
 Value: 300
 *** 12. row ***
 Variable_name: delayed_queue_size
 Value: 1000
 *** 13. row ***
 Variable_name: flush
 Value: OFF
 *** 14. row ***
 Variable_name: flush_time
 Value: 0
 *** 15. row ***
 Variable_name: have_bdb
 Value: NO
 *** 16. row ***
 Variable_name: have_gemini
 Value: NO
 *** 17. row ***
 Variable_name: have_innodb
 Value: NO
 *** 18. row ***
 Variable_name: have_isam
 Value: YES
 *** 19. row ***
 Variable_name: have_raid
 Value: NO
 *** 20. row ***
 Variable_name: have_ssl
 Value: NO
 *** 21. row ***
 Variable_name: init_file
 Value:
 *** 22. row ***
 Variable_name: interactive_timeout
 Value: 28800
 *** 23. row ***
 Variable_name: join_buffer_size
 Value: 131072
 *** 24. row ***
 Variable_name: key_buffer_size
 Value: 8388600
 *** 25. row ***
 Variable_name: language
 Value: /usr/local/mysql/share/mysql/english/
 *** 26. row ***
 Variable_name: large_files_support
 Value: ON
 *** 27. row ***
 Variable_name: locked_in_memory
 Value: OFF
 *** 28. row ***
 Variable_name: log
 Value: OFF
 *** 29. row ***
 Variable_name: log_update
 Value: OFF
 *** 30. row ***
 Variable_name: log_bin
 Value: ON
 *** 31. row ***
 Variable_name: log_slave_updates
 Value: OFF
 *** 32. row ***
 Variable_name: log_long_queries
 Value: OFF
 *** 33. row

Re: Aborted clients

2003-07-25 Thread Ken Menzel
Hi Jeff,
   Just a quick guess did you change the max_connections variable up
from the default of 100?  You did not provide a show variables so I
can only guess.

From the [mysqld] section of /etc/my.cnf
set-variable= max_connections=500

Ken
- Original Message - 
From: Jeff McKeon [EMAIL PROTECTED]
To: MySQL LIST [EMAIL PROTECTED]
Sent: Friday, July 25, 2003 7:45 AM
Subject: Aborted clients


 Ver 3.23 on RH Linux.

 We came in this morning and were greeted by our DB server rejecting
 connections to the db from our application.  There seems to be a
high
 number of Aborted_clients.  How can we tell what clients/connections
are
 causing this?

 mysql show status;
 +--++
 | Variable_name| Value  |
 +--++
 | Aborted_clients  | 149|
 | Aborted_connects | 122|
 | Bytes_received   | 422801700  |
 | Bytes_sent   | 3604618252 |
 | Connections  | 7375   |
 | Created_tmp_disk_tables  | 885|
 | Created_tmp_tables   | 20331  |
 | Created_tmp_files| 509|
 | Delayed_insert_threads   | 0  |
 | Delayed_writes   | 0  |
 | Delayed_errors   | 0  |
 | Flush_commands   | 2  |
 | Handler_delete   | 5252   |
 | Handler_read_first   | 35028  |
 | Handler_read_key | 95425837   |
 | Handler_read_next| 2978256304 |
 | Handler_read_prev| 0  |
 | Handler_read_rnd | 7727972|
 | Handler_read_rnd_next| 3143081074 |
 | Handler_update   | 45487  |
 | Handler_write| 2010283|
 | Key_blocks_used  | 7793   |
 | Key_read_requests| 585802473  |
 | Key_reads| 18261  |
 | Key_write_requests   | 3740894|
 | Key_writes   | 254091 |
 | Max_used_connections | 100|
 | Not_flushed_key_blocks   | 0  |
 | Not_flushed_delayed_rows | 0  |
 | Open_tables  | 64 |
 | Open_files   | 109|
 | Open_streams | 0  |
 | Opened_tables| 252|
 | Questions| 5171955|
 | Select_full_join | 881|
 | Select_full_range_join   | 0  |
 | Select_range | 22 |
 | Select_range_check   | 0  |
 | Select_scan  | 280668 |
 | Slave_running| ON |
 | Slave_open_temp_tables   | 0  |
 | Slow_launch_threads  | 0  |
 | Slow_queries | 138|
 | Sort_merge_passes| 254|
 | Sort_range   | 474|
 | Sort_rows| 40227394   |
 | Sort_scan| 22550  |
 | Table_locks_immediate| 5695456|
 | Table_locks_waited   | 8278   |
 | Threads_cached   | 0  |
 | Threads_created  | 7373   |
 | Threads_connected| 97 |
 | Threads_running  | 2  |
 | Uptime   | 317854 |
 +--++



 Jeff McKeon
 IT Manager
 Telaurus Communications LLC
 [EMAIL PROTECTED]
 (973) 889-8990 ex 209

 ***The information contained in this communication is confidential.
It
 is intended only for the sole use of the recipient named above and
may
 be legally privileged. If the reader of this message is not the
intended
 recipient, you are hereby notified that any dissemination,
distribution
 or copying of this communication, or any of its contents or
attachments,
 is expressly prohibited. If you have received this communication in
 error, please re-send it to the sender and delete the original
message,
 and any copy of it, from your computer system. Thank You.***


 -- 
 MySQL General Mailing List
 For list archives: http://lists.mysql.com/mysql
 To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]




-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



RE: Aborted clients

2003-07-25 Thread Jeff McKeon
]
(973) 889-8990 ex 209 

***The information contained in this communication is confidential. It
is intended only for the sole use of the recipient named above and may
be legally privileged. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this communication, or any of its contents or attachments,
is expressly prohibited. If you have received this communication in
error, please re-send it to the sender and delete the original message,
and any copy of it, from your computer system. Thank You.***



 -Original Message-
 From: Ken Menzel [mailto:[EMAIL PROTECTED]
 Sent: Friday, July 25, 2003 9:47 AM
 To: Jeff McKeon; MySQL LIST
 Subject: Re: Aborted clients
 
 
 Hi Jeff,
Just a quick guess did you change the max_connections
 variable up from the default of 100?  You did not provide a 
 show variables so I can only guess.
 
 From the [mysqld] section of /etc/my.cnf
 set-variable= max_connections=500
 
 Ken
 - Original Message -
 From: Jeff McKeon [EMAIL PROTECTED]
 To: MySQL LIST [EMAIL PROTECTED]
 Sent: Friday, July 25, 2003 7:45 AM
 Subject: Aborted clients
 
 
  Ver 3.23 on RH Linux.
 
  We came in this morning and were greeted by our DB server rejecting
  connections to the db from our application.  There seems to be a
 high
  number of Aborted_clients.  How can we tell what clients/connections
 are
  causing this?
 
  mysql show status;
  +--++
  | Variable_name| Value  |
  +--++
  | Aborted_clients  | 149|
  | Aborted_connects | 122|
  | Bytes_received   | 422801700  |
  | Bytes_sent   | 3604618252 |
  | Connections  | 7375   |
  | Created_tmp_disk_tables  | 885|
  | Created_tmp_tables   | 20331  |
  | Created_tmp_files| 509|
  | Delayed_insert_threads   | 0  |
  | Delayed_writes   | 0  |
  | Delayed_errors   | 0  |
  | Flush_commands   | 2  |
  | Handler_delete   | 5252   |
  | Handler_read_first   | 35028  |
  | Handler_read_key | 95425837   |
  | Handler_read_next| 2978256304 |
  | Handler_read_prev| 0  |
  | Handler_read_rnd | 7727972|
  | Handler_read_rnd_next| 3143081074 |
  | Handler_update   | 45487  |
  | Handler_write| 2010283|
  | Key_blocks_used  | 7793   |
  | Key_read_requests| 585802473  |
  | Key_reads| 18261  |
  | Key_write_requests   | 3740894|
  | Key_writes   | 254091 |
  | Max_used_connections | 100|
  | Not_flushed_key_blocks   | 0  |
  | Not_flushed_delayed_rows | 0  |
  | Open_tables  | 64 |
  | Open_files   | 109|
  | Open_streams | 0  |
  | Opened_tables| 252|
  | Questions| 5171955|
  | Select_full_join | 881|
  | Select_full_range_join   | 0  |
  | Select_range | 22 |
  | Select_range_check   | 0  |
  | Select_scan  | 280668 |
  | Slave_running| ON |
  | Slave_open_temp_tables   | 0  |
  | Slow_launch_threads  | 0  |
  | Slow_queries | 138|
  | Sort_merge_passes| 254|
  | Sort_range   | 474|
  | Sort_rows| 40227394   |
  | Sort_scan| 22550  |
  | Table_locks_immediate| 5695456|
  | Table_locks_waited   | 8278   |
  | Threads_cached   | 0  |
  | Threads_created  | 7373   |
  | Threads_connected| 97 |
  | Threads_running  | 2  |
  | Uptime   | 317854 |
  +--++
 
 
 
  Jeff McKeon
  IT Manager
  Telaurus Communications LLC
  [EMAIL PROTECTED]
  (973) 889-8990 ex 209
 
  ***The information contained in this communication is confidential.
 It
  is intended only for the sole use of the recipient named above and
 may
  be legally privileged. If the reader of this message is not the
 intended
  recipient, you are hereby notified that any dissemination,
 distribution
  or copying of this communication, or any of its contents or
 attachments,
  is expressly prohibited. If you have received this communication in
  error, please re-send it to the sender and delete the original
 message,
  and any copy of it, from your computer system. Thank You.***
 
 
  --
  MySQL General Mailing List
  For list archives: http://lists.mysql.com/mysql
  To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
 
 
 
 

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL

RE: Aborted clients

2003-07-25 Thread Jeff McKeon
   | 0 | NULL
| show processlist |
+-+--+-+--+-+---+---
--+--+
51 rows in set (0.00 sec)
Jeff McKeon

 -Original Message-
 From: Ken Menzel [mailto:[EMAIL PROTECTED] 
 Sent: Friday, July 25, 2003 10:16 AM
 To: Jeff McKeon
 Cc: [EMAIL PROTECTED]
 Subject: Re: Aborted clients
 
 
 Hi Jeff,
 
 The two telling line for your aborted clients are
  *** 39. row ***
  Variable_name: max_connections
  Value: 100
 and
| Max_used_connections | 100|
 
 This means that you hit the limit.
 Are saying you don't believe you should have 100 connections? 
 If you do SHOW PROCESSLIST are they all valid connections?  
 Do you need more than 100? Did you perhaps copy an example 
 config file or are you not using any config file?
 
 Have to run to a meeting now.  Hope this bring some ideas to 
 the table. Ken
 - Original Message - 
 From: Jeff McKeon [EMAIL PROTECTED]
 To: Ken Menzel [EMAIL PROTECTED]
 Sent: Friday, July 25, 2003 9:54 AM
 Subject: RE: Aborted clients
 
 
  No, no changes to the max_connections.  What we did 
 discover is that 
  although this is a master db and not a slave of any, it was trying
 to
  replicate to an unknown server (nothing in the master.info file)
 with
  user test.  Nobody here recalls doing anything to set this up...
 
  FYI Variables
 
  mysql show variables \G;
  *** 1. row ***
  Variable_name: back_log
  Value: 50
  *** 2. row ***
  Variable_name: basedir
  Value: /usr/local/mysql/
  *** 3. row ***
  Variable_name: binlog_cache_size
  Value: 32768
  *** 4. row ***
  Variable_name: character_set
  Value: latin1
  *** 5. row ***
  Variable_name: character_sets
  Value: latin1 dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 
  cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr
 greek
  win1250 croat cp1257 latin5
  *** 6. row ***
  Variable_name: concurrent_insert
  Value: ON
  *** 7. row ***
  Variable_name: connect_timeout
  Value: 5
  *** 8. row ***
  Variable_name: datadir
  Value: /home/data/mysql/data/
  *** 9. row ***
  Variable_name: delay_key_write
  Value: ON
  *** 10. row ***
  Variable_name: delayed_insert_limit
  Value: 100
  *** 11. row ***
  Variable_name: delayed_insert_timeout
  Value: 300
  *** 12. row ***
  Variable_name: delayed_queue_size
  Value: 1000
  *** 13. row ***
  Variable_name: flush
  Value: OFF
  *** 14. row ***
  Variable_name: flush_time
  Value: 0
  *** 15. row ***
  Variable_name: have_bdb
  Value: NO
  *** 16. row ***
  Variable_name: have_gemini
  Value: NO
  *** 17. row ***
  Variable_name: have_innodb
  Value: NO
  *** 18. row ***
  Variable_name: have_isam
  Value: YES
  *** 19. row ***
  Variable_name: have_raid
  Value: NO
  *** 20. row ***
  Variable_name: have_ssl
  Value: NO
  *** 21. row ***
  Variable_name: init_file
  Value:
  *** 22. row ***
  Variable_name: interactive_timeout
  Value: 28800
  *** 23. row ***
  Variable_name: join_buffer_size
  Value: 131072
  *** 24. row ***
  Variable_name: key_buffer_size
  Value: 8388600
  *** 25. row ***
  Variable_name: language
  Value: /usr/local/mysql/share/mysql/english/
  *** 26. row ***
  Variable_name: large_files_support
  Value: ON
  *** 27. row ***
  Variable_name: locked_in_memory
  Value: OFF
  *** 28. row ***
  Variable_name: log
  Value: OFF

Aborted clients, aborted connects

2003-01-14 Thread Stefan Hinz
Dear all,

can someone explain this phenomenon (I connect to mysqld-max-nt in
another DOS box, then close the window without issuing 'quit'; MySQL
4.0.7 with InnoDB tables on Win2K SP2):

mysql SHOW STATUS LIKE 'Aborted%';
+--+---+
| Variable_name| Value |
+--+---+
| Aborted_clients  | 1 |
| Aborted_connects | 548   | ---
+--+---+
2 rows in set (0.00 sec)

mysql SHOW STATUS LIKE 'Aborted%';
+--+---+
| Variable_name| Value |
+--+---+
| Aborted_clients  | 2 |
| Aborted_connects | 551   | ---
+--+---+
2 rows in set (0.00 sec)

mysql SHOW STATUS LIKE 'Aborted%';
+--+---+
| Variable_name| Value |
+--+---+
| Aborted_clients  | 3 |
| Aborted_connects | 554   | ---
+--+---+
2 rows in set (0.01 sec)

Why is Aborted_connects incremented at all? And why is it incremented by
3?

sql,mysql for the filters

Regards,
--
  Stefan Hinz [EMAIL PROTECTED]
  Geschäftsführer / CEO iConnect GmbH http://iConnect.de
  Heesestr. 6, 12169 Berlin (Germany)
  Tel: +49 30 7970948-0  Fax: +49 30 7970948-3



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




What is `Aborted Clients` ?

2002-04-29 Thread João Paulo Vasconcellos

Hello Everybody,

  can anyone explain me what is an Aborted Client ? I begin to wonder about 
this because this number was about 20 or 30 last week, and now suddenly it 
got above 200 ! I have no idea of what it means, so any help would be 
appreciated.


Filter : sql

-- 
João Paulo Vasconcellos
Gerente de Tecnologia - NetCard
Tel. 21 3852-9008 Ramal 31
[EMAIL PROTECTED]


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: What is `Aborted Clients` ?

2002-04-29 Thread Paul DuBois

Hello Everybody,

   can anyone explain me what is an Aborted Client ? I begin to wonder about
this because this number was about 20 or 30 last week, and now suddenly it
got above 200 ! I have no idea of what it means, so any help would be
appreciated.

The number of connections closed by the server after the client failed
to properly close the connection from its end.  This is in the manual
under SHOW STATUS.



Filter : sql

--
João Paulo Vasconcellos
Gerente de Tecnologia - NetCard
Tel. 21 3852-9008 Ramal 31
[EMAIL PROTECTED]

-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: What is `Aborted Clients` ?

2002-04-29 Thread Jeremy Zawodny

On Mon, Apr 29, 2002 at 02:52:16PM -0300, João Paulo Vasconcellos wrote:
 Hello Everybody,
 
   can anyone explain me what is an Aborted Client ? I begin to
 wonder about this because this number was about 20 or 30 last week,
 and now suddenly it got above 200 ! I have no idea of what it means,
 so any help would be appreciated.

I believe that's the message generated when a client disconnects
abnormally.
-- 
Jeremy D. Zawodny, [EMAIL PROTECTED]
Technical Yahoo - Yahoo Finance
Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936

MySQL 3.23.47-max: up 81 days, processed 2,094,002,365 queries (298/sec. avg)

-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: What is `Aborted Clients` ?

2002-04-29 Thread webmaster

Hi


Can anyone explain me what is an Aborted Client ? I begin to wonder about
this because this number was about 20 or 30 last week, and now suddenly it
got above 200 ! I have no idea of what it means, so any help would be
appreciated.


This is incremented if one of the following has happened:

The client program did not call mysql_close() before exit.
The client had been sleeping more than wait_timeout or interactive_timeout
without doing any requests.
The client program ended abruptly in the middle of the transfer.



Peter Kelly
http://www.TrafficG.com





- Original Message -
From: Jeremy Zawodny [EMAIL PROTECTED]
To: João Paulo Vasconcellos [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, April 29, 2002 7:31 PM
Subject: Re: What is `Aborted Clients` ?


 On Mon, Apr 29, 2002 at 02:52:16PM -0300, João Paulo Vasconcellos wrote:
  Hello Everybody,
 
can anyone explain me what is an Aborted Client ? I begin to
  wonder about this because this number was about 20 or 30 last week,
  and now suddenly it got above 200 ! I have no idea of what it means,
  so any help would be appreciated.

 I believe that's the message generated when a client disconnects
 abnormally.
 --
 Jeremy D. Zawodny, [EMAIL PROTECTED]
 Technical Yahoo - Yahoo Finance
 Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936

 MySQL 3.23.47-max: up 81 days, processed 2,094,002,365 queries (298/sec.
avg)

 -
 Before posting, please check:
http://www.mysql.com/manual.php   (the manual)
http://lists.mysql.com/   (the list archive)

 To request this thread, e-mail [EMAIL PROTECTED]
 To unsubscribe, e-mail
[EMAIL PROTECTED]
 Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php






-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Re: What is `Aborted Clients` ?

2002-04-29 Thread João Paulo Vasconcellos

Thanks everybody.



 Filter : sql

-- 
João Paulo Vasconcellos
Gerente de Tecnologia - NetCard
Tel. 21 3852-9008 Ramal 31
[EMAIL PROTECTED]

-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Advice about 'many aborted clients'

2001-05-18 Thread Sander Dekker

Hello,
 
we're using mysql 3.23.33 on a separate Linux server, but about 50% of all
connections go wrong and get an error like this: Aborted connection 84620
to db: 'xxx' user: 'yyy' host: `aaa.bbb.cc.ddd.' (Got timeout reading
communication packets). There are 3 frontends (Sun) webservers. We're
making about 15 connections per second. Has anybody any tips about the
configuration and give advice about how to prevent those errors. 
 
Sander.
 
my.cnf parameters: 
 
[client]
port= 3306
socket  = /tmp/mysql.sock
 
# The MySQL server
[mysqld]
port= 3306
socket  = /tmp/mysql.sock
skip-locking
set-variable= key_buffer=256M
set-variable= max_connections=255
set-variable= max_allowed_packet=1M
set-variable= table_cache=256
set-variable= sort_buffer=1M
set-variable= record_buffer=1M
set-variable= myisam_sort_buffer_size=64M
set-variable= thread_cache=16
set-variable= thread_concurrency=8
log-bin
server-id   = 1
 
set-variable= interactive_timeout=60
set-variable= wait_timeout=60
set-variable= connect_timeout=10
 
[mysqldump]
quick
set-variable= max_allowed_packet=16M
 
[mysql]
no-auto-rehash

[isamchk]
set-variable= key_buffer=128M
set-variable= sort_buffer=128M
set-variable= read_buffer=2M
set-variable= write_buffer=2M
 
[myisamchk]
set-variable= key_buffer=128M
set-variable= sort_buffer=128M
set-variable= read_buffer=2M
set-variable= write_buffer=2M
 
[mysqlhotcopy]
interactive-timeout