木下様

ありがとうございます。

> これはpurgeの動作そのものを制御するパラメータではなく、
> purgeが間に合わない場合(マシンの性能が低い or 処理が激しい？)に、
> 故意にパフォーマンスを下げて(DMLのレスポンスを遅くする)、
> purgeが間に合うように手加減するためのものです。
> 通常は利用しないと思います。

ということは、パージスレッド自体は定期的に走っており、デフォルトではpurge_lagが0になるように目指す。
ただし、遅いマシンや処理が激しいマシンなどでpurge_lagが際限なくたまっていってしまう場合、なんとかパージ処理が追いつくように、わざとDMLにdelayを入れる。
という解釈で正しいでしょうか？

07/06/22 に Yasufumi Kinoshita<kinoshita.yasufumi@xxxxxxxxxx> さんは書きました:
> 木下です。
>
> > パージ操作にはtablespaceなどへのディスクアクセスが伴うため、パージ操作が
> > ボトルネックになる可能性があります。
> > なので、innodb_max_purge_lagのデフォルト値0ではディスクアクセスが頻繁に
> > 起きてボトルネックになる、という考え方は正しいでしょうか？
> > また、innodb_max_purge_lagの値を適宜増やして、後でまとめてパージ操作して
> > もらうことでパフォーマンスアップを図るという考え方は正しいでしょうか？
>
> 多分違います。
> これはpurgeの動作そのものを制御するパラメータではなく、
> purgeが間に合わない場合(マシンの性能が低い or 処理が激しい？)に、
> 故意にパフォーマンスを下げて(DMLのレスポンスを遅くする)、
> purgeが間に合うように手加減するためのものです。
> 通常は利用しないと思います。
> どうでしょうか？
>
> Katsuyuki Sakai wrote:
> > 酒井と申します。
> > 先ほどは変なエンコーディングでメールを送信してしまい、申し訳ございません
> > でした。
> > 念のため再送させていただきます。
> >
> > -----------------
> >
> > innodb_max_purge_lagについて教えていただきたく存じます。
> >
> > InnoDBはmulti-versionedストレージエンジンなので、UPDATEやDELETEで変更さ
> > れた行の変更される前の古い情報を保持しておくかと思います（あるトランザク
> > ションが変更前のデータを読む必要性ががあるかもしれないため）。
> >
> > innodb_max_purge_lagのデフォルト値は0なので、UPDATEやDELETE後MySQLは直ち
> > にパージスレッドを走らせ、そのスレッドによって古い情報はパージされるので
> > しょうか？（ただし古い情報を読む必要があるトランザクションが存在しない限
> > り）
> >
> > マニュアルなどを読むと、古い情報の行数をpurge_lagとし、purge_lagの値が
> > innodb_max_purge_lagの値を超えた場合、
> > INSERTとUPDATE、DELETEの各操作が((purge_lag/innodb_max_purge_lag)×10)-5
> > ミリ秒だけ遅延され、その間にパージスレッドが走る、と読めます。
> > http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html
> > http://dev.mysql.com/doc/refman/5.0/en/innodb-multi-versioning.html
> > http://forums.mysql.com/read.php?22,122206,122800#msg-122800
> >
> > パージ操作にはtablespaceなどへのディスクアクセスが伴うため、パージ操作が
> > ボトルネックになる可能性があります。
> > なので、innodb_max_purge_lagのデフォルト値0ではディスクアクセスが頻繁に
> > 起きてボトルネックになる、という考え方は正しいでしょうか？
> > また、innodb_max_purge_lagの値を適宜増やして、後でまとめてパージ操作して
> > もらうことでパフォーマンスアップを図るという考え方は正しいでしょうか？
> >
> > ご返答のほど、よろしくお願いいたします。
> >
> > --
> > 酒井
> >
> >
> >
>
>
>
>