EmergencyEMERGENCY? Get 24/7 Help Now!

MySQL net_write_timeout vs wait_timeout and protocol notes

 | July 8, 2007 |  Posted In: Insight for DBAs

PREVIOUS POST
NEXT POST

In my previous post I mentioned you might need to increase net_write_timeout to avoid connection being aborted and now I think I should have better explained that.

MySQL uses a lot of different timeout variables at different stages. For example when connection is just being established connect_timeout is used. When server waits for another query to be sent to it wait_timeout
(or interactive_timeout for applications which specified they are interactive during connection). This value is rather large as it is rather typical for some applications to have long delays between queries.

If query is being read or result set is being sent back, much shorter net_read_timeout and net_write_timeout are used.

net_read_timeout rarely becomes the problem unless you have extremely poor network, but when you’re in trouble anyway, because in most cases query is generated and sent as single packet to the server and application can’t switch doing something else and leaving server with partial query received.

Result set however comes back in multiple pieces and if you’re using mysql_use_result you can do any work between fetches, which potentially could take a lot of time, so increasing net_write_timeout could be the good idea.

This for example typical cause of aborted connections while using Sphinx with large data sets and large buffers. While indexing Sphinx performs sorts and flushes buffers to the disk every so often which can take long enough to trigger default net_write_timeout on the server side.

You could ask why server does not do any flow control and can’t find out client just is just busy and it is not network issue – well this comes from simplicity of MySQL protocol which does not allow client to talk to the server until full result set is fetched. This is also the reason why you can’t stop fetching for ordinary statements and mysql_free_result will have to complete the fetch internally.

Is there any way to tell the server you need more time besides increasing net_write_timeout ? Not what I know of. You can’t use something like mysql_ping because connection is in the stage of getting the data. You can’t even fetch couple of rows every few seconds to show you’re fetching data because there is buffering happening inside MySQL client library so you never know when real network read will happen.

As net_write_timeout and net_read_timeout are session level variables you can simply change them per connections for connections which could have timeout issues otherwise without affecting the rest of the server, so it seems like fine solution.

PREVIOUS POST
NEXT POST
Peter Zaitsev

Peter managed the High Performance Group within MySQL until 2006, when he founded Percona. Peter has a Master's Degree in Computer Science and is an expert in database kernels, computer hardware, and application scaling.

3 Comments

  • [KFSMI-3178] labor scrubber fails on mysql…

    last night i made two changes in reg and this error did not occur…
    – upped connections from 25 to 50 (mostly because server was crashing yesterday because we were running out – first in reg/mysql then in cnv/oracle
    – upped connection timeout from ….

  • I used to run mysqlump on huge databases through network. At times I had ended up in the below error

    mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table table_2 at row: 10364

    Should be due to network issues, but increasing “net_write_timeout” had solved above said issue.

Leave a Reply

 
 

Percona’s widely read Percona Data Performance blog highlights our expertise in enterprise-class software, support, consulting and managed services solutions for both MySQL® and MongoDB® across traditional and cloud-based platforms. The decades of experience represented by our consultants is found daily in numerous and relevant blog posts.

Besides specific database help, the blog also provides notices on upcoming events and webinars.
Want to get weekly updates listing the latest blog posts? Subscribe to our blog now! Submit your email address below and we’ll send you an update every Friday at 1pm ET.

No, thank you. Please do not ask me again.