Performance problem - reads slower than writes
Christoph Hellwig
hch at infradead.org
Tue Jan 31 08:52:05 CST 2012
On Tue, Jan 31, 2012 at 10:31:26AM +0000, Brian Candler wrote:
> - seek to inode (if the inode block isn't already in cache)
> - seek to extents table (if all extents don't fit in the inode)
> - seek(s) to the file contents, depending on how they're fragmented.
>
> I am currently seeing somewhere between 7 and 8 seeks per file read, and
> this just doesn't seem right to me.
You don't just read a single file at a time but multiple ones, don't
you?
Try playing with the following tweaks to get larger I/O to the disk:
a) make sure you use the noop or deadline elevators
b) increase /sys/block/sdX/queue/max_sectors_kb from its low default
c) dramatically increase /sys/devices/virtual/bdi/<major>:<minor>/read_ahead_kb
> OK. I saw "df -i" reporting a stupid number of available inodes, over 500
> million, so I decided to reduce it to 100 million. But df -k didn't show
> any corresponding increase in disk space, so I'm guessing in xfs these are
> allocated on-demand, and the inode limit doesn't really matter?
Exactly, the number displayed is the upper bound.
More information about the xfs
mailing list