web-dev-qa-db-ja.com

straceはmysqlソケットからの読み取りに長い時間を示しています-mysqlはクエリの実行に長い時間がかかりますか？

私のApacheサーバーはリクエストの処理に長い時間がかかります。 straceを添付すると、次の2つの遅延が見られます。

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を見つけて、タイムアウトの原因を突き止めようとしました。説明されている手法を使用しました ここ が、問題の記述子を示した手法はありませんでした。タイムアウトがどこから来ているのかを知るにはどうすればよいですか？

linuxapache-2.2mysqlstracefile-descriptors
6
Maxim Koretskyi

問題は解決されました。 information_schemaMySQLデータベースのPROCESSLISTテーブルを調べたところ、一部のテーブルが状態Waiting for table level lockでロックされていることがわかりました。そこで検索したところ、ロックの理由の1つはmysqldumpバックアップである可能性があることがわかりました。これは、最近構成したものとまったく同じです。しかし、ジョブが正しく構成されていなかったため、毎分実行され、MySQLが常にロックされていました。バックアップが正しく構成されたので、サーバーは正常に動作します。

それでも、pollに関する2番目の質問は未解決のままです。

2
Maxim Koretskyi