ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • MySQL 스레딩 구조
    Technique/RDBMS 2016. 5. 16. 21:57
    반응형

    MySQL 서버는 프로세스 기반이 아니라 스레드 기반으로 작동하며 포그라운드 ( Foreground ) 스레드와 백그라운드( Background ) 스레드로 구분할 수 있다.


    포그라운드 스레드 ( 클라이언트 스레드 )
    최소한 MySQL 서버에 접속된 클라이언트의 수만큼 존재하며, 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리하는 것이 임무다. 클라이언트 사용자가 작업을 마치고 커넥션을 종료하면,ㅡ 해당 커넥션을 담당하던 스레드는 다시 스래드 캐시 ( Thread pool ) 로 되돌아 간다.

    이미 스레드 캐시에 일정 개수 잇아의 대기중인 스레드가 있으면 스레드 캐시에 넣지 않고 스레드를 종료시켜 일정 개수의 스레드만 스레드 캐시에 존재하게 한다.


    포그라운드 스레드는 데이터를 MySQL의 데이터 버퍼나 캐시로부터 가져오며, 버퍼나 캐시에 없는 경우에는 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업을 처리한다. MyISAM 테이블은 디스크 쓰기 작업까지 포그라운드 스레드가 처리하지만, InnoDB 테이블은 데이터 버퍼나 캐시까지만 포그라운드 스레드가 처리하고 나머지 버퍼로부터 디스크까지 기록하는 작업은 백그라운드 스레드가 처리한다.



    백그라운드 스레드

    MyISAM의 경우에는 별로 해당 사항이 없는 부분이지만 InnoDB는 여러가지 작업이 백그라운드로 처리된다. 대표적으로 인서트 버퍼( Insert Buffer ) 를 병합하는 스레드, 로그를 디스크로 기록하는 스레드, InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드, 디에터를 버퍼로 읽어들이는 스레드, 그리고 기타 여러 가지 잠금이나 데드락을 모니터링하는 스레드가 있다. 이러한 모든 스레드를 촐괄하는 메인 스레드도 있다.


    가장 중요한 녀석은 로그 스레드( Log Thread )와 버퍼의 데이터를 디스크로 내려 쓰는 작업을 처리하는 쓰기 스레드 ( Write Thread ) 일 것이다. 

    InnoDB에서도 데이터를 읽는 작업은 주로 클라이언트 스레드에서 처리되기 때문에 읽기 스레드는 많이 설정할 필요가 없지만, 쓰기 스레드는 아주 많은 작업을 백그라운드로 처리하기 때문에 일반적인 내장 디스크를 사용할 때는 2~4 정도 DAS나 SAN 같은 스토리지를 사용할 때는 4개 이상으로 충분히 설정해 해당 스토리지 장비가 충분히 활용될 수 있게 하는 것이 좋다.


    SQL 처리 도중 데이터의 쓰기 작업은 지연되어 처리될 수 있지만 데이터의 읽기 작업은 절대 지연될 수 없다.

    그래서 일반적인 사용 DBMS에는 대부분 쓰기 작업을 버퍼링 해서 읽괄 처리하는 기능이 탑재돼 있으며, InnoDB 또한 이러한 방식으로 처리한다. 하지만 MyISAM은 그렇지 않고 사용자 스레드가 쓰기 작업까지 함께 처리하도록 설계돼 있다.

    이러한 이유로 InnoDB에서는 INSERT와 UPDATE, DELETE쿼리로 데이터가 변경되는 경우, 데이터가 디스크의 데이터 파일로 완전히 저장될 때까지 기다리지 않아도 된다.


    MySQL에서 사용자 스레드와 포그라운드 스레드는 똑같은 의미로 사용된다. 클라이언트가 MySQL 서버에 접속하게 되면 MySQL 서버는 그 ㅋㄹ라이언트의 요청을 처리해 줄 스레드를 생성해 그 클라이언트에게 할당해 준다. 이 스레드는 DBMS의 앞단에서 사용자와 통신하기 때문에 포그라운드 스레드라고 하며, 또한 사용자가 요청한 작업을 처리하기 때문에 사용자 스레드라고도 한다.


    반응형

    'Technique > RDBMS' 카테고리의 다른 글

    플러그인 스토리지 엔진 모델  (0) 2016.05.16
    메모리 할당 및 사용 구조  (0) 2016.05.16
    MySQL 아키텍처  (0) 2016.05.16
    MySQL InnoDB storage  (0) 2016.04.10
    MySQL 쿼리 캐시  (0) 2016.04.10

    댓글

Designed by Tistory.