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
|
