Download Linux for Your-Oct-2009 PDF

TitleLinux for Your-Oct-2009
TagsTypes Magazines/Newspapers
File Size35.7 MB
Total Pages116
Document Text Contents
Page 1

O

c
to

b
e
r 2

0
0
9


L
IN

U
X

F
O

R
Y

O
U


V

O
L
U

M
E

: 0
7
IS

S
U

E
: 8

Rs 100
ISSN 0974-1054

In case this DVD does not work properly, write to us at [email protected] for a free replacement.

CD Team
e-m

ail: cdteam
@

efyindia.com


Note: Any object
iona

ble
m

ate
ria

l, i
f f

ou
nd

o
n

th
e

dis
c,

is
un

inte
nde

d, an
d should be attributed to the complex nature of Internet data.

Re
co

m
m

en
de

d S
ys

tem
Re

qu
ire

me
nts

: P4
, 51

2MB
RAM

, DVD-R
OM Drive

Vol
um

e: 0
7

Iss
ue:

08

Oct
obe

r 20
09

Ins
tall

DV
D13.0

Thi
s re

lea
se

brin
gs

wit
h it

ma
ny

ma
jor

cha
nge

s, i
ncl

udi
ng

a

com
ple

tely
rew

ork
ed

col
lec

tion
of

X

pac
kag

es,
ma

jor
upg

rad
es

to t
he

des
kto

p e
nvi

ron
me

nts
(KD

E

ver
sio

n 4
.2.4

an
d X

fce
ve

rsio
n

4.6
.1),

a n
ew

.tx
z pa

cka
ge

form
at

wit
h m

uch
be

tter
co

mp
res

sio
n,

and
oth

er u
pgr

ade
s a

ll ar
oun

d.

VOLUME: 07 ISSUE: 8 October 2009 116 PAGES ISSUE# 81

Published by EFY—ISO 9001:2000 Certified

India INR 100
US $ 12
Singapore S$ 9.5
Malaysia MYR 19

Case Study: IDBI Banks its Mission-critical Apps on Open Source

T H E C O M P L E T E M A G A Z I N E O N O P E N S O U R C E

Fre
e D

VD

Sl
ac

kw
ar

e
13

.0

Try a Scheduler that’s
Desktop-optimised

Limited Set of Constructs in C?
GCC Fills the Gap

Extend Web Applications with
WebHooks

The Two Most Common
VPN Configurations

Setup OpenSolaris on the
Xen Hypervisor

Practices that Can Help You
Minimise Defects in Code

25 questions that are commonly asked.
Often they are not handled well.
Turn to page 22 for tips from a veteran on how to…

Page 58

the queue, the kernel first tries to enlarge an existing request by
merging the new request with one that is already in the queue.
If the request cannot be merged with an existing one, then the
new request will be assigned a position in the queue based on
several factors including the elevator algorithm (which we will
configure later).

First, let's check what the current queue length is and which
current IO scheduler the OS is using. To view the current queue
length, issue the following command:

# cat /sys/block/sda/queue/nr_requests

128

You can see that my current queue length is 128 requests.
Now I want to increase it to 170—let's do it using the echo:

# echo 170 > /sys/block/sda/queue/nr_requests

# cat /sys/block/sda/queue/nr_requests

170

To make it permanent, add the entry to the /etc/rc.local file.
[As a rule, keep in mind that anything under /sys can be made
permanent by using /etc/rc.local.]

Now, let's check which elevator (or I/O scheduler) algorithm
the OS is using by default:

# cat /sys/block/sda/queue/scheduler

noop anticipatory deadline [cfq]

On my system, it's cfg. Now the question is...

What is an I/O scheduler?
I/O schedulers control the way Linux handles reads and writes
to disks. Linux 2.6 includes a number of I/O schedulers—the
intention of providing these choices is to allow better
optimisation for different classes of workload.

Without an I/O scheduler, Linux follows FIFO (First In, First
Out). This could result in massive HDD thrashing—for example,
if one process is reading from one part of the disk and one
writing to another, the heads would have to seek back and forth
across the disk for every operation. The scheduler's main goal is
to optimise disk access times.

