strace показывает долгое время чтения из сокета mysql - mysql занимает много времени для выполнения запроса?
Мой сервер Apache занимает много времени для обработки запроса. Я прикрепил к нему strace и вижу две следующие задержки:
1) Очень критично (143 секунды для обработки)
1335 0.000037 write(16, "\235\0\0\0\3INSERT INTO `br_anonymous_user_tokens` (`dtExpires`, `nmToken`, `dtCreated`) VALUES ('2014-08-25', '46e35dc39a41e836b806f48d21621b066ea182a9', '2014-06-25')", 161) = 161
1335 0.000111 read(16, "\t\0\0\1\0\1\374\262\n\2\0\0\0", 16384) = 13
1335 143.588134 gettimeofday({1403675497, 653337}, NULL) = 0
Файловый дескриптор #16 выглядит как сокет mysql:
line from strace
1335 0.000328 socket(PF_LOCAL, SOCK_STREAM, 0) = 16
И здесь
pidof mysqld
15393
lsof -p 15393
mysqld 15393 mysql 12u IPv4 26913133 0t0 TCP *:mysql (LISTEN)
Таким образом, похоже, что Apache ожидает mysql для выполнения запроса, который был записан в сокет в предыдущей строке. Я прав? Значит ли это, что мне нужно понять, почему MySQL так долго выполняет простой запрос?
2) очень долго
1335 0.000040 poll([{fd=14, events=POLLIN}], 1, 5000) = 0 (Timeout)
1335 5.005295 gettimeofday({1403675502, 686212}, NULL) = 0
Здесь я попытался найти файловый дескриптор #14, чтобы выяснить, откуда истекает время ожидания. Я использовал методы, описанные здесь, но ни один из них не показал рассматриваемый дескриптор. Как я могу узнать, откуда берется тайм-аут?
1 ответ
Проблема решена. Я посмотрел через PROCESSLIST стол в information_schema MySQL базы данных и обнаружил, что некоторые таблицы заблокированы с состоянием Waiting for table level lock, Затем я искал и обнаружил, что одной из причин блокировки могут быть резервные копии mysqldump - и это именно то, что я недавно настроил. Но поскольку задание было неправильно настроено, оно выполнялось каждую минуту, постоянно блокируя MySQL. Теперь, когда резервные копии настроены правильно, сервер работает нормально.
И все же второй вопрос с poll остается нерешенным.