Мой сервер 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, чтобы узнать, откуда исходит тайм-аут. Я использовал описанные техники Вот, но ни один из них не показал рассматриваемый дескриптор. Как узнать, откуда исходит таймаут?
Проблема решена. Я просмотрел PROCESSLIST стол в information_schema База данных MySQL и обнаружила, что некоторые таблицы заблокированы с состоянием Waiting for table level lock. Затем я поискал и обнаружил, что одной из причин блокировки может быть резервное копирование mysqldump - и это именно то, что я недавно настроил. Но поскольку задание было неправильно сконфигурировано, оно выполнялось каждую минуту, постоянно блокируя MySQL. Теперь, когда резервное копирование настроено правильно, сервер работает нормально.
Но второй вопрос с poll остается нерешенным.