23.07.2014 Views

Lustre 1.6 Operations Manual

Lustre 1.6 Operations Manual

Lustre 1.6 Operations Manual

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

22.3 <strong>Lustre</strong> Performance Tips<br />

This section describes various tips to improve <strong>Lustre</strong> performance.<br />

22.3.1 Setting SCSI I/O Sizes<br />

Some SCSI drivers default to a maximum I/O size that is too small for good <strong>Lustre</strong><br />

performance. we have fixed quite a few drivers, but you may still find that some<br />

drivers give unsatisfactory performance with <strong>Lustre</strong>. As the default value is hardcoded,<br />

you need to recompile the drivers to change their default. On the other hand,<br />

some drivers may have a wrong default set.<br />

If you suspect bad I/O performance and an analysis of <strong>Lustre</strong> statistics indicates that<br />

I/O is not 1 MB, check /sys/block//queue/max_sectors_kb. If it is<br />

less than 1024, set it to 1024 to improve the performance. If changing this setting<br />

does not change the I/O size as reported by <strong>Lustre</strong>, you may want to examine the<br />

SCSI driver code.<br />

22.3.2 Write Performance Better Than Read Performance<br />

Typically, the performance of write operations on a <strong>Lustre</strong> cluster is better than read<br />

operations. When doing writes, all clients are sending write RPCs asynchronously.<br />

The RPCs are allocated, and written to disk in the order they arrive. In many cases,<br />

this allows the back-end storage to aggregate writes efficiently.<br />

In the case of read operations, the reads from clients may come in a different order<br />

and need a lot of seeking to get read from the disk. This noticeably hampers the read<br />

throughput.<br />

Currently, there is no readahead on the OSTs themselves, though the clients do<br />

readahead. If there are lots of clients doing reads it would not be possible to do any<br />

readahead in any case because of memory consumption (consider that even a single<br />

RPC (1 MB) readahead for 1000 clients would consume 1 GB of RAM).<br />

For filesystems that use socklnd (TCP, Ethernet) as interconnect, there is also<br />

additional CPU overhead because the client cannot receive data without copying it<br />

from the network buffers. In the write case, the client CAN send data without the<br />

additional data copy. This means that the client is more likely to become CPU-bound<br />

during reads than writes.<br />

22-4 <strong>Lustre</strong> <strong>1.6</strong> <strong>Operations</strong> <strong>Manual</strong> • September 2008

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!