달력

22025  이전 다음

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28

[Tip] I/O Scheduler Configuration(cfq, deadline)

 

[I/O Scheduler]

하드디스크에 최적화된 블럭 디바이스 스케줄링 알고리즘을 의미한다.

SATA controller 또는 일반적인 HDD disk의 controller를 이용하는 SSD 제품의 경우, NOOP를 선택하면 탁월한 성능 향상이 있다.

 

[I/O Scheduler 종류]

Completely Fair Queuing (CFQ)

- 기본 I/O scheduler

- 기본적인 스케줄러이며, 말그대로 기본적으로 사용되어지기 때문에 균등하게 배분하게 예약을 하며, 많은 프로세스들이 세세한 I/O을 많이 발생시킬때 사용되어 진다.

- CFQ 스케줄러는 광범위한 응용 프로그램과 I/O 시스템 설계에 최상의 성능을 제공하기 때문에 기본 스케줄러로 선택이 되었다. 16개의 CPU를 가지고 있고, Ultra SCSI와 Fiber channel로 구성된 2~64개의 LUN을 가진 시스템에서 CFQ는 탁월한 성능을 발휘한 것으로 알려져 있다. 게다가 CFQ는 다른 I/O subsystem의 성능과 일치할 수 있도록 /proc/sys/scsi subsystem에 있는 nr_requests 파라미터를 조정하여 쉽게 최적화 할 수 있다.

- CFQ(Complete Fair Queuing)는 각 프로세스 마다 작업 큐를 가지고 있고 이것들이 round robin방식으로 돌며 정해진 time slice 내에서 작업을 수행하게 된다. Time slice안에 작업을 모두 끝내게 되어도 10ms 정도를 추가로 기다리며 혹시나 있을 I/O 작업을 대기하다가 안들어오면 다른 프로세스의 큐로 이동한다. 각 큐에서는 synchronous 요청이 asynchronous보다 우선순위를 가지고 진행되어 writes-starving-reads 문제를 해결한다.

 

Deadline

- I/O대기시간의 한계점(deadline)을 마련하고, 가까운 I/O부터 처리하는데, 처리량이 많은 데이타보다, 지연에 최적화된 스케줄러이다. 이때문에, 몇몇 많은 프로세스 I/O을 발생시키는 환경에 적합하며, 대체적으로 데이타베이스, KVM 등 환경에 많이 사용되어 진다.

- Deadline 스케줄러는 real-time 같은 single I/O 처럼 연속된 read를 빠르고 효율적으로 처리하기 위하여 대기 시간을 가지는 방식이다. Single I/O 환경에서는 빠르지만 multip HBA 또는 파일시스템간의 트랜젝션에는 항상 최상의 선택이 될 수는 없다.

- Linux Elevator의 작업 큐외에 별도의 read/write 큐를 둔다. 작업 큐에는 요청이 block 번호 순서로 정렬되어 있고, read/write큐는 FIFO로 (요청 들어온 순서대로) 들어간다. I/O Scheduler는 작업 큐에 정렬된 요청들을 가지고 작업을 하다가 expiration time에 넘은 요청이 발견되면 그 요청을 가지고 있는 read(혹은 write)큐에가서 작업을 진행한다. 일반적으로 read 큐는 expiration time이 500ms로 짧고 write 큐는 5초정도로 준다.

 

Anticipatory

- 추천 대상

제한된 I/O 설정을 가지고 있는 경우

1 또는 2개의 LUN만 가지고 잇는 작은 시스템

I/O 대기시간 보다 대화형 응답시간에 우선권을 주는 것이 유리할 경우 (대부분의 workstation들..)

- 일반적인 하드디스크와 처리방식이 비슷한데, 입출력을 모아서 한꺼번에 처리하는 성향으로 인해 지연시간의 경우 degraded될수 있다는 점 유의하자.

