MySQL InnoDB BACKGROUND THREAD
[출처] MySQL InnoDB BACKGROUND THREAD (MySQL Power Group) |작성자 악동
http://cafe.naver.com/mysqlpg/421
여기 저기 많은 Site 내용을 끼워 맞추었고...ㅠㅠ영어 Site 는 음... 틀리게 이해 한 부분 있으면 바로 지적해주세요
여기 저기 끼워맞추기 1탄입니다.
데이터베이스는 ACID 조건을 만족하고 최적의 실행 계획을 찾아 내기 위해서 복잡하고 정교한 작업을 진행합니다.
내부적으로는 동시 처리를 위한 저수준 잠금, 롤백 세그먼트 관리, disk Flush를 유기적으로 처리해야만 하며
MySQL InnoDB 역시 MVCC(multiversion concurrency controll)를 통해서 변경 전후 데이터를 유지하며
MUTEX(mutual exclusion)를 통해 수많은 동시 DB 명령어를 처리합니다.
모든 DB 명령어는 엔진에서 재귀 명령어를 발생시고 세션이나 사용자 동접이 올라가면 부하는 지수적으로 올라갑니다.
MySQL은 버전 업그레이드가 진행 되면서 동시 처리 성능 증대를 위한 많은 변경이 있었으며
MySQL 명령어인 show engine innodb status\G 에서 innodb 상태를 체크 할 수 있으며
버전이 올라가면서 각 Thread 분리 혹은 성능 최적화를 위한 주요 내용들에 대한 성능 개선에 대한 이해를 show engine innodb status 부분과 연관지어 보려고 합니다.
( 최근 MySQL 에서는 information_schema performance_schema 를 통해 보다 많은 성능 수치를 확인 할 수 있다. )
----------------------
BACKGROUND THREAD
----------------------
srv_master_thread loops: 4155278 1_second, 4155276 sleeps, 397985 10_second, 3508874 background, 3507563 flush
srv_master_thread log flush and write: 4354878
* srv_master_thread (마스터 Thread)
- mysql 5.1 이전 버전 : srv_master_thread 한개로 purge(innodb dirty page check 및 purge,
transcation commit 처리, redo log check 및 purge) 수행합니다.
문제 : Main Thread 한나로 purge함으로써 대량 트래픽 발생으로 인한 transaction purge 부하 증가가 되고
dirty 및 redo의 처리에 대한 지연발생으로 전체적인 성능 저하가 발생 합니다.
- MySQL 5.5 : main thread or background thread로 transaction purge를 분리할 수 있도록 합니다.
( innodb_purge_threads=[0|1],innodb_purge_batch_size )
- MySQL 5.6 : main thread 가 아닌 background thread 로 동작하며 multi purge thread 를 위해 32까지 가능합니다.
(innodb-purge-threads=[1..32])
multi threaded purge 참고
(https://blogs.oracle.com/mysqlinnodb/entry/mysql_5_6_multi_threaded)
purge thread 성능 비교 참고
(http://dimitrik.free.fr/blog/archives/2010/04/mysql-performance-why-purge-thread-in-innodb.html)
=> dirty page purge Thread 분리 MySQL 5.6(page cleaner thread)
MySQL purge thread 참고
(https://dev.mysql.com/doc/innodb/1.1/en/innodb-improved-purge-scheduling.html)
MySQL InnoDB는 버전이 업그레이드 되면서 purge 를 위한 Thread 들이 각각 기능별 분리 및 성능 향샹을 위한 옵션이 추가 되었습니다.
show engine innodb status 의 TRANSACTIONS 섹션을 통해서 transaction, redo log ,dirty page, insert buffer purge 에 대한 자세한 내용을 언급 하도록 하겠습니다.
여기 저기 끼워맞추기 2탄 입니다.
--------------
SEMAPHORES
--------------
OS WAIT ARRAY INFO: reservation count 16808581, singal count 75349348
Mutex spin waits 567136608, rounds 989818342, OS waits 7441108
RW-shared spins 23382110, rounds 222945748, os waits 7441108
RW-excl spins 7120585, rounds 2349470423, OS waits 3060884
Spin rounds per wait: 1.75 mutex, 9.53 RW-shared, 33.63 RW-excl
--Thread 140426532412 has waited at btr/btr0sea.c line 774 for 0.00 seconds
S-lock on RW-latch at 0x7fb86b28f0b8 created in file btr/btr0sea.c line 139
a writer (thread id 1404265345512) has reserved it in node exclusive number of readers 0,
waiters flag 1
* semaphore : 다중 프로세스처리시 공유 데이터에 접근할때(context switch 와 같은 케이스...) 순서에 따라
동기화 처리 하도록 합니다.
* mutex : 임계영역(공유데이터) 접근시 하나의 쓰레드만 처리할수 있도록 Lock 처리합니다.
* reservation count : 세마포어 slot 에 추가된 건수입니다.
* signal count : 쓰레드가 공유데이터에 접근하기 위한 signal 을 받은 건수입니다.
* spin waits : mutex 획득을 통해 lock한 건수입니다.
* rounds : mutex 를 획득 못할때 바로 context switch 를 발생하지 않도록 retry 한 건수입니다.
* os waits : Thread 가 공유 데이터 접근하기 위해 context Switch 한 건수이며 일정 spin waits 시도 후에
context switch 가 발생합니다.
* 평균 mutex 획득 요청수 = spin_rounds/ sin_waits
* innodb_spin_wait_delay 를 통해 mutex 획득을 위한 ms 를 정할수 있습니다. default 6
http://topnanis.tistory.com/195
mutex 개선 변경 히스토리
http://www.tocker.ca/2013/11/27/what-is-a-mutex-anyway.html
mutex 개선 내용
http://dev.mysql.com/doc/innodb/1.1/en/innodb-performance-latching.html
- A,B 두개의 Thread 가 아래 코드를 실행할때 케이스
--------------------------------------------------------------------------------------
i = 10; 전역변수
i += 10;
--------------------------------------------------------------------------------------
A Thread B Thread
--------------------------------------------------------------------------------------
임시변수 i = 전역변수 i 10 + 10 처리
임시변수 i = 전역변수 i 10 + 10 처리
전역변수 i = 임시변수 i(20) 복사
전역변수 i = 임시변수 i(20) 복사
--------------------------------------------------------------------------------------
=> A, B Thread 가 시간 차이를 두고 실행 되때 전역변수i를 A Thread 가 Lock(Mutex) 처리 하고 B Thread 가
rounds 시도 이후 context switch이 발생합니다.
위 같은 상황에서 다른 Thread 가 요청 발생이 되면 B Thread 가 우선 순위(Semaphore)로 동기화가 됩니다.
MySQL rounds 는 OS context switch 발생으로 인한 리소스 소비를 줄이기 위하여 mutex 획득 재시도 합니다.
참고 (http://topnanis.tistory.com/195)
* MySQL 5.5.4 Mutex 개선 내용
http://blog.zawodny.com/2010/04/14/mysql-5-5-4-is-very-exicting/
* MySQL InnoDB는 MUTEX 성능을 최대화 하기 위해 많은 개선이 이루어 졌으며 아래와 같은 내용들이 수정 되었습니다.
- buffer pool mutex : 대용량 buffer pool 사용으로 인한 LRU list, flush list 를 인스턴스별로 관리하여
purge 성능을 높일수 있다.
https://dev.mysql.com/doc/innodb/1.1/en/innodb-multiple-buffer-pools.html
http://mikaelronstrom.blogspot.ca/2010/09/multiple-buffer-pools-in-mysql-55.html
MySQL 5.5 버전에서 buffer pool instance 분리 기능 추가
- adaptive hash index (AHI) mutex : innodb는 secondary index에 대해 호출 패턴을 분석하여 prefix 값을 통해
hash 인덱스를 생성하여 관리하나 index search 시 경합 문제가 발생합니다.
MySQL 5.1 버전부터 (innodb_adaptive_hash_index) 을 통해 제어 가능합니다.
http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-performance-adaptive_hash_index.html
- log_sys mutex : in memory log buffer(innodb_log_buffer_size)의 사용자 transaction redo log 적용부분과
innodb buffer pool 의 dirty page 가 겹치게 되면 과도한 I/O 발생 및 경합이 발생하게 됩니다.
MySQL 5.5 부터는 dirty page flush 처리를 위해 모든 dirty page의 연속적인
최소 트랜잭션 로그 MTR(mini-transaction)과 global log buffer로 나누어 관리합니다.
http://dev.mysql.com/doc/innodb/1.1/en/innodb-improved-log-sys-mutex.html
https://blogs.oracle.com/mysqlinnodb/entry/redo_logging_in_innodb
http://www.sba-research.org/wp-content/uploads/publications/WSDF2012_InnoDB.pdf
http://cafe.naver.com/mysqlpg/86
- rseg mutex : innodb는 ibdata의 rollback segement를 통해 변경 이전 정보를 기록하며 비정상 Fail 에도 Data 일관성을
보장하며 변경전 데이터에 대한 동기화 mutex에 개선이 아래와 같이 이루어졌습니다.
변경이전 데이터에 대한 동기화가 지연될 경우 show engine innodb status 에서 "TRANSACTIONS" 부분의
history list length 에 해당 갯수가 카운트 됩니다.
rollback segment mutex 는 purge와 연관이 있으며
MySQL 5.0 (innodb 1.0) : rollback segment 관리는 Main Thread 에서 직접 Purge 를 관리하며
disk bound disk I/O 발생으로 전반적으로 느려지는 현상이 발생한다.
MySQL 5.5 (innodb 1.1) : rollback segment 관리가 Background Thread 로 분리되었으며 한개
rollback segment에 slot 1024개의 동시 트랜잭션 처리가 가능하도록 변경되었습니다.
대량 변경으로 인한 disk 요청량이 많아지면서 unflushed된 history list 가 쌓이는 현상이 발생하며
Innodb_max_purge_lag 옵션을 통해 조절이 가능합니다.
예) history list length : 3000 => innodb_max_purge_lag 에 지연 수치를 적용(2000)
: (( history list length / innodb_max_purge_lag ) * 10 ) - 5 3000 / 2000 * 10 - 5 = 10ms
=> innodb_max_purge_lag 변경에 따른 undo log segement Size 가 커지는 문제발생
=> history list length 수치에 따른 Query 영향도
: undo log segement 를 scan 하는 리소스 발생한다.
MySQL 5.6 (innodb 1.1) : 128개 rollback segment에 각 segment당 slot 1024개의 동시 트랜잭션 약 128K 처리가
가능하도록 변경되었으며(multiple thread,page cleaner) 새로운 flush 방식을 통해 MySQL 5.5의
history list length 문제점이 개선 되었습니다.
http://www.pythian.com/blog/some-fun-around-mysql-history-list/
http://dev.mysql.com/doc/innodb/1.1/en/innodb-multiple-rollback-segments.html
http://dev.mysql.com/doc/innodb/1.1/en/innodb-separate-flush-list-mutex.html
https://blogs.oracle.com/mysqlinnodb/entry/better_scalability_with_multiple_rollback
http://mysqldba.tistory.com/83
- kernel mutex : V5.5까지 InnoDB core sub-system(Locking, Transaction, MVCC view sub-system)의
쿼리의 상태 변화를 체크를 커널 뮤텍스라는 글로벌 뮤텍스로 처리하였으며
Thread 증가로 여러개의 transaction이 동시 처리를 위해 각 Thread의 Query 상태는 lock, release 발생 및
transaction 처리가 완료되며
Thread별 Query의 상태 변화 때마다 글로벌 뮤텍스를 사용하게 되여 동시 처리량이 감소하는 현상이 발생합니다.
MySQL V5.6 에서는 multi thread 처리를 위해 innodb core sub-system에서 transaction 시작과 끝에는
글로벌 lock과 Query 상태 변화는 mutex로 분리하여 처리하도록 변경되었습니다.
https://blogs.oracle.com/mysqlinnodb/entry/mysql_5_6_innodb_scalability
MySQL 5.5이전 버전에서 Kernel mutex 이슈로 innodb_sync_spin_loops 변경에 따른 성능 비교가 있으나
Thread 증가에 따른 영향도는 크지 않습니다.
http://www.mysqlperformanceblog.com/2011/12/02/kernel_mutex-problem-or-double-throughput-with-single-variable/
아래는 tcmalloc의 per thread cache 를 사용관련 내용입니다.
http://jamesgolick.com/2012/7/18/innodb-kernel-mutex-contention-and-memory-allocators.html
- MDL(Meta Data Lock) mutex : MySQL V5.3 을 기준으로 이전 버전에서 isolation level repeatable-read 트랜잭션 안의
구문단위로 MDL 을 획득 하여 다른 세션에서 DDL 수행이 완료되며 트랜잭션 안에서 읽기 일관성이 깨지는 현상 발생
MySQL V5.3 이상부터 트랜잭션 단위로 MDL을 처리하여 다른 세션의 DDL은 트랜잭션이 끝나기를 기다리므로 읽기
일관성은 일치하나 wait 이 발생합니다.
MySQL V5.7 에서는 metadata_locks_cache_size 와 metadata_locks_hash_instances 가 소개된다.
http://dev.mysql.com/doc/refman/5.5/en/metadata-locking.html
http://sql.dzone.com/articles/implications-metadata-locking
여기 저기 끼워맞추기 3탄 입니다.
---------------
TRANSACTIONS
---------------
Trx id counter A881F4E8
purge done for trx's n:0 < A881F4D0 undo n:0 < 0
History list length 2597
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 4339297, OS thread handle 0x7fd3c7cc6700, query id 3360966151 localhost root
show engine innodb status
---TRANSACTION A881F4E7, not started
MySQL thread id 3244653, OS thread handle 0x7fd3c7cc6700, query id 3360966151 Slave has read all relay log; waiting for the slave I/O thread to update it
* MySQL InnoDB의 트랜잭션을 처리를 위해서 FILE I/O, INSERT BUFFER AND ADAPTIVE HASH INDEX, LOG, BUFFER
POOL AND MEMORY 간의 서로 연관된 복잡한 동기화를 실행합니다.
TRANSACTIONS 에 가장 눈에 띄는 History list length 관련하여 SEMAPHORE rseg mutex에서 언급한
Rollback Segment 구조를 이해하기 전에 전체 InnoDB 의 레이아웃부터 확인해 보고자 합니다.
Rollback segement 구조에 대한 search를 하다가 InnoDB 테이블 구조에 대한 내용이 잘 정리된 곳부터 소개해 드립니다.
InnoDB table space 에 대한 전반적인 레이아웃은 Jeremy Cole 블로그를 통해 많은 정보를 얻을수 있습니다.
http://blog.jcole.us/2013/01/03/the-basics-of-innodb-space-file-layout/
http://blog.jcole.us/2013/01/04/page-management-in-innodb-space-files/
InnoDB 다이어그램 다운로드 https://github.com/jeremycole/innodb_diagrams 에서 png파일을 받아 볼수 있습니다.
( System, Extents, Index, Free list, Transaction, Data, Undo 공간에 대한 구조를 볼수 있습니다. )
관심 있는분은 위 URL을 참고하세요
InnoDB Page(16Kbyte) header에는 이전Page, 다음Page 위치 정보를 4byte로 모든 Page 주소를 표현할수 있습니다.
최대 관리되는 Page 숫자는 2^32 = 약42억(4294967296)개를 가질수 있으며
하나의 Default Page Size는 16Kbyte(16384Byte)로 2^32*16Kbyte = 약64Tbyte 까지 사용할수 있습니다.
( MySQL V5.6.4 부터는 set innodb_page_size=n(4k, 8k, 16k, or 4096, 8192, 16384) 으로 변경가능합니다 )
대락 적인 구조 정보
Table Space 구조 정보
- InnoDB 의 ibdata Talble space 0 ~ 191page는 전체 구조 정보를 담고 있습니다.
( 약 3Mbyte 이상의 공간에 필요한 중요 정보들이 포함되어 있습니다. )
page0 type FSP_HDR : space, lists of free, fragmented, full extents 들의 정보 저장
page1 type IBUF_BITMAP : Insert Buffer bitmap 정보 저장
page2 type INODE : inode 관련된 정보 저장
page3 type SYS : Insert Buffer Header 정보 저장
page4 type INDEX : insert buffering 를 위한 index의 root page 정보 저장
Page5 type TRX_SYS : innodb 트랜잭션을 위한 정보 저장
(마지막 transaction id,binlog 정보, double write buffer extents 위치 정보)
Page6 type SYS : first rollback segment 정보 저장
Page7 type SYS : index data dictionary 정보 저장
Page 8 ~ 63 : 확장 SYS type 정보 저장
Pages 64 ~ 127 : 1번째 double write buffer(64page or 1 Extent 1Mbyte)
Pages 128 ~ 191 : 2번째 double write buffer(64page or 1 Extent 1Mbyte)
그중에서 Page5 type TRX_SYS 부터 rollback segment 에 대한 구조를 통해
InnoDB history 관리가 어떻게 되는지에 대한 구조를 확인 할 수 있습니다.
Page5 type TRX_SYS 에는 rollback segment 를 위한 128개의 slot 가 존재하며
각 slot 는 Page43 type SYS 와 같이 rollback segments 를 가리키고 있습니다.
Page43 에는 동시 트랜잭션 처리를 위한 undo Segment Arrary 0 ~ 1023(1024) 가 존재하며
history list 정보를 통해서 purge 되지 않는 리스트를 관리합니다.
page301 에는 undo log segment가 존재하며 실제 ungo Logs 에 purge 되어 Sync 가 이루어 집니다.
rollback segment 구조에 이어 show engine innodb status\G TRANSACTIONS부분에 나온 내용은 아래와 같습니다.
Trx id counter A881F4E8 : 전체 트랜잭션의 갯수를 16진수(64bit 범위)로 표시하며 총 트랜잭션 갯수를 의미합니다.
A881F4E8 => 2827089108
purge done for trx's n:o < A881F4D0 undo n:o < 0 : purge done for trx's n:o 는 purge된 트랜잭션 갯수 입니다.
A881F4D0 => 2827089104
undo n:o 는 purge 가 진행되고 있는 갯수 입니다.
not started 된 상태 => trx id counter - (purge done + undo)
History list length 2597 : undo space 에서 purge 가 안된 갯수입니다.
트랜잭션의 상태를 표시하는 정보들이 이어서 보여 줍니다.
"not started", "ACTIVE", "fetching rows", "updating",
"Thread declared inside InnoDB 400"
"waiting in InnoDB queue","sleeping before joining InnoDB queue"
InnoDB kernel 내부 Queue에 진입하기 위해 Innodb_thread_concurrency, innodb_thread_sleep_delay 를 통해
성능 최상의 성능을 발휘하도록 변경가능합니다.
http://dimitrik.free.fr/blog/archives/2010/11/mysql-performance-55-and-innodb-thread-concurrency.html
(관련 테스트 내용입니다.)
InnoDB 커널내부에서 동시에 처리되는 Queue 옵션으로 innodb_concurrency_tickets로 조절할수 있으며
MySQL V5.5 까지 defaults 500이며 V5.6.6 에서는 5000 으로 변경되었습니다.
http://www.pythian.com/blog/once-again-about-innodb-concurrency-tickets/
( 간단한 테스트 내용입니다.)
show engine innodb status\G 에 대한 이해는 필요할 것으로 보여 여기 저기 블럭 맞추기를 하고 있습니다.
혹 틀린 부분 있으면 언제든지..말씀 주세요
여기 저기 끼워맞추기 4탄 입니다.
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (read thread)
I/O thread 4 state: waiting for i/o request (read thread)
I/O thread 5 state: waiting for i/o request (read thread)
I/O thread 6 state: waiting for i/o request (write thread)
I/O thread 7 state: waiting for i/o request (write thread)
I/O thread 8 state: waiting for i/o request (write thread)
I/O thread 9 state: waiting for i/o request (write thread)
Pending normal aio reads: 0[0,0,0,0], aio writes: 0 [0,0,0,0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
293406 OS file reads, 10470446 OS file writes, 175420 OS fsyncs
9.33 reads/s, 16384 avg bytes/read, 696.86 writes/s, 2.75 fsyncs/s
Linux 데이터 동기화는 system API 호출을 통해 OS Kernel 내부 캐시 자체 대기열을 사용하여 DISK 에 기록하며 자체
대기열로 인한 문제를 해결하기 위해 sync(), fsync(), fdatasync() 시스템 콜 함수를 제공합니다.
- sync() : 모든 버퍼 내용(데이터, 메타데이터) 동기화합니다. 일반적으로 시스템이 30초 주기로 flush 할때 호출 됩니다.
- fsync() : fd(file descriptor) 로 지정된 파일과 관련된 모든 변경내용(데이터, 메타데이터)을 디스크에 동기화 합니다.
- fdatasync() : fd(file descriptor) 로 지정된 파일과 관련된 데이터만 디스크에 동기화 합니다.(fsync() 보다 빠릅니다.)
시스템 콜 함수 이외에 open() 함수를 사용하여 O_SYNC, O_DSYNC, O_RSYNC, O_DIRECT 플래그를 통하여
데이터 동기화를 사용할 수 있습니다.
- O_SYNC : write()호출 직후 fsync()를 강제로 호출을 하여 데이터 동기식 입출력을 할수 있도록 합니다.
(쓰기 연산 시간이 늘어날 수 있습니다.)
- O_DSYNC : write()호출 직후 fdatasync()를 강제로 호출 합니다.
- O_RSYNC : write()와 read() 호출전에 메타데이터 동기화를 하도록 합니다.
- O_DIRECT : 캐시를 우회해서 사용자 영역 버퍼에서 디바이스로 직접 입출력 동기화를 합니다.
InnoDB 역시 데이터를 DISK 에 기록하기 위해(Linux OS경우) Asynchronous I/O(AIO)에 대해
innodb plugin 1.1 innodb_use_native_aio 설정을 통해 pread() pwrite() 시스템 콜을 활용하여 파일의 처음부터
오프셋으로 access를 하지 않고 지정된 위치 부터 오프셋에 access 하여 flush_list 에 대한 별도의 marking(clean,removed)을
하지 않아 IO를 줄이도록 하였습니다.
https://blogs.oracle.com/mysqlinnodb/entry/innodb_now_supports_native_aio
InnoDB DISK I/O를 위한 Thread는
- insert buffer thread : buffer pool에 존재하지 않는 secondary index 데이터 수정이 되면 buffer pool 일부분에 해당 정보를
기록하여 Secondary Index 의 Random DISK I/O를 줄이도록 하며 해당 데이터가 memory에
load 될때 merge 작업을 통해 leaf node의 데이터를 동기화 하는 Thread 입니다.
http://dev.mysql.com/doc/innodb/1.1/en/innodb-performance-change_buffering.html
- log thread : redo log disk sync를 위한 Thread이며 MySQL V5.1 까지 srv_master_thread 에서 purge를 했으며 V5.5 부터
분리되었습니다.
- read thread / write thread : buffer pool 데이터 동기화 하며 MySQL V5.1 부터 srv_master_thread Thread 에서 분리되어
innodb_write_io_threads/innodb_read_io_threads 옵션으로 조절 됩니다.
innodb_use_native_aio 를 통해 시스템 콜을 사용하여 대량 트래픽 발생시 Linux System IO Call 의
제한으로 error 이 발생될 수 있습니다.
InnoDB: Using Linux native AIO
InnoDB: Warning: io_setup() failed with EAGAIN. Will make 5 attempts before giving up.
InnoDB: Warning: io_setup() attempt 1 failed.
InnoDB: Warning: io_setup() attempt 2 failed.
InnoDB: Warning: io_setup() attempt 3 failed.
InnoDB: Warning: io_setup() attempt 4 failed.
InnoDB: Warning: io_setup() attempt 5 failed.
InnoDB: Error: io_setup() failed with EAGAIN after 5 attempts.
InnoDB: You can disable Linux Native AIO by setting innodb_native_aio = off in my.cnf
InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: Completed initialization of buffer pool
mysqld got signal 11 ;
* Linux aio max nr 설정 확인
cat /proc/sys/fs/aio-max-nr
65536
* Linux aio 사용 현황
cat /proc/sys/fs/aio-nr
* Linux aio 설정 변경
sysctl fs.aio-max-nr=262144
FILE I/O 이외의 다른 Thread 정보 확인
select * from performance_schema.thread;
+-----------+----------------------------------------+------------+----------------+
| thread_id | name | type | PROCESSLIST_ID |
+-----------+----------------------------------------+------------+----------------+
| 1 | thread/sql/main | BACKGROUND | NULL |
| 2 | thread/innodb/io_log_thread | BACKGROUND | NULL |
| 3 | thread/innodb/io_read_thread | BACKGROUND | NULL |
| 4 | thread/innodb/io_read_thread | BACKGROUND | NULL |
| 5 | thread/innodb/io_ibuf_thread | BACKGROUND | NULL |
| 6 | thread/innodb/io_read_thread | BACKGROUND | NULL |
| 7 | thread/innodb/io_read_thread | BACKGROUND | NULL |
| 8 | thread/innodb/io_write_thread | BACKGROUND | NULL |
| 9 | thread/innodb/io_write_thread | BACKGROUND | NULL |
| 10 | thread/innodb/io_write_thread | BACKGROUND | NULL |
| 11 | thread/innodb/io_write_thread | BACKGROUND | NULL |
| 14 | thread/innodb/srv_lock_timeout_thread | BACKGROUND | NULL |
| 15 | thread/innodb/srv_error_monitor_thread | BACKGROUND | NULL |
| 16 | thread/innodb/srv_monitor_thread | BACKGROUND | NULL |
| 17 | thread/innodb/srv_master_thread | BACKGROUND | NULL |
| 18 | thread/innodb/srv_purge_thread | BACKGROUND | NULL |
| 19 | thread/innodb/page_cleaner_thread | BACKGROUND | NULL |
| 20 | thread/sql/signal_handler | BACKGROUND | NULL |
| 22 | thread/sql/one_connection | FOREGROUND | 2 |
+-----------+----------------------------------------+------------+----------------+
19 rows in set (0.00 sec)
와 같이 main, purge(srv_purge_thread), one_connection(thread_handling) 과 같은 Thread 정보를 확인 할 수 있습니다.
http://dba.stackexchange.com/questions/56482/how-can-i-determine-the-maximum-possible-number-of-threads
Pending normal aio reads: 0[0,0,0,0], aio writes: 0 [0,0,0,0]
read,write aio 의 Pending page 갯수를 표시합니다.
예) Pending normal aio reads: 8[1,2,1,4], aio writes: 0 [0,0,0,0]
현재 read aio 에서 4개의 Thread 에서 각각 page(16K) 들이 Pending 된 상태를 보여 줍니다.
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
insert buffer AIO Pending read page 갯수를 표시합니다, log i/o's : log Pending log i/o 수 입니다,
sync i/o's: Pending sync 수 입니다.
Pending flushes (fsync) log: 0; buffer pool: 0
fsync 를 통한 동기화 Pending 수입니다.
293406 OS file reads, 10470446 OS file writes, 175420 OS fsyncs
reads는 innodb page(16Kbyte) 단위로 읽어 들이는 건수이며 16384 avg bytes/read 보다 크게 되면
Random Read 가 발생하여 Read I/O 에 영향이 될수 있습니다.
writes 는 data,log file write 건수이며 data의 경우 innodb page(16Kbyte) 수이며 log file ,
double write 의 경우 512byte 의 건수 입니다.
show global status 의 innodb_data_writes와 innodb_log_writes 의 합한 결과입니다.
9.33 reads/s, 16384 avg bytes/read, 696.86 writes/s, 2.75 fsyncs/s
초당 reads,writes 한 건수 와 평균 read 한 byte 수가 표시 됩니다.
(writes 의 경우 data, log write 단위가 서로 다릅니다.)
16384 byte 이상의 avg bytes/read 발생시 많은 Random read 발생 확률이 높아집니다.
http://www.mysqlperformanceblog.com/2007/06/26/can-innodb-read-ahead-reduce-read-performance/
innodb data read write 관련 설명
http://www.facebook.com/notes/mysql-at-facebook/innodb-disk-io-counters-in-show-status/445139830932
'연구개발 > MYSQL' 카테고리의 다른 글
| 기초 Admin 1장 테스트 (0) | 2014.09.16 |
|---|---|
| MMM (Multi-Master Replication Mananger) 설치 (0) | 2014.09.15 |
| INNODB 두번째 (0) | 2014.09.15 |
| INNODB 첫번째 (0) | 2014.09.15 |
| TokuDB? Fractal Index에 대해 알아보아요~! (0) | 2014.09.15 |