The "queue_stats()" function, introduced in Q4M 0.9.7

gistfile1.txt

How it looks like
==================================

mysql> select queue_stats('t');
+------------------------------------------------------------------------------------------------------------------------------+
| queue_stats('t')                                                                                                             |
+------------------------------------------------------------------------------------------------------------------------------+
| rows_written: 0
rows_removed: 0
wait_immediate: 0
wait_delayed: 0
wait_timeout: 0
restored_by_abort: 0
restored_by_close: 0
 |
+------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)


Description of the Variables
==================================

rows_written: 0       -- 書込行数
rows_removed: 0       -- 削除行数
wait_immediate: 0     -- queue_wait() が呼ばれた際に、キューに滞留していた行を返した回数
wait_delayed: 0       -- queue_wait() が呼ばれた際に、キューが空で、待機中に届いた行を返した回数
wait_timeout: 0       -- queue_wait() が呼ばれた際に、キューが空で、行を返さないままタイムアウトした回数
restored_by_abort: 0  -- queue_abort() が呼ばれた結果として、キューにデータが戻された回数
restored_by_close: 0  -- queue_wait() / queue_end() が呼ばれないままデータベース接続が切断された結果として、キューにデータが戻された回数

全ての値は mysqld 起動後の、テーブル単位の累計になります。

以下のような値を定期的に取得して、前回取得時との差分を監視するといいかも：
- rows_removed - rows_written: SELECT COUNT(*) と同等
- wait_immediate の差分 / (wait_immediate + wait_delayed + wait_timeout) の差分: キューにデータが滞留している比率が分かる。これが増加し始めるとワーカー増設を考えるべき
- restored_by_close: この値が前回取得時と変化するようなら、ネットワークに問題があって TCP 接続が切れているか、ワーカーが queue_end() か queue_wait() を呼ばないまま、異常終了していないか確認すべき


FAQ
==================================

Q. なぜ information_schema じゃないの？

A. information_schema は、統計テーブルを返します。つまり、統計テーブルへのアクセスが発生する度に、 mysqld インスタンス内に存在する全ての q4m テーブルのメトリックスを収集する必要があるのです。多数の q4m テーブルが存在する環境において頻繁な統計情報へのアクセスが必要になる可能性があるため、このようなパフォーマンス上の問題が発生する可能性がある information_schema ではなく UDF としての実装を優先しました。