Professional Web Applications Themes

how do i find out my I/O? - UNIX Programming

Other than watching a file copy is there a way to test how much I/O i can do? or while a file is running test how much it has done per second or so....

  1. #1

    Default how do i find out my I/O?

    Other than watching a file copy is there a way to test how much I/O i can
    do? or while a file is running test how much it has done per second or so.


    Ryan Guest

  2. #2

    Default Re: how do i find out my I/O?


    "Ryan" <net> wrote in message
    news:d1fYb.695$..

     


    I can't figure out what you're asking. Can you try to be more specific.
    You might be looking for 'vmstat' or 'iostat' or you might be looking for
    'bonnie'. It's hard to tell because you're question is so poorly formed. Are
    you looking for a benchmark? Or are you looking for a way to get statistics
    of how much I/O the system is currently doing?

    DS



    David Guest

  3. #3

    Default Re: how do i find out my I/O?



    David Schwartz wrote:
     
    >
    >
    >
    > I can't figure out what you're asking. Can you try to be more specific.
    > You might be looking for 'vmstat' or 'iostat' or you might be looking for
    > 'bonnie'. It's hard to tell because you're question is so poorly formed. Are
    > you looking for a benchmark? Or are you looking for a way to get statistics
    > of how much I/O the system is currently doing?
    >
    > DS
    >
    >
    > [/ref]

    Well, I'll hazard a guess as to what the OP wanted and add
    my $0.02 to the conversation -

    By saying "watching a file copy" I presume the OP was interested
    in disk I/O. A simple file copy is likely to give
    erroneous results unless it spans a considerable portion
    of the disk.

    Disk I/O is limited by laws of physics. Meaning there
    is head movement (physical seek time)
    and rotational latency. On a single (non-mirrored)
    disk, the rotational latency can be computed
    from the RPM rating and assuming the average
    random write will be half a rotation away
    from the spot it needs to write.
    Thus a 7200 RPM disk (120 revs per second)
    or has a full rotation of about 8 ms and a half
    rotation of about 4 ms.
    Seek time, depends on how far apart on the
    disk the random I/O's are. Manufacturers
    quote "average seek" times on the order of
    6-8 ms. nowadays. Thus a random I/O can
    be considered to be about 10-12 ms in terms
    of the clock time it takes. Running at
    100% utilization, this equates to about 80-100
    I/O's per second. But I would not want
    to run a disk at 100% utilization for other reasons.
    This 10 ms. or so actually dwarfs the actual
    data transfer time.

    Note that this is almost a "worst case" scenario.
    -The O/S will buffer your I/O requests and resequence
    the physical read and writes to minimize seek time
    as much as possible.
    -If you are copying from A to B and the locations
    are fairly close together on the disk, i.e.
    in the same physical disk partition, the seek
    time will be smaller. (If you can guarantee
    that there is no other disk activity).
    -If you can guarantee the the free-block list
    is contiguous on the partition to which you
    are writing, the seek time should be almost
    neglible. If, at the same time, you read/write
    in large chunks, approximating almost what can
    fit on a single track, you may actually
    find the rotational latency decreasing.

    I use the 10 ms. rule of thumb for large,
    random access type of applications.
    (e.g. read customer records
    from a database, the next customer may be
    anywhere on disk).

    Mirrored disks are quicker on reads and slower
    on writes. Disk arrays with large non-volatile
    caches are a win all around since you effectively
    have no seek time and no rotational latency.
    Some of these have been measured to have an
    average latency of about 1-2 ms. and sustained
    I/O rates at 400 per second.

    Your mileage WILL vary, so I would suggest
    you write a simple utility which
    does random seeks on the raw disk and
    time a million or so operations.

    --

    "It is impossible to make anything foolproof because fools are so
    ingenious" - A. Bloch

    Nick Guest

  4. #4

    Default Re: how do i find out my I/O?



    Nick Landsberg wrote:
     
    > >
    > >
    > >
    > > I can't figure out what you're asking. Can you try to be more specific.
    > > You might be looking for 'vmstat' or 'iostat' or you might be looking for
    > > 'bonnie'. It's hard to tell because you're question is so poorly formed. Are
    > > you looking for a benchmark? Or are you looking for a way to get statistics
    > > of how much I/O the system is currently doing?
    > >
    > > DS
    > >
    > >
    > >[/ref]
    >
    > Well, I'll hazard a guess as to what the OP wanted and add
    > my $0.02 to the conversation -
    >
    > By saying "watching a file copy" I presume the OP was interested
    > in disk I/O. A simple file copy is likely to give
    > erroneous results unless it spans a considerable portion
    > of the disk.
    >
    > Disk I/O is limited by laws of physics. Meaning there
    > is head movement (physical seek time)
    > and rotational latency. On a single (non-mirrored)
    > disk, the rotational latency can be computed
    > from the RPM rating and assuming the average
    > random write will be half a rotation away
    > from the spot it needs to write.
    > Thus a 7200 RPM disk (120 revs per second)
    > or has a full rotation of about 8 ms and a half
    > rotation of about 4 ms.
    > Seek time, depends on how far apart on the
    > disk the random I/O's are. Manufacturers
    > quote "average seek" times on the order of
    > 6-8 ms. nowadays. Thus a random I/O can
    > be considered to be about 10-12 ms in terms
    > of the clock time it takes. Running at
    > 100% utilization, this equates to about 80-100
    > I/O's per second. But I would not want
    > to run a disk at 100% utilization for other reasons.
    > This 10 ms. or so actually dwarfs the actual
    > data transfer time.
    >
    > Note that this is almost a "worst case" scenario.
    > -The O/S will buffer your I/O requests and resequence
    > the physical read and writes to minimize seek time
    > as much as possible.
    > -If you are copying from A to B and the locations
    > are fairly close together on the disk, i.e.
    > in the same physical disk partition, the seek
    > time will be smaller. (If you can guarantee
    > that there is no other disk activity).
    > -If you can guarantee the the free-block list
    > is contiguous on the partition to which you
    > are writing, the seek time should be almost
    > neglible. If, at the same time, you read/write
    > in large chunks, approximating almost what can
    > fit on a single track, you may actually
    > find the rotational latency decreasing.
    >
    > I use the 10 ms. rule of thumb for large,
    > random access type of applications.
    > (e.g. read customer records
    > from a database, the next customer may be
    > anywhere on disk).
    >
    > Mirrored disks are quicker on reads and slower
    > on writes. Disk arrays with large non-volatile
    > caches are a win all around since you effectively
    > have no seek time and no rotational latency.
    > Some of these have been measured to have an
    > average latency of about 1-2 ms. and sustained
    > I/O rates at 400 per second.
    >
    > Your mileage WILL vary, so I would suggest
    > you write a simple utility which
    > does random seeks on the raw disk and
    > time a million or so operations.
    >
    > --
    >
    > "It is impossible to make anything foolproof because fools are so
    > ingenious" - A. Bloch[/ref]

    I agree, Nick. I think that for the PO, the bottom line is something
    like this:

    1. The total number of bits you can write to the disk is controlled
    by the amount of space it has.

    2. The total number of bits per second is limited (upper bounded)
    by the physics of the disk, as Nick observed.

    3. There is in general _no_ lower bound on the speed of IO.

    Speaking only for myself,

    Joe Durusau


    joe Guest

Similar Threads

  1. Using DW find to find tags not on page
    By ian@uaa in forum Macromedia Dynamic HTML
    Replies: 0
    Last Post: August 9th, 05:13 PM
  2. find(...
    By _mvm in forum Coldfusion - Advanced Techniques
    Replies: 2
    Last Post: July 20th, 04:35 PM
  3. trailing slash issue in Find.find
    By Jeff Mitchell in forum Ruby
    Replies: 0
    Last Post: August 23rd, 11:30 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

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 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139