마감 스케줄러
Deadline scheduler마감 스케줄러는 Jens Axboe가 2002년에 작성한 Linux 커널의 I/O 스케줄러다.
개요
![]() |
마감 스케줄러의 주요 목표는 요청에 대한 시작 서비스 시간을 보장하는 것이다.[1]그것은 요청의 기아를 방지하기 위해 모든 I/O 운영에 기한을 부과함으로써 그렇게 한다.또한 정렬된 대기열(읽기와 쓰기 모두) 외에 두 개의 마감 대기열을 유지한다.마감 대기열은 기본적으로 마감일(만료 시간)에 따라 정렬되며, 정렬된 대기열은 섹터 번호에 따라 정렬된다.
다음 요청을 처리하기 전에 마감 스케줄러는 사용할 대기열을 결정한다.프로세스에서 일반적으로 읽기 작업을 차단하기 때문에 읽기 대기열에는 더 높은 우선 순위가 부여된다.다음으로, 마감 스케줄러는 마감 대기열의 첫 번째 요청이 만료되었는지 확인한다.그렇지 않으면 스케줄러는 정렬된 대기열에서 일괄 요청을 처리한다.두 경우 모두 스케줄러는 정렬된 대기열에서 선택한 요청에 따른 일괄 요청을 처리한다.
기본적으로 읽기 요청의 만료 시간은 500ms이고 쓰기 요청은 5초 후에 만료된다.
스케줄러의 초기 버전은 2002년 1월에 Jens Axboe에 의해 출판되었다.[2]
측정 결과 특정 다중 스레드 워크로드의 경우 마감 I/O 스케줄러가 CFQ I/O 스케줄러를 능가하는 것으로 나타났다.[3]
sysfs 튜너블
fifo_filency (filo_filency)
마감일은 섹터 수 증가 측면에서 발주된 일련의 작업인 "배치" 개념을 통해 I/O 운영(IOPs)을 실행한다.이 튜닝 가능은 요청이 디스크에 대기하기 전에 배치의 크기를 결정한다(현재 구축되고 있는 배치의 만료 제한).배치 크기가 작을수록 새로운 요청이 더 빨리 실행되도록 보장하여 지연 시간을 줄일 수 있지만(요청이 더 많이 들어오기를 기다리는 것이 아니라) 드라이브 헤드의 전체 이동을 증가시킴으로써 전체 처리량을 저하시킬 수 있다.또한, IOP의 수가 충분히 많으면, 배치는 어쨌든 적시에 실행될 것이다.
read_message (read)
'read_expire' 시간은 읽기가 '만료된' 것으로 간주되는 최대 시간(밀리초)이다.이것을 우유팩의 유통기한처럼 더 생각해봐.우유는 유통기한 전에 사용하는 것이 가장 좋다.마감 스케줄러도 마찬가지야.모든 IO가 만료일 전에 발급되도록 시도하지 않는다.하지만 입출력이 만료되면 우선 순위가 뒤틀린다.주의하여
읽기 만료 대기열은 마감 스케줄러가 읽기 대기열을 재평가할 때만 확인된다.읽기는 스트리밍 io의 경우를 제외하고 정렬된 읽기가 전송될 때마다 이 값을 의미한다.스케줄러가 읽기 대기열에서 io를 스트리밍하는 동안 읽기 만료는 평가되지 않는다.읽기 대기열을 재평가할 때 논리는
만료된 읽기 확인(FIFO [시간 순서] 대기열의 헤드 참조) 캐시된 읽기 포인터가 유효한지 확인(그래서 스트리밍하지 않더라도 캐시된 포인터가 여전히 우선하므로 정렬된 대기열이 스위프에서 꼬리로 이동됨) 만료된 읽기가 있는 경우 정렬된 대기열에서 첫 번째 읽기를 선택하십시오(다른 스위프를 위해 팁에서 다시 시작).그리고 나서 첫 번째 것은 FIFO에서 뽑힌다.이 만료된 읽기는 읽기 정렬 순서의 새로운 넥서스라는 점에 유의하십시오.캐시된 다음 포인터는 이 포인터가 만료된 후 정렬 대기열에서 다음 io를 가리키도록 설정된다.주목할 점은 알고리즘이 만료된 모든 io를 만료일이 지나면 실행만 하는 것이 아니라는 것이다.이를 통해 만료된 읽기 대기열을 다시 점검하기 전에 'write_starved' 정렬된 읽기를 함께 일괄 처리하여 합리적인 성능을 유지할 수 있다.
따라서 읽기 만료된 io 간에 수행할 수 있는 최대 IO 수는 2 * 'fifo_batch' * 'writes_starved'이다.한 세트의 'fifo_batch' 스트리밍은 첫 번째 read io가 만료된 후 읽으며, 만약 이 스트림이 쓰기 부족 상태를 야기한다면, 또 다른 'fifo_batch' 스트리밍 쓰기가 가능하다.이것은 더 나쁜 경우로서, 그 후에 읽기 만료 대기열이 재평가될 것이다.기껏해야 만료된 읽기 대기열은 쓰기 대기열이 사용되기 때문에 건너뛰기 전에 연속적으로 'write_starved' 시간을 평가한다.
write_properties(필수)
read_expire와 동일하지만 쓰기 작업용(읽기와 별도의 배치로 그룹화됨)
writs_properties(필수)
앞서 언급했듯이 마감일은 쓰기보다 읽기를 선호한다.결과적으로, 이는 운영이 거의 완전히 읽히는 상황을 초래할 수 있다.write_expire가 길거나 전체 대역폭이 포화 상태에 가까워짐에 따라 이는 더욱 중요한 조정 가능 상태가 된다.이를 줄이면 읽기 작업을 희생하면서 쓰기(상대적으로 말하기)에 더 많은 대역폭이 생긴다.그러나 애플리케이션 워크로드가 읽기 집약적인 경우(예: 대부분의 HTTP 또는 디렉터리 서버) 이를 늘리면 평균 IOP의 지연 시간을 줄일 수 있다(쓰기 배치를 디스크에 대기열에 넣기 전에 더 많은 읽기를 수행해야 함).
front_messes(bool 정수)
"프론트 병합"은 소규모 요청을 더 적은 (더 많은) 작업으로 응축(또는 "merge")하려는 I/O Scheduler가 새로운 작업을 취한 후 활성 배치를 검토하여 시작 섹터가 동일하거나 다른 작업의 시작 섹터 직후에 작업을 찾으려고 시도하는 작업이다."백 병합"은 정반대로, 활성 배치의 엔딩 섹터가 현재 운영 개시 섹터와 동일하거나 직후인 섹터를 검색한다.합치는 작업을 현재 배치에서 활성 배치로 전환하여 처리량을 증가시키기 위해 "공정성"을 감소시킨다.
파일이 일반적으로 배치되는 방식 때문에 백 병합은 전면 병합보다 훨씬 일반적이다.일부 워크로드의 경우 병합 요청을 처리하려고 하면 시간 낭비라는 사실을 알고 있을 수 있다.front_merges를 0으로 설정하면 이 기능이 비활성화된다.전면 병합은 캐시된 last_merge 힌트로 인해 여전히 발생할 수 있지만, 기본적으로 0원가가 되기 때문에 여전히 수행된다.이 부울은 I/O 스케줄러 병합 기능이 호출될 때 단순히 전면 섹터 조회를 비활성화한다.디스크 병합 합계는 /proc/diskstats에 블록 단위 장치당 기록된다.[1]
기타 I/O 스케줄러
참조
- ^ a b Jens Axboe (11 November 2002). "Deadline I/O scheduler tunables". Linux kernel documentation. Retrieved 20 November 2011.
- ^ Jens Axboe (4 January 2002). "[PATCH][RFT] simple deadline I/O scheduler". Linux Kernel Mailing List Archive. Retrieved 6 July 2014.
- ^ IBM (12 September 2013). "Kernel Virtual Machine (KVM) Best practices for KVM" (PDF). IBM. Retrieved 6 July 2014.[영구적 데드링크]