SEARCH
TOOLBOX
LANGUAGES
Mysql

Mysql

From Chaehyun

(Difference between revisions)
Jump to: navigation, search
(innoDB perge 관련)
(innoDB perge 관련)
Line 16: Line 16:
* History list length가 커지면, background thread에 의해 실행될 pending된 io가 많아진다는 것을 의미함. background thread가 이 io를 수행하는 속도는 서버의 현재 상태 (busy or idle)와 서버가 초당 100개의 IO를 처리할 수 있다는 가정에 따라 결정된다.  
* History list length가 커지면, background thread에 의해 실행될 pending된 io가 많아진다는 것을 의미함. background thread가 이 io를 수행하는 속도는 서버의 현재 상태 (busy or idle)와 서버가 초당 100개의 IO를 처리할 수 있다는 가정에 따라 결정된다.  
* primary key 순서대로 스캔하는 thread와 지우는 thread가 동시에 있을 때, 스캔하는 thread는 delete thread에 의해 삭제 되었지만, 아직 purge되지 않은 row를 만날 수 있다. 만약 백그라운드에서 돌고 있는 purge가 delete 작업을 따라잡지 못하면, 스캔 작업은 생각했던 것 보다 굉장히 느릴 것이다. 그러므로 innodb_max_purge_lag을 설정하여, insert, update, delete 작업을 delay 시켜 버린다.
* primary key 순서대로 스캔하는 thread와 지우는 thread가 동시에 있을 때, 스캔하는 thread는 delete thread에 의해 삭제 되었지만, 아직 purge되지 않은 row를 만날 수 있다. 만약 백그라운드에서 돌고 있는 purge가 delete 작업을 따라잡지 못하면, 스캔 작업은 생각했던 것 보다 굉장히 느릴 것이다. 그러므로 innodb_max_purge_lag을 설정하여, insert, update, delete 작업을 delay 시켜 버린다.
 +
* innodb_buffer_pool_size 를 키우자. 메모리의 70~80% 까지. (현재 우리는 1GB로 설정되어 있음)
== data 옮기기 ==
== data 옮기기 ==

Revision as of 02:36, 15 June 2011

  • mysql innodb status
    • History list length 1616091 ??

Contents

innoDB perge 관련

  • innoDB 에서는 sql에 의해 row를 지우더라도, 실제 database에서 row가 즉시 물리적으로 삭제 되지 않음
  • 삭제를 위한 undo log record가 innodb에서 버려졌을 때, 그제서야 해당되는 row와 index rocord를 db에서 물리적으로 삭제함
  • 이러한 삭제 작업을 purge라고 칭함. 그리고 이 purge 작업은 굉장히 빠르고, 보통은 sql의 삭제와 동일한 time order를 가짐
  • my.cnf
  • innodb_max_purge_lag = 8192
    • http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html
    • purge 작업이 지체되었을 때, 얼마나 기다릴 것인지 조절하는 설정
    • 기본은 0임. (delay 없음)
    • 값이 있을 때는, ((purge_lag/innodb_max_purge_lag)×10)–5 milliseconds 만큼, insert, update, delete 작업을 delay 시킨다.
  • show innodb status 하면 innoDB monitor output을 볼 수 있음
    • History list length 값이 바로 purge_lag의 값임
  • http://mysqlha.blogspot.com/2008/07/how-do-you-know-when-innodb-gets-behind.html
  • History list length가 커지면, background thread에 의해 실행될 pending된 io가 많아진다는 것을 의미함. background thread가 이 io를 수행하는 속도는 서버의 현재 상태 (busy or idle)와 서버가 초당 100개의 IO를 처리할 수 있다는 가정에 따라 결정된다.
  • primary key 순서대로 스캔하는 thread와 지우는 thread가 동시에 있을 때, 스캔하는 thread는 delete thread에 의해 삭제 되었지만, 아직 purge되지 않은 row를 만날 수 있다. 만약 백그라운드에서 돌고 있는 purge가 delete 작업을 따라잡지 못하면, 스캔 작업은 생각했던 것 보다 굉장히 느릴 것이다. 그러므로 innodb_max_purge_lag을 설정하여, insert, update, delete 작업을 delay 시켜 버린다.
  • innodb_buffer_pool_size 를 키우자. 메모리의 70~80% 까지. (현재 우리는 1GB로 설정되어 있음)

data 옮기기

  • data를 삭제하기 보다는 새로 insert를 하는 게 더 낫다
  • select ~ where~ into outfile "output"
  • loaddata infile "table" into table Document
    • insert 보다 30배 빠르다는데?
    • unique 확인을 끄는 설정을 켜면 더 빠름
  • mysqldump의 경우, sql로 만드므로, dump file이 커지고, data를 넣을 때, insert를 실행하기 때문에 느리다

설정 값 바꾸기

  • show global variable;
  • set global innodb_max_purge_lag = 0
    • 이러면 바뀜

disk 상태 보기

  • iostat -k 1

다중 출력

  • mysql -E -e "select~" 라고 하면 수직으로 출력됨
Retrieved from "http://chaehyun.kr/w/Mysql"