This is where I/O schedulers come into the picture.
Quoting the WlugWiki [www.wlug.org.nz/LinuxIoScheduler]
an I/O scheduler can use the following techniques to improve
performance:

Request merging—The scheduler merges adjacent requests
together to reduce disk seeking.
Elevator—The scheduler orders requests based on their
physical location on the block device, and it basically tries to
seek in one direction as much as possible.
Prioritisation—The scheduler has complete control
over how it prioritises requests, and can do so in a
number of ways
In addition to these, all I/O schedulers also take into

account resource starvation, which ensures requests to







be serviced.
Scheduler algorithms operate like elevators in buildings,

and are therefore also called elevators. As per The Red Hat
Enterprise Linux 5 IO Tuning Guide: “The algorithms used to
operate real-life building elevators make sure that it services
requests per floor, efficiently. To be efficient, the elevator
does not travel to each floor depending on which one issued
a request to go up or down, first. Instead, it moves in one
direction at a time, taking as many requests as it can until
it reaches the highest or lowest floor, then does the same
in the opposite direction. Simply put, these algorithms
schedule disk I/O requests according to which logical block
address on the disk they are targeted to. This is because the
most efficient way to access the disk is to keep the access
pattern as sequential (i.e., moving in one direction) as
possible. Sequential, in this case, means 'by increasing the
logical block address number'. As such, a disk I/O request
targeted for disk block 100 will normally be scheduled
before a disk I/O request targeted for disk block 200. This is
typically the case, even if the disk I/O request for disk block
200 was issued first.”

There are currently four types of schedulers available:
1. The no-op scheduler (noop)
2. The anticipatory IO scheduler (anticipatory)
3. The deadline scheduler (deadline)
4. The Complete Fair Queueing scheduler (CFQ)

The no-op scheduler
As the name suggests, ‘no-op’ actually does nothing—it simply
works in the FIFO manner. No configurable options are
available here. The I/O requests are sent in the same manner as
they are received, and it is left to the hardware to work on it. The
main goal is to conserve CPU cycles.

You can make no-op your IO scheduler as follows:

echo noop > /sys/block/sda/queue/scheduler

To make it your choice of I/O scheduler across reboots, edit
/boot/grub/grub.conf and append elevator=noop at the end of
the kernel line:

root (hd0,0)

kernel /vmlinuz-2.6.29.6-217.2.16.fc11.i686.PAE ro root=LABEL=Fedora rhgb quiet

elevator=noop

The anticipatory scheduler
I personally think this is the most optimistic of the schedulers. It
waits in anticipation that the next I/O request might be for the
next disk block, before moving to another location. The basic
idea is that the IO scheduler will wait for a certain short period
of time after catering to one I/O request and before going on to
the next I/O request. So if the next I/O request is for the next
disk block, it saves time in moving the head back to the same
location again. But this may also result in additional latency, if
the next I/O is not for the next disk block.

Switch to this scheduler as follows:

58 | OCTOBER 2009 | LINUX FOR YOU | www.LinuxForU.com

Admin | How To ____________________________________________________________________________________________________________

www.LinuxForU.com | LINUX FOR YOU | OCTOBER 2009 | 59

____________________________________________________________________________________________________________ How To | Admin

Page 59

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

Add elevator=anticipatory in the kernel line of /boot/grub/
grub.conf, if you want to make it your default.

But how can you tune it as per your needs? Well, the
primary tunables are under the /sys/block/sda/queue/iosched/
directory. Some common values that can be tuned are (the
values appear automatically under /sys/block/sda/queue/
iosched/ as soon as you change your elevator):

antic_expire – Here you can set the maximum amount of
time (in milliseconds) you anticipate a good read (one with
a short seek distance from the most recently completed
request) before giving up. For example, I can change the
antic_expire from the default 6 ms to 60 ms, as follows:
# cat /sys/block/sda/queue/iosched/antic_expire

6

# echo 60 > /sys/block/sda/queue/iosched/antic_expire

# cat /sys/block/sda/queue/iosched/antic_expire

60

You can make it permanent by adding the echo line in your
/etc/rc.local file.

read_expire – All the read and write IO requests are
processed in batches. So this parameter specifies the
time within which the read request must be fulfilled
or completed before it expires. The time is specified in
milliseconds.
# cat /sys/block/sda/queue/iosched/read_expire

