0x0102
DevOps - dirty page가 I/O에 끼치는 영향 본문
1. dirty page
dirty page:
page cache에 있는 페이지 중 쓰기 작업이 이루어진 메모리
page writeback (or dirty page 동기화) :
dirty page가 생성될 때마다 디스크에 쓰면 쓰기 I/O가 폭증하여 성능 저하가 발생할 수 있기에
몇가지 조건을 만족시켜야만 dirty page를 디스크로 동기화하는 과정
보통 pdflush,flush,bdflush 등 flush가 들어간 커널 스레드가 이 작업을 진행함
따라서 I/O가 많이 발생하는 서버에서는 dirty page를 언제 얼마나 동기화 시키느냐가 중요한 성능 튜닝 요소가 됨
2. dirty page 관련 커널 파라미터
1) vm_dirty_background_ratio
dirty page 내용을 백그라운드로 동기화할 때 그 기준이 되는 비율
파라미터 값(비율) x 전체 메모리 양 < dirty page -> 백그라운드 동기화 진행
2) vm.dirty_background_bytes
1번과 같은 방식이지만 절대적인 bytes 값을 명시한다.
3) vm.dirty_ratio
1번과 유사하나 background라는 단어가 빠져있는, 일종의 hard limit이다.
4) vm.dirty_writeback_centisecs
3번과 같은 방식이지만 절대적인 bytes 값을 명시한다.
5) vm.dirty_writeback_centisecs
flush 커널 스레드를 몇 초 간격으로 깨울 것인지 결정한다.
1/100값으로 표기된다.
6) vm.dirty_expire_centisecs
5번값에 의해 깨어난 flush 커널 스레드가 디스크에 싱크시킬 dirtypage 기준을 찾을 때 사용한다.
1/100초 값으로 표기된다.
3. 백그라운드 동기화
1) 백그라운드 동기화
동기화 작업이 백그라운드로 진행되는 것
vm_dirty_background_ratio, vm.dirty_ratio 를 통해 조절한다.
애플리케이션이 dirty page를 생성할 때마다 현재까지 생성된 dirty page와 전체 메모리의 비율을 바탕으로 진행된다.
2) 주기적인 동기화
동기화 작업이 주기적으로 진행되는 것
vm.dirty_writeback_centisecs, vm.dirty_expire_centisecs 를 통해 조절된다.
dirty page를 동기화하기 위해 필요한 flush 데몬을 깨우는 주기와 깨웠을 때 동기화 시키는 dirtypage의 기준을 설정한다.
3) 명시적인 동기화
명령어를 통해 명시적으로 동기화시키는 것
sync,fsync 등응 이용해 현재 생성되어 있는 dirty page를 명시적으로 디스크에 쓴다.
이러한 동기화 과정은 ftace 결과로 확인할 수 있으며
실습을 통해 백그라운드 동기화와 주기적인 동기화가 flush 커널 스레드를 깨우는 기준만 다르지 하는 작업은 다르지 않다는 것을 알 수 있다.
두 경우 모두 서로 영향을 끼치고 같은 방식으로 dirty page를 동기화함으로 두 값은 시스템의 전체적인 dirty page 관리 포인트를 설정하는 의미가 있다.
4. dirty page 설정과 I/O 패턴
dirty page 관련 파라미터 값을 조절하여 I/O 패턴이 어떻게 바뀌는지 실습
1) 비율을 높게 설정한 경우
iostat으로 I/O 사용량을 살펴보면 대부분 0%에서 100%까지 갑자기 이르는 패턴을 확인할 수 있다.
flush 커널 스레드가 깨어나는 조건이 더 길어지는 대신 한번에 동기화하는 양이 많아지기 때문이다.
2) 비율을 낮춘 경우
1에 비해 낮은 수준으로 dirty page의 크기가 유지되는 것을 볼 수 있다.
더 자주 flush 커널 스레드가 깨어나지만 한번에 동기화하는 양이 1보다 작다.
dirty page 동기화와 관련하여 가장 중요한 부분은 flush 커널 스레드를 얼마나 자주 깨울 것인지, 깨울 때 어느 정도 양을 동기화할 것인지를 설정하는 것이다.
자주 깨어나면 io uitl%이 비교적 적지만 flush 커널 스레드가 자주 깨어나는 단점이 있고
늦게 깨우면 flush 커널 스레드는 자주 깨지 않지만 io util%이 높아지는 단점이 있다.
flush 커널 스레드가 너무 자주 깨어나면 스케줄링에 대한 오버헤드가 발생할 수 있으며 cpu 리소스 또한 빼앗길 수 있어 성능 저하가 발생할 수 있다.
dirty page 동기화는 어떻게 설정하느냐에 따라 장단점이 있으며 절대적인 기준이 존재하지 않는다.
따라서 현재 시스템에서 발생하는 워크로드와 디스크의 성능에 따라 결정해야한다.
ex) 초당 1mb의 dirtypage를 생성하는 애플리케이션과 A(초당 10MB쓰기 가능), B(초당 100MB 쓰기 가능) 가 있을 때
A 시스템에서 한번에 dirtypage를 100MB 동기화 하면 background 동기화 속도가 dirtypage 속도를 따라잡지 못해 성능에 영향을 줄 수 있다. 따라서 10MB 단위로 동기화할 수 있도록 설정하는 것이 좋다.
반면 B 시스템에서 한번에 dirtypage를 10MB 동기화 하면 오히려 자주 깨어나는 스레드가 성능을 저하시킬 수 있다. 따라서 100MB로 설정하는 것이 좋다.
'Study > DevOps' 카테고리의 다른 글
I/O 작업이 지나가는 관문, I/O 스케줄러 (0) | 2024.02.06 |
---|---|
DevOps - TCP 재전송과 타임아웃 (0) | 2024.02.02 |
DevOps - TCP Keepalive를 이용한 세션 유지 (0) | 2024.02.01 |
DevOps - TIME_WAIT 소켓이 서비스에 미치는 영향 (0) | 2024.01.29 |
DevOps - NUMA, 메모리 관리 새로운 세계 (1) | 2024.01.26 |