Mysql을 사용하면서 대량을 삭제가 발생할 때 purge lag이 싸여서 mysql 응답속도가 느려질 수 있다는 이야기를 들은 적이있다.
괜찮은 페이지를 찾아서 정리해 놓는다.
http://mysqlha.blogspot.com/2008/07/how-do-you-know-when-innodb-gets-behind.html
InnoDB does not remove deleted rows from a table until they cannot be read by any other transaction. This is done by a background thread. Deleted rows that have not been purged artificially increase the size of a table. They also increase the overhead of table scan operations. This line from SHOW INNODB STATUS displays the amount of work pending for the purge operation. |
History list length 30
즉, delete된 row들이 바로 삭제되지 않는다는 것인데, 실제 삭제는 background thread가 담당한다.
너무 많은 삭제가 일어나 background Thread가 처리하지 못하고 pending(미해결)된 list를 Purge-lag이라고 한다.
http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#sysvar_innodb_max_purge_lag
위의 페이지에서 보면 innodb_max_purge_lag 변수에 대한 설명을 들을 수 있다.
Command-Line Format | --innodb_max_purge_lag=# |
||
Option-File Format | innodb_max_purge_lag |
||
Option Sets Variable | Yes, innodb_max_purge_lag |
||
Variable Name | innodb_max_purge_lag |
||
Variable Scope | Global | ||
Dynamic Variable | Yes | ||
Permitted Values | |||
Type | numeric |
||
Default | 0 |
||
Range | 0 .. 4294967295 |
이 변수는 background thread들이 다 처리하지 못한 purge-lag가 얼마나 쌓였을 때 부터 Insert, update, delete가 delay될 것인가를 결정한다.
background thread가 처리하지 못한 list를 purge-lag이라고 할때 insert,update,delete가 delay되는 시간은 아래의 공식으로 구해지며 매 10초마다 purge batch에 의해 갱신된다.
((
purge_lag
/innodb_max_purge_lag
)×10)–5 millisecondsmysql에서 대량의 삭제를 진행할 때 이 값을 눈여겨 보길 바란다.
'DB > Mysql' 카테고리의 다른 글
mysql replication 문제 (update replication 실패) (0) | 2011.09.08 |
---|---|
Mysql timestamp update null value, mysql에서 timestamp 컬럼에 null을 update할때 (0) | 2011.08.30 |
Mysql 서브쿼리 사용법 페이지 (0) | 2011.07.01 |
Mysql index에 대해서 (0) | 2011.06.23 |
mysql insert 속도에 대하여 (Speed of INSERT Statements) (0) | 2011.04.19 |