125

# echo 250 > /sys/block/sda/queue/iosched/read_expire

# cat /sys/block/sda/queue/iosched/antic_expire

250

write_expire – they are equivalent to the above, for writes.
# cat /sys/block/sda/queue/iosched/write_expire

250

# echo 300 > /sys/block/sda/queue/iosched/read_expire

# cat /sys/block/sda/queue/iosched/antic_expire

300

The deadline scheduler
As the name suggests, here all the I/O requests have to be
fulfilled in a specified amount of time—before they expire.
So when an I/O request enters the queue, it is assigned some
time (in milliseconds), within which it has to be fulfilled before
the time expires, regardless of its targeted block device. The
same applies for the write requests. It will also specify how
the maximum number of read requests will be fulfilled before
switching to a write request.

In order to switch to this scheduler, use the following
command:

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

To make it permanent, add elevator=deadline in the kernel
line of /boot/grub/grub.conf.

And here are its tunables (located under the same /sys/
block/sda/queue/iosched/ directory):







read_expire – Here, when a read request first enters the
I/O scheduler, it is assigned a deadline that is the current
time plus the read_expire value, in milliseconds. And,
like before, I can change the default value for read_expire
from 500 ms to 444 ms:
# cat /sys/block/sda/queue/iosched/read_expire

500

# echo 444 > /sys/block/sda/queue/iosched/read_expire

# cat /sys/block/sda/queue/iosched/antic_expire

444

write_expire – As you might have already guessed, its
function is the same as read_expire, but it is for writes. The
time is again in milliseconds.
# cat /sys/block/sda/queue/iosched/write_expire

5000

# echo 4000 > /sys/block/sda/queue/iosched/read_expire

# cat /sys/block/sda/queue/iosched/antic_expire

4000

front_merges – Normally, I/O requests are merged at the
bottom of the request queue. This Boolean value controls
whether an attempt should be made to merge the request
to the top of the request queue. A value of 0 indicates that
the front merges are disabled.
# cat /sys/block/sda/queue/iosched/front_merges

1

The Completely Fair Queue scheduler (CFQ)
The CFQ scheduler works in a pure, democratic way. It
equally divides all the available bandwidth between all the
I/O requests. CFQ uses 64 internal queues to maintain and
keep I/O requests. It fills internal queues in a round-robin
manner and pulls the I/O requests from these 64 internal
queues and places them into a dispatch queue, where they
are catered to. Internally, CFQ also changes the order of I/O
requests to minimise the head movement.

Most Linux distros come with CFQ as the default I/O
scheduler. If not, make it the default as follows:

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

Append elevator=cfq to the kernel line of /boot/grub/grub.
conf to make the change permanent.

As for the tunables, they are:
quantum – This is the total number of requests to be moved
from internal queues to the dispatch queue in each cycle.
# cat /sys/block/sda/queue/iosched/quantum

4

# echo 8 > /sys/block/sda/queue/iosched/read_expire

# cat /sys/block/sda/queue/iosched/antic_expire

8

Here I just changed the number of requests to 8 from the
default value of 4. Feel free to use /etc/rc.local to make the
changes permanent.

queued – This is the maximum number of requests allowed
per internal queue. You can view and change the current value
using the cat and echo commands, respectively, as above.











58 | OCTOBER 2009 | LINUX FOR YOU | www.LinuxForU.com

Admin | How To ____________________________________________________________________________________________________________

www.LinuxForU.com | LINUX FOR YOU | OCTOBER 2009 | 59

____________________________________________________________________________________________________________ How To | Admin

Page 115

Vipul Mehra, General Manager, [email protected]
Tel: +91 11 4279 5000 / 5030 M: +91 99102 04131

Securing your Business

23-25 March 2010

International Exhibition & Conference
Pragati Maidan, New Delhi, India

South Asia’s largest ICT event
@

Supports

Department of Telecommunications
Ministry of Communications & Information Technology

Government of India

Department of Information Technology
Ministry of Communications & Information Technology

Government of India

Suppporting Journal Certified by

www.convergenceindia.org

Organiser

Clickjacking

Virtualisation

Info Security

Cloud Computing

Data Theft

IP Surveillance

Similer Documents