|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Доброго времени суток!
Заранее прошу прощения, что вопросы не по непосредственно mysql, а по особенностям его API.
Нахожусь в процессе написания утилиты, которая раз в несколько минут в отдельном потоке создаёт соединение с mysql,
выполняет запрос и отсоединяется (дескриптор соединения создаётся и уничтожается на стеке функции потока), т. е. "пересечений"
между дескрипторами соединения с mysql нету.
Linux, использую posix threads, собираю с -lmysql_client_r, mysql_thread_safe честно возвращает единицу.
Подключение проходит куда менее на ура, чем если делать в однопоточном режиме - хотя бы то, что блокирующий mysql_real_connect часто не срабатывает
(т.е. возвращает NULL), при этом
mysql_error: Can't connect to MySQL server on 'xxx.xxx.xxx.xxx' (4)
mysql_errno: 2003 (CR_CONN_HOST_ERROR)
errno: 4
perror 4: OS error code 4: Interrupted system call
Это вроде объяснимо тем, что pthreads работает через сигналы, при этом не ставя SA_RESTART.
1) Поделитесь плиз, у кого есть соображения - почему mysql_real_connect иногда возвращает NULL, при этом:
mysql_error: Lost connection to MySQL server at 'reading authorization packet, system error: 0'
mysql_errno: 2013 (CR_SERVER_LOST)
errno: 0
- это все при том, что mysql сервер работает, не падает и при следующей попытке подключение успешно происходит?
Это лишь в дополнительных потоках, когда произвожу соединение из основного потока все идет четко и ничего не прерывается.
В однопоточном режиме таких сложностей как-то не возникало, во-всяком случае мне не попадались, даже если ставил обработчики на некоторые сигналы.
2) Вызовы mysql_options (с параметрами MYSQL_OPT_LOCAL_INFILE и MYSQL_OPT_CONNECT_TIMEOUT) могут длится несколько секунд
(опять же в отличие от однопоточного режима) - за счет чего?
3) После успешной установки соединения делаю запрос load data local infile. Иногда mysql_query возвращает "nonzero", при этом
mysql_error: Lost connection to MySQL server during query
mysql_errno: 2013 (CR_SERVER_LOST)
errno: 0
Судя по данным в базе, запрос успешно выполнился. Но функция mysql_query возвращает признак ошибки.
Собственно вопрос: на что можно сориентироваться в такой ситуации?
В какую сторону нужно интерпретировать потерянное соединение в течении выполнения запроса?
Неактивен
А сетевых лагов нету? Можете свести дело к какому-нибудь простому
testcase (грубо говоря, 100 потоков, которые параллельно подсоединяются,
делают SELECT 1, отцепляются, и пишут ошибку, если таковая есть)?
Неактивен
Что касается тест-кейза, то оно на самом деле примерно так и получается - дело в том, что я запускаю одновременно 25 экземпляров такой программки (каждая из которых работает со своей базе на одном и том же mysql-сервере), и в час Ч и минуту М все они создают дополнительные потоки, в которых и производится попытка соединения.
Разница в том (по сравнению с предложенным Вами тесткейзом), что у меня каждый процесс создает один поток, а не как Вы написали - один процесс создаёт 100 потоков. Уточните пожалуйста, насколько это приниципиально.
Дело, как мне кажется, не в сети по следующей причине: предыдущая версия этой программы была однопоточной и соединение с mysql производилось в основном и единственном потоке. Точно также 25 процессов стартовало (единовременно), все они тут же соединялись с одним и тем же mysql-сервером. И не было таких проблем ни разу. И сейчас опять-таки: в основном потоке установка mysql-options, соединение, выполнение запроса и отсоединение происходили без всяких "фокусов", которые я выше описал.
Неактивен
Ээээ... я хотел схитрить и заставить Вас написать простой кусок кода, который бы
я скомпилировал и сказал бы, что у меня бага не проявляется 
Напишу тогда попозже сам.
Неактивен
Уже пишу :-). Просто хотел уточнить немного.
Неактивен
Вот нечто, отвечающее условию :-). Работает без сбоев, но уж больно простой запрос. Та программка, в которой у меня проблемы - там запрос load data local infile, который прогружает файлы, которые весят несколько десятков мегабайт
Отредактированно deadka (29.07.2010 18:48:06)
Неактивен
Похоже, саппорт MySQL так и не признает, что это баг, а не фича :-).
Но предложенный солюшен ( увеличить net_read_timeout/net_write_timeout ) помог.
Подробности здесь: http://bugs.mysql.com/bug.php?id=55673
Прошу Гуру прокомментировать, если есть соображения.
Неактивен
Да, про таймауты я как-то не подумал. Оказывается, Света бывает молодец 
Я, наверное, предвзято отношусь к FreeBSD, но поставьте все-таки MySQL не
из портов, чтобы не ловить левые баги из-за их сборки Это не лечение теку-
щей проблемы, а превентивная мера против других наведенных ошибок.
Неактивен
paulus написал:
Да, про таймауты я как-то не подумал. Оказывается, Света бывает молодец
А то ж )). Вот, в частности, ее материалы http://sql-error.microbecal.com.
paulus написал:
Я, наверное, предвзято отношусь к FreeBSD, но поставьте все-таки MySQL не
из портов, чтобы не ловить левые баги из-за их сборки
щей проблемы, а превентивная мера против других наведенных ошибок.
Да, я планирую пересобрать из исходников, спасибо за совет.
Что же касается лечения текущей проблемы, то я так понимаю, что проблема здесь в том, что иногда управление приходит в тот поток который инициировал и ждёт выполнения sql-запроса уже после истечения интервала net_write_timeout (ведь здесь не select, а именно модифицирующий запрос), а сервер после благополучного выполнения запроса не получает от клиента ответа (потому что не пришло еще управление в поток, который создал подключение к mysql), думает, что с клиентом что-то не так и возвращает ошибку. А запрос-то уже выполнился благополучно...
Поправьте меня, если ошибаюсь, пожалуйста.
Неактивен
Нет, просто операция передачи данных по сети таймаутится. Посмотрите
на загруженность сетевого интерфейса. Он может быть сильно забит в этот
момент.
Неактивен
Страниц: 1
