MySQLプロセスリストの統計状態

Question

busy MySQL Serverクエリあり

SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=592885621) FOR UPDATE

どこ pqr_sess_idはPrimary Keyテーブル内。

クエリを個別に実行すると、0.00 secs,ですが、クエリがハングしていることが何度も観察されていますstatisticsのプロセスリストです。

問題となる可能性があるのは、このクエリのカウントが遅いログで10K回を超えていることです。

mysql> show full processlist; +------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 2899 | root | 192.168.9.217:49340 | abdulrony | Query | 58 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=592885621) FOR UPDATE | | 2977 | root | 192.168.9.217:35082 | abdulrony | Query | 30 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=593059341) FOR UPDATE | | 3010 | root | 192.168.9.217:44607 | abdulrony | Query | 3 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=595647701) FOR UPDATE | | 3011 | root | 192.168.9.217:44287 | abdulrony | Query | 33 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=593503321) FOR UPDATE | | 3014 | root | 192.168.9.217:49280 | abdulrony | Query | 3 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=595641601) FOR UPDATE | | 3016 | root | 192.168.9.217:60243 | abdulrony | Query | 51 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=592248641) FOR UPDATE | | 3033 | root | 192.168.9.217:49695 | abdulrony | Query | 22 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=594780861) FOR UPDATE | | 3034 | root | 192.168.9.217:44473 | abdulrony | Query | 27 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=594503601) FOR UPDATE | | 3038 | root | 192.168.9.217:55093 | abdulrony | Query | 1 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=595625241) FOR UPDATE | +------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 22 rows in set (0.00 sec)

チューニングできることはわかっていますoptimizer_search_depthいくつかの低い値に設定することによってデフォルト値は以下のとおりですが、クエリに単一のテーブルが関与しているため、役に立たないと思います。

SHOW variables like 'optimizer_search_depth'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | optimizer_search_depth | 62 | +------------------------+-------+ 1 row in set (0.00 sec)

Mahesh Patil · Answer

クエリtheadがstatisticsの間長く留まる場合は、サーバーがおそらくディスクにバインドされており、他の作業を実行していることを示しています。

ディスクバインドを減らす方法：

1）innodb_buffer_pool_sizeのサイズを増やします

Innodbテーブルを使用している場合、テーブルデータがInnoDBバッファープールにキャッシュされると、ディスクI/Oを必要とせずに、クエリによって繰り返し処理できます。 innodb_buffer_pool_sizeオプションでバッファプールのサイズを指定します。このメモリ領域は非常に重要であり、ビジー状態のデータベースでは物理メモリ量の約80％のサイズが指定されることがよくあります。

2）GNU/LinuxおよびUnixの一部のバージョンでは、Unixのfsync（）呼び出し（デフォルトではInnoDBが使用）および類似のメソッドを使用してファイルをディスクにフラッシュすると、驚くほど遅くなります。データベースの書き込みパフォーマンスが問題になる場合は、innodb_flush_methodパラメーターをO_DSYNCに設定してベンチマークを実施します。

3）innodb_log_buffer_sizeのサイズを増やします-InnoDBの先行書き込みログエントリを格納するバッファに割り当てるメモリの量を設定します。大規模なトランザクションの場合、トランザクションコミットごとにログバッファがフラッシュされるまで、ディスク上のログファイルにログを書き込む代わりに、ログをログバッファにロードできます。実行時にshow innodb statusの出力に大きなログI/Oが表示される場合は、おそらく、ディスクI/Oを節約するためにinnodb_log_buffer_sizeパラメータに大きな値を設定する必要があります。

4）テーブルとクエリのキャッシュに使用するメモリを増やします-それらのキャッシュヒット率を確認しますこれらのMySQL変数を確認して増やします：query_cache_size、query_cache_limit、query_cache_min_res_unit、tmp_table_size、join_buffer_size、sort_buffer_sizeなど.

5）サーバー上のすべてのテーブルに適切なインデックスが適用されていることを確認し、適切なデータ型を使用します。

これらのリンクを参照して、ディスクにバインドされた問題を解決できます： http://dev.mysql.com/doc/refman/5.5/en/disk-issues.html https：// blogs.Oracle.com/luojiach/entry/mysql_innodb_performance_tuning_for