Задавайте вопросы, мы ответим
Вы не зашли.
На довольно нагруженом запросами серваке, но и довольно мощном: 4 * Intel Xeon CPU 3.06GHz; 8Gb оперативы
MySQL 5.0.45, CentOS 5.0, клиенты это php скрипты, MySQL стоит на отдельном серваке, клиенты к нему по локалке подключаются, локалка 150 Мбит.
это стата за 19 дней работы (с max_connections = 512 в конфиге, сейчас max_connections = 1024)
Соединения ø в час %
Максимально одновременных 513 --- ---
Неудачных попыток 8,566 18.69 0.14%
Прерваны 2,866 6.25 0.05%
Всего 5,947 k 12.98 k 100.00%
имеют место такие ошибки, они появляются както случайно можно перезагружать страницу одну и туже по многу раз и ошибка редко, но появляется, также она может появится на любой другой странице
error #2013: Lost connection to MySQL server at 'reading authorization packet', system error: 0
или
error #2013: Lost connection to MySQL server at 'reading final connect information', system error: 0
По логам видно, что обрывы случаются когда коннект не происходит в основном в течение 10 сек,
но бывает что обрыв случается от 5 до 9 сек и от 11 до 15, но гораздо реже.
Что бы было понятнее код для коннекта и фиксирования времени такой примерно
$querytime_before = array_sum(explode(' ', microtime()));
$conn = mysql_connect($CONN['_HOST'], $CONN['_USER'], $CONN['_PASSWORD']);
if (!$conn) {
$querytime_after = array_sum(explode(' ', microtime()));
$query_time = $querytime_after - $querytime_before;
return check_mysql_error($conn, 'Cannot connect to the database'.$query_time);
}
В мускуле
connect_timeout = 5
wait_timeout = 28800
interactive_timeout = 28800
В пхп не знаю может это влияет
default_socket_timeout = 60
При всем при этом LA на серваке не большой от 1 до 3 не больше, CPU используется даже не на 50%, память свободная имеется.
Вопросы такие, в какой лимит упирается система?
по сути это должен быть connect_timeout, но почему тогда есть 10 секундные задержки?
Почему соединение не происходит так долго в чем проблема может быть и как с этим справиться?
Спасибо
Отредактированно denisimus (08.06.2009 18:13:50)
Неактивен
--skip-name-resolve включали?
Неактивен
нет не включали, а это имеет значение если в $CONN['_HOST'] всегда ИП используется?
поробую
Отредактированно denisimus (08.06.2009 19:53:31)
Неактивен
Важны обратные проверки, именно они могут тормозить со стороны DNS.
Ну и пробуйте использовать persistent connections
Неактивен
--skip-name-resolve запустил с этой опцией. пока наблюдаю
а по поводу persistent connections, я знаю про них, но не использовал
если есть опыт, то какая плата за их использование?
Неактивен
10 копеек за соединение
Они просто висят в памяти и используются по мере возможности. Меньше переподключений —
быстрее работа. В самой памяти места практически не занимают.
Неактивен