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]
