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_connects 0
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_connections 205
Open_tables 84
Opened_tables 90
Qcache_free_blocks 4451
Qcache_free_memory 54838840
Qcache_hits 18034
Qcache_inserts 66383
Qcache_lowmem_prunes 0
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]
