Nils: thank you so much for the response. Below are results related to '%time%' from the db giving 2013 error:
mysql> SHOW VARIABLES LIKE '%time%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | connect_timeout | 30 | | delayed_insert_timeout | 300 | | flush_time | 0 | | innodb_lock_wait_timeout | 50 | | interactive_timeout | 28800 | | long_query_time | 10 | | net_read_timeout | 30 | | net_write_timeout | 60 | | slave_net_timeout | 3600 | | slow_launch_time | 2 | | timezone | EDT | | wait_timeout | 28800 | +--------------------------+-------+ just this morning we replaced the switch sitting between our application boxes and the db boxes hoping that it may resolve the issue, but we are still getting random 2013 errors. If it's any help, the majority of the queries which seem to fail with a 2013 are pretty small, a simple select from a single table with less than 100 entries. As it happens this is the first query of many from a series of scripts which get accessed quite a bit. We get pretty steady traffic throughout the day and the 2013's seem fairly constant throughout all application boxes, not every query by any means though. I'm pretty much shooting in the dark now, but hoping that maybe there are some tracer bullets around which can help to rectify this. Thanks again, Kevin -----Original Message----- From: Nils Valentin [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 8:34 PM To: Kevin A. Miller; [EMAIL PROTECTED] Subject: Re: MySQL Errno: 2013 Hi Kevin, Error 2013 means lost connection during query So, as you said the workload of the server is not so high - and I take your word for it -I would like to go once more to the timeout variables. You said that you changed wait timeout, but I believe you missed the important one ( just a guess o.k:-) How about : ?? connect_timeout interactive_timeout net_read_timeout net_write_timeout slave_net_timeout Try this SHOW VARIABLES LIKE '%time%'; and let me know if this was of any help. Best regards Nils Valentin Tokyo/Japan 2003年 5月 30日 金曜日 01:54、Kevin A. Miller さんは書きました: > I am reposting this in hopes that somebody out there has at least a > suggestion or hint as where to look. Everything I've tried so far (mainly > small setting changes) seems to prevent numerous 2013 errors. > > help me mysql kenobi, you're my only hope. > > Kevin > > -----Original Message----- > From: Kevin A. Miller [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 27, 2003 3:18 PM > To: [EMAIL PROTECTED] > Subject: MySQL Errno: 2013 > > > In our production environment, we are receiving sporadic but constant 2013 > errors from one of our mysql dbs. > > The production environment consists of 5 servers running RH 6.2/apache > 1.3.27/php 4.0.6, load balanced with a foundry server iron. Each app box > queries a central db box, using pconnect, (rh 8.0/mysql 4.0.12) primarily > for reads (roughly 80% of a script's db transactions) and another db box > for writes (rh 6.2/mysql 4.0.12). > > Logic is in place to log any mysql errors on each app box from either mysql > server. Over the past month, well pretty much since logging was enabled, > the 'read' server returns quite a few 2013 errors. We log the 'suspect' > query and the queries are valid. Not every query results in an error, but > enough where we get up to 50 an hour from every box. During peak times we > average around 500 qps. The db server in question is pretty robust and > hardly ever carries a load above 1.0. We are using a pretty standard 'huge' > version of my.conf, except for the following changed lines: > skip-innodb > skip-name-resolve > set-variable=thread_stack=256k > > set-variable=wait_timeout=60 > set-variable=thread_cache_size=40 > > From scanning previous posts related to errno 2013, we have adjusted > 'thread_stack' to above value as well as the 'wait_timeout'. Nothing so far > seems to correct the problem. There seems to be no rhyme or reason as to > what causes the errors, many scripts are executed during the day. In fact > nobody in our office has even experienced the error first-hand, but logs > indicate that it does occur and quite frequently > > Thanks in advance. > > Kevin A. Miller > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- ================================================ Valentin Nils Internet Technology E-Mail: [EMAIL PROTECTED] URL: http://www.knowd.co.jp/staff/nils ------------------------------------------------ 有限会社ナレッジデザイン 〒182-0024 東京都調布市布田4-6-1 調布丸善ビル7F Phone: 0424-40-7912 Fax: 0424-40-7913 URL: http://www.knowd.co.jp ================================================ -- 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]
