Personal tools
You are here: Home Personal My Blog Fedora 10 - Disk IO

Fedora 10 - Disk IO

— filed under: , , , , ,
by Harald Hoyer last modified Dec 02, 2008 17:54

Identifying heavy disk IO tasks and reducing IO helps to shorten the boot time on e.g. a Asus EeePC.

Identifying heavy disk IO tasks and reducing IO helps to shorten the boot time on e.g. a Asus EeePC.

To measure IO, I installed a systemtap script to run as soon as rc.sysinit starts.

#! /usr/bin/env stap
# modified traceio.stp
# Copyright (C) 2007 Red Hat, Inc., Eugene Teo <eteo@redhat.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#

global device_of_interest, dev, reads, writes, total_io

probe begin {
  /* Hack! Insert your MAJOR, MINOR of the 
     device you are interested in */
  device_of_interest = MKDEV(253, 1)
}

probe vfs.read.return {
        if (dev == device_of_interest)
        reads[execname()] += $return
}

probe vfs.write.return {
        if (dev == device_of_interest)
        writes[execname()] += $return
}

probe timer.s(1) {
    foreach (p in reads)
        total_io[p] = 0
    foreach (p in writes)
        total_io[p] = 0
    foreach (p in reads)
        total_io[p] += reads[p]
    foreach (p in writes)
        total_io[p] += 5 * writes[p]
    foreach(p in total_io- limit 10)
        printf("%15s r: %8d KiB w: %8d KiB\n",
            p, reads[p]/1024,
            writes[p]/1024)
        printf("\n")
    # Note we don't zero out reads, writes,
    # so the values are cumulative since the script started.
}

Because on a EeePC disk writes are very slow (5 times slower than reading) they are weighted with factor 5.

From rc.sysinit start to the gdm login screen, the top 5 IO tasks are on my Live-CD standard installation:

Name Read KiB Write KiB
modprobe 5900 0
gconfd-2 4827 47
setroubleshootd 4187 0
xkbcomp 2961 81
rpcbind 3248 0

 

Now, if you want to improve Fedora's boot speed, here is a starting point.

Document Actions
  • Print this
  • Hits: 010444

boot times

Posted by peter at Dec 15, 2008 09:42
Every review I have read of f10 mentions it boots quicker. On my computer it boots quicker than Vista, now.

Keep up the good work!

Script Tweaks

Posted by Will Cohen at Dec 16, 2008 17:55
Excellent application of systemtap! A couple things to make the script more efficient and less hardcoded:

-use command line to pass in options: $1 device number and $2 relative write cost
-delete total_io rather than use foreach loops

something like the following.

-Will

#! /usr/bin/env stap
# modified traceio.stp
# Copyright (C) 2007 Red Hat, Inc., Eugene Teo <eteo@redhat.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# arguments:
# $1 device number
# $2 relative cost of write
#
# Example how to run this script:
# stap dio.stp `stat -c '0x%D' /` 5
#

global device_of_interest, dev, reads, writes, total_io

probe begin {
  /* Device number can be obtained with "stat -c '0x%D' filesystem" */
  device_of_interest = usrdev2kerndev($1)
}

probe vfs.read.return {
        if (dev == device_of_interest)
        reads[execname()] += $return
}

probe vfs.write.return {
        if (dev == device_of_interest)
        writes[execname()] += $return
}

probe timer.s(1) {
    delete total_io
    foreach (p in reads)
        total_io[p] += reads[p]
    foreach (p in writes)
        total_io[p] += $2 * writes[p]
    foreach(p in total_io- limit 10)
        printf("%15s r: %8d KiB w: %8d KiB\n",
            p, reads[p]/1024,
            writes[p]/1024)
        printf("\n")
    # Note we don't zero out reads, writes,
    # so the values are cumulative since the script started.
}

Datafiles

Posted by Dennis Jacobfeuerborn at Dec 17, 2008 09:12
What I would like to see is a script that logs which files the processes actually open/close and how much data they read/write from/to them. That would make it easier to detect abnormal patterns such as wasteful opening of whole directories of files or repeated opening of the same files.
I guess that would have to be a two step process. In the first step the opening/reading/writing/closing of inodes would have to be logged and in the second step a script would have to find the files the inodes correspond to.

Script that records io on particular files

Posted by Will Cohen at Dec 17, 2008 17:04
The following URL is a script in the systemtap examples that records the amount of data read and written for each file opened:

http://sourceware.org/systemtap/examples/io/iotime.stp

It works on a file names rather than inodes. However, it might be a starting point.


-Will

I/O Time

Posted by Harald Hoyer at Dec 17, 2008 17:08
Careful with the interpretation of the time. Time might go up with parallel I/O happening in the background by other processes or just ext3 write commits.

random / sequential

Posted by Andreas at Jan 12, 2009 14:52
i think a huge improvement could be made by reading whatever data is needed sequentially. random i/o will kill your performance.

And so?

Posted by Jim (JR) at Jan 14, 2009 10:47
As a Linux / Fedora user (make that read pretty darn competent user, but *not* a developer!), what does this tell me? What "starting point"? Where? The closest I can figure this is that this is the end-product of a Pareto (80/20) analysis, and this is the 20% of the problem that will give me 80% (+?) of the return.

But knowing that, by itself, doesn't buy me much.

Am I supposed to go in and do a full-court-press code review on setroubleshootd or re-compile modprobe?

Now, I already know this isn't Windows (or Mac), and I shoudn't expect miracles to just fall out of the sky into my lap, but simply pointing to a haystack and saying "the solution is in there SOMEWHERE doesn't help much.

Can you help clarify for those of us who may want to use this information, but are not sure where to go with it?

Thanks!

Jim