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
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