- 연속된 부분의 read 요청의 경우 디스크의 헤더는 이미 다른 위치로 이동해 있는 상태에서 다시 이전의 위치로 이동하여 작업을 수행하게 되는 낭비가 있다. 때문에 연속적인 read를 위해 한번의 read가 마쳐지면 최대 6ms 까지 아무일도 수행하지 않고 (헤드의 위치를 이동하지 않고) 대기해서 연속적인 read작업시 시간을 아끼는 방식의 스케쥴링을 anticipatory I/O scheduler라고 한다.

 

NOOP

- 주로 rawdevice환경을 사용하는  DBMS 그리고, SSD와 같이 반도체디스크형태일 경우 사용하게 되는데 즉 아무것도 하지 않는 스케줄러로써, 부하를 줄일수 있다는 거다.

- 블럭 번호 순으로 정렬은 하지 않고 merging만 하는 스케쥴러 이다. Hard Disk 방식의 controller (sata/sas)를 사용하는 SSD의 경우, 이 방식을 선택하도록 한다.

- 별도 controller를 가지고 있을 경우, driver단에서 이미 최적화 알고리즘을 가지고 있기 때문에 신경쓸 필요 없음. (예.. Fusion IO)

 

[설정]

- 파라미터 변경 -

# echo deadline > /sys/block/sda/queue/scheduler

noop [deadline] cfq

-> 설정 후 재 부팅 고려하여, /etc/rc.local 등에 설정

- tuned-adm 설정 -

 

# tuned-adm list

Available profiles:

- enterprise-storage

- laptop-ac-powersave

- default

- server-powersave

- desktop-powersave

- spindown-disk

- latency-performance

- laptop-battery-powersave

- throughput-performance

Current active profile: enterprise-storage

 

 

Example Use Cases    default profile    enterprise-storage    latency-performance    throughput-performance    virtual-guest    virtual-host

    Most Workloads    Databases    Network latency-sensitive    Databases    KVM Guests    KVM Hosts

        Oracle OLTP, IBM DB2    CPU-bound workloads           

        PostgreSQL, MySQL    Sybase ASE           

        SAS (in guests too) (THPoff where SAS runs) (elevate readahead more 4-16K)               

 

 

[테스트 방법]

* 설정

mkdir /tmp/test1;

mkdir /tmp/test2;

mkdir /tmp/test3;

mkdir /tmp/test4;

mkdir /tmp/test5;

time dd if=/dev/zero of=/tmp/test1/file.t bs=1024k count=2000;

time dd if=/dev/zero of=/tmp/test2/file.t bs=1024k count=2000;

time dd if=/dev/zero of=/tmp/test3/file.t bs=1024k count=2000;

time dd if=/dev/zero of=/tmp/test4/file.t bs=1024k count=2000;

sync;

 

* 테스트

cat /sys/block/sda/queue/iosched/fifo_batch;

cat /sys/block/sda/queue/iosched/writes_starved;

cat /sys/block/sda/queue/iosched/read_expire;

cat /sys/block/sda/queue/iosched/write_expire;

echo 3 > /proc/sys/vm/drop_caches;

sync;

sync;

sleep 5;

iostat 10 30 -t -k -x >& ./iostat-test.log &

top -b -d 10 -n 30    >& ./top-test.log &

vmstat 10 30          >& ./vmstat-test.log &

time dd if=/tmp/test1/file.t of=/dev/null bs=64k &

time dd if=/tmp/test2/file.t of=/dev/null bs=64k &

time dd if=/tmp/test2/file.t of=/dev/null bs=64k &

time dd if=/tmp/test4/file.t of=/dev/null bs=64k &

time dd if=/dev/zero         of=/tmp/test5/file.t bs=64k count=32002

time sync

 

[성능비교]

deadline Schduler I/O Logic Flow는, 아래 형태를 따르는데, 상세한 건 구글링을 통해 찾아보자.

1. Streaming Logic

2A. Read Q Select Logic

2B. Write Q Select Logic

3. Request Select Logic (Generic: either read/write)

 

 

[참고사이트]

https://wiki.kldp.org/wiki.php/KernelScheduler

http://rhlinux.tistory.com/26#recentTrackback

 

 

 

Posted by 짜꾸미의골골몽
|