3

I have two programs that write to my servers disk.

One I wrote, it does linear writes, it's writing data quickly. Another I'm benchmarking, it's writing data at a 3rd of the speed. It doesn't do much else, and I believe the problem is caused by the second program seeking more (i.e. it does more random file access).

Is there a tool on Linux I can use to determine the number of seeks being performed on a particular disk? Or by a particular process?

new299
  • 133
  • 3

3 Answers3

0

This tool might help you http://sourceforge.net/projects/hdparm/ - i have used this in the past with some success. The other tools which can give you a benchmark is iometer. Iostat is another tool but that might not show you processes and this tool might also help http://www.atoptool.nl/. Hope that helps!

Oli
  • 418
  • 4
  • 15
0

For determining the number of seek calls per process you can use strace and search for every interesting system call (fseek(o), lseek(64), llseek etc.). Better just grep for seek to see which functions are called by that particular process.

Examples:

lseek(3, -1467, SEEK_CUR)               = 842

The file opened via file descriptor 3 is set to -1467 bytes from the current position, resulting in a new position of 842 bytes.

lseek(12, 40267, SEEK_SET)              = 40267

The file opened via file descriptor 12 is set to the total position of 40267 bytes resulting in a new position of 40267 bytes (which equals success as both numbers are the same).

scai
  • 2,269
  • 2
  • 13
  • 16
0

Perhaps it might be revealing to look at the load impact and behaviour of the storage system:

iostat -x 1

There are several values of interest there:

  • avgrq-sz describes the size (in sectors) of requests sent to the disk
  • avgqu-sz shows the length of this queue (think no. of transactions)
  • await displays the time spent waiting for device access (until the device starts processing the request)
  • svctm shows the time the device spent to satisfy the requests

In your case, request size should go up for your description of linear writes, while queue length and device utilization should stay medium to low. In your second case of more random access patterns the request size should stay lower but the queue size, access wait and utilization should go up.

Depending on the access patterns it might make sense to tune /proc/sys/vm/dirty_writeback_centisecs or the /proc/sys/vm/dirty_background_ratio, but this depends on the amount and pattern of data moved (just to give you a pointer of where the tune-ables for the page cache/write cache are).

phs
  • 103
  • 4
byteborg
  • 111
  • 3
  • While `iostat` can give you rough guesses, it does not show the real number of disk seeks the hardware is doing. See also http://stackoverflow.com/questions/37083324/linux-monitor-number-of-disk-seeks-per-second – nh2 Dec 10 '16 at 20:22