#Context switcing 이란?
CPU가 어떤 프로세스를 실행하고 있는 상태에서 인터럽트에 의해 다음 우선 순위를 가진 프로세스가 실행되어야 할 때
기존의 프로세스 정보들은 PCB에 저장하고 다음 프로세스의 정보를 PCB에서 가져와 교체하는 작업을 컨텍스트 스위칭이라 한다.
#PCB(process Control Block)란?
Process ID와 상태, 우선순위, 메모리 정보 등을 저장한다.
멀티스레드가 아닌 멀티프로세스 환경에서는 PCB가 PC(program counter)와 Register set 정보도 포함한다.
#TCB(Thread Control Block)란?
Thread별로 존재하는 자료구조이며, PC와 Register Set(CPU 정보), 그리고 PCB를 가리키는 포인터를 가진다.
그리고 TCB는 PCB보다 적은 데이터를 가지는 자료구조이다. 해당 Thread에 대한 정보만 저장하면 되기 때문이다
#Context switcing이 자주 일어나면 왜 부하가 발생할까?
메모리와 레지스터 사이의 데이터 이동도 I/O이다.
즉, 컨텍스트 스위칭 과정에서 I/O가 발생한다. 빈번한 I/O 발생은 overhead를 발생시킨다.
실행되는 process의 수가 많고, 빈번한 컨텍스트 스위칭이 발생한다면, 이는 성능을 떨어뜨린다.
하지만 I/O가 발생할 때, CPU는 비싼 자원을 기다리게 할 수 없다.
I/O가 발생할 때, CPU를 게속 사용하려면 컨텍스트 스위칭은 피할 수 없다.
기본적인 Context switching은 위와 같고 mysql은 멀티스레드 구조라 아래와 같은 환경이다.
스레드 스위치와 프로세스 스위치의 차이는 스레드 스위치 중에는 가상 메모리 공간이 그대로 유지되지만 프로세스 스위치에서는 그렇지 않다는 것이다.
두 유형 모두 컨텍스트 스위치를 수행하기 위해 운영 체제 커널에 제어 권한을 넘겨주는 것을 포함한다.
레지스터를 전환하는 비용과 함께 OS 커널을 안팎으로 전환하는 프로세스는 컨텍스트 스위치를 수행하는 데 가장 큰 고정 비용이다.
context switching을 알아야하는 이유는 mysql의 장애상황이 대부분이 이것과 관련되기 때문이다.
대부분은 상황은 Cost가 큰 실행계획 등으로 인해 실행엔진에서 I/O 핸들러가 Disk에 가서 데이터를 찾을텐데 이게 오래걸리다 보면 waiting을 기다리지 않고 CPU는 다른 thread를 실행하기 위해 context switching을 발생하는 것으로 보인다.
#컨텍스트 스위치도 구분이 있다?
MySQL의 경우 스레드를 실행중에
조만간 디스크 IO, 네트워크 IO, 뮤텍스 대기 또는 양보와 같은 일부 차단 작업을 수행해야 한다.
이 경우 실행이 다른 프로세스로 전환되며, 이를 자발적 컨텍스트 스위치라고 한다.
반면에, 프로세스/스레드는 할당된 CPU 시간(그리고 이제는 다른 작업을 실행해야 함)을 사용하였거나 높은 우선순위 작업을 실행해야 하기 때문에 스케줄러에 의해 선점될 필요가 있을 수 있다.
이것을 비자발적인 컨텍스트 스위치라고 한다.
--> 어떤 것이 더 좋은 상황인지 아직 잘 모르겠다. mysql의 context switching 상황에 대해 설명한 블로그의 글을 참조하여 일단 정리한다.
#mysql 뮤택스 모든경합이 context-switching?
MySQL에서 모든 경합이 컨텍스트 스위치로 이어지는 것은 아니라는 점에 유의할 필요가 있다.
InnoDB는 자체적인 뮤텍스와 RW-locks를 구현하는데, 이는 종종 자원이 이용 가능해지기를 기다리기 위해 "spin"을 시도한다. 이것은 컨텍스트 스위치를 하기보다는 CPU 시간을 직접적으로 소모한다.
참조:
https://teraphonia.tistory.com/802
https://jhnyang.tistory.com/33
https://jinnify.tistory.com/36
https://www2.cs.duke.edu/courses/spring01/cps110/slides/threadsync/sld004.htm
https://hwan-shell.tistory.com/197
'RDB > mysql' 카테고리의 다른 글
[튜닝] 유물발굴 (mysql tuning using heavy query) (0) | 2020.09.18 |
---|---|
mysql을 시작하기 전에 3 (8) | 2020.08.26 |
mysql을 시작하기 전에 1 (0) | 2020.08.04 |
mysql swap 메모리 사용 초기화 (0) | 2020.07.22 |
대용량 테이블 컬럼추가 (rows 1000만 건 이상) (0) | 2020.07.17 |