Sandia National Laboratories

TEST1

(Phase 1)

Description:
Each test employed a single client writing (and reading) a single file to an increasing number of OST's.  This is a file-per-process test. The OST's are assigned in order such that a two stripe file will utilize both OST's on a single OSS. A four stripe file will utilize 4 OST's on two OSS's. Stripe size is limited by lustre to be the minimum of either the number of OST's configured in the file-system or 160 (in this test 56). 

Purpose:
One purpose of this test is to measure the ability of the client to source or put data. By providing a sink that should exceed the network bandwidth we should be able to determine if the client is a performance bottle-neck.

Performance

AVG PER OST Performance

AXES:
Y- MiB/sec aggregate transfer for each datapoint
X - <clients.stripe> constant client count of 1, increasing stripe count from 2-56.

Testing Parameters:
TEST CODE:    IOR
VERSION:    2.8.10
API:    POSIX
ACCESS:    file-per-process
MAX OST's:    56
MAX OSS's:    28

Observations:
For stripe counts between 2 and 16 the transfer rate increases quickly relative to the increase between stripe counts 16 and 56.
While the transfer rate increases more quickly between 2 and 16, the rate of increase is well below perfect scalability based on the initial two stripe OST performance. A two stripe write achieves a rate of approximately 144 MiB/sec. If the file-system scaled perfectly we would expect (based on the two stripe performance) a rate of approximately 1152 MiB/sec for a 16 stripe file. In actuality what we observed in testing is an average rate of  480 MiB/sec (an approximately 41% loss).
We noted that little increase is seen using stripe sizes in excess of 24.

Data in TABLE format

Raw Data

HOME

Next >>