Deadline I/O Schduler?

날씨가 부쩍 추워졌다.

왠만하면 추워도 파카를 안입는 체질인데 아침부터 파카를 껴입었다.

아직 12월도 아닌데....제귈..조만간 털모자도 꺼내야겠다.

회사다니는데 있어 복장이 크게 중요치 않다고 느끼는 나인데. 요즘 복장이 너무나도 free해졌다...

헤헤....뭐 어쩔수 없다;;

아무튼 서론이 길었고 오늘은 무얼 가지고 놀까 아니...무얼 포스팅할까 고민하던중, I/O Schduler라는 놈이 땡겼다. 갑자기 왜? 이젠 소재도 고갈되어지나....쩝;;

아무튼 먼저 I/O Scheduler중 deadline이라는 놈을 알기전에 I/O Scheduler라는 녀석을 알필요가 있다.

간단하게 말하자면, I/O 스케줄러는 디스크 I/O 를 효율화하기 위한 하나의 기능인데, Kernel 2.6.10에서는 

deadline, noop, cfq, anticipatory 4 종류가 있고, 기본은 cfq 이다.

[dhkim@redhat ~]$ cat /sys/block/sda/queue/scheduler 

noop deadline [cfq]

OS 내에 있는 I/O scheduler 디자인을 결정하는 핵심 요소가 'throughput vs. latency(response time)'이라 가정한다면, 운영하는 서비스에서 특히 File I/O가 맞은 아키텍처에서는 튜닝 포인트 중에 하나라는 것도 알아두어야 할것이다. 

추가적으로, 커널은 운영체제의 핵심인 커널 I / O 스케줄링을 사용하여 디스크의 액세스 제어를 담당하기도 하는데, 여기서 RHEL은 대부분의 워크로드에게 우수한 성능을 제공하지만, 그것은 항상 리눅스 사용자 요즘에서 사용중인 응용 프로그램의 넓은 범위에 가장 적합한 I / O 특성을 제공하지 않기 때문에, 해당 튜닝포인트를 인지해야 한다는 것이다.

일단 여기서 다룰 deadline과 함께 다른 놈(?)도 소개하자면,

Completely Fair Queuing—elevator=cfq (default)

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

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

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

Anticipatory—elevator=as

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

중점으로 알아볼 deadline의 녀석의 자세한 내용은 kernel document에서 자세히 나와있다.

[dhkim@redhat ~]$ cat /usr/share/doc/kernel-doc-2.6.35.14/Documentation/block/deadline-iosched.txt 

Deadline IO scheduler tunables

==============================

This little file attempts to document how the deadline io scheduler works.

In particular, it will clarify the meaning of the exposed tunables that may be

of interest to power users.

Selecting IO schedulers

-----------------------

Refer to Documentation/block/switching-sched.txt for information on

selecting an io scheduler on a per-device basis

성능 benchmark에 대한 그래프를 통해서도 한눈에 확인이 가능하다.

또한 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)

설정방법은 여러가지가 있으나, 특히 RHEL6의 경우, tuned-adm 프로파일을 통해 간단하게 시스템환경에 따라 적용이 가능해졌다. 유후~~이런거 조아부러...

[dhkim@redhat ~]$ 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

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/main-analyzeperf-tuned.html

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)

또다른 적용방법으로는,

[dhkim@redhat ~]$ sudo cat /etc/grub.conf 

title Fedora (2.6.35.14-103.fc14.i686)

root (hd0,5)

kernel /vmlinuz-2.6.35.14-103.fc14.i686 ro root=UUID=c777a865-ee0b-41b0-ac4f-fa0eb5b3286e rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=ko_KR.UTF-8 KEYTABLE=us rhgb quiet elevator=deadline

[dhkim@redhat ~]$ echo deadline > /sys/block/sda/queue/scheduler 

noop [deadline] cfq

두개의 방법중 가능하나, 아래방법은 소멸성으로 리부팅하게되면 설정정보가 사라지니 염려해두자.

더 나아가 deadline 튜닝설정방법은 다음 항목이 있으니 참고하자

Deadline Tunables

- fifo_batch

- writes_starved

- front_merges

- read_expire

- write_expire

- writes_starved

$ ls /sys/block/sda/queue/iosched

fifo_batch          def:   16

front_merges        def:    1 (enabled)

read_expire         def:  500ms

write_expire        def: 5000ms

writes_starved      def:    2

나의 경우 위 항목을 설정후, 아래와 같이 테스트를 거쳤다.

* 설정

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

위 내용보다 자세한 설명은 아래 URL을 통해 참고할수 있다.

http://lwn.net/Articles/21274/

종합적으로.

나름 생각나는 대로 적어보았으나, 뭐 알맹이가 없는거 같아 마음이 쓰리다.

뭐 상세히 아는게 없으니, 나의 두뇌를 탓할수 밖에 없구나.....유유;;