RE: MySQL Errno: 2013
Nils: sorry for the delay getting back to you. this morning we modified the variables mentioned below. Following are current 'time' related values . . . +--+---+ | Variable_name| Value | +--+---+ | connect_timeout | 30| | delayed_insert_timeout | 300 | | flush_time | 0 | | innodb_lock_wait_timeout | 50| | interactive_timeout | 28800 | | long_query_time | 30| | net_read_timeout | 60| | net_write_timeout| 60| | slave_net_timeout| 3600 | | slow_launch_time | 2 | | timezone | EDT | | wait_timeout | 28800 | +--+---+ unfortunately we are still seeing these evil 2013 errors across all application boxes. the errors still appear to be very random. we are in the process of a much needed upgrade of php. any chance that upgrading php will alleviate the problems? Thanks again for your time. Cheers, Kevin -Original Message- From: Nils Valentin [mailto:[EMAIL PROTECTED] Sent: Sunday, June 01, 2003 9:55 AM To: Kevin A. Miller; [EMAIL PROTECTED] Subject: Re: MySQL Errno: 2013 Hi Kevin, I dont think its the switch. I would like to try the following variables: net_read_timeout 60 net_write_timeout 60 long_query_time 30 Please let me know if this was of any help. Best regards NIls Valentin Tokyo/Japan 2003 5 30 23:33Kevin A. Miller : 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:54Kevin 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
Re: MySQL Errno: 2013
Hi Kevin, thats alright, let me know when it worked, thats what I want to hear ;-) Best regards Nils Valentin 2003 6 5 00:12Kevin A. Miller : Nils: sorry for the delay getting back to you. this morning we modified the variables mentioned below. Following are current 'time' related values . . . +--+---+ | Variable_name| Value | +--+---+ | connect_timeout | 30| | delayed_insert_timeout | 300 | | flush_time | 0 | | innodb_lock_wait_timeout | 50| | interactive_timeout | 28800 | | long_query_time | 30| | net_read_timeout | 60| | net_write_timeout| 60| | slave_net_timeout| 3600 | | slow_launch_time | 2 | | timezone | EDT | | wait_timeout | 28800 | +--+---+ unfortunately we are still seeing these evil 2013 errors across all application boxes. the errors still appear to be very random. we are in the process of a much needed upgrade of php. any chance that upgrading php will alleviate the problems? Thanks again for your time. Cheers, Kevin -Original Message- From: Nils Valentin [mailto:[EMAIL PROTECTED] Sent: Sunday, June 01, 2003 9:55 AM To: Kevin A. Miller; [EMAIL PROTECTED] Subject: Re: MySQL Errno: 2013 Hi Kevin, I dont think its the switch. I would like to try the following variables: net_read_timeout 60 net_write_timeout 60 long_query_time 30 Please let me know if this was of any help. Best regards NIls Valentin Tokyo/Japan 2003 5 30 23:33Kevin A. Miller : 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:54Kevin 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
Re: MySQL Errno: 2013
Hi Kevin, I dont think its the switch. I would like to try the following variables: net_read_timeout 60 net_write_timeout 60 long_query_time 30 Please let me know if this was of any help. Best regards NIls Valentin Tokyo/Japan 2003 5 30 23:33Kevin A. Miller : 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:54Kevin 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
RE: MySQL Errno: 2013
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:54Kevin 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
RE: MySQL Errno: 2013
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] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
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:54Kevin 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 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]
