Peter Braam wrote:
I'd just like to take one step back here for the reading problem -
let's keep it simple.
When we worked with DDN 8500 controllers we established that with
something like 10 reading threads reading 1MB chunks randomly from
OSTs we achieved the full bandwidth of the array.
Read-ahead probably only damages things at this point (but is very
important for reading smaller files).
Is testing with only 10 threads truly representative of the situation?
I recall from a previous message that they have 30 threads per ost so on
a ddn couplet that's 30*8 threads. I would assume that such a workload
would greatly randomize the io from the perspective of the ddn.
There are many users of the 9500 SATA arrays now, and it surprises me
that we don't have the OST survey graphs for these arrays. I believe
that someone from our staff is at work with Sandia to get one done.
This should show us the parameters to get full bandwidth at least when
the application reads at least X MB, where X is hopefully still 1 (if
not we have a nasty networking problem on our hands).
I would say that "playing" with the parameters (DDN settings, Lustre
read ahead etc) is almost certain to make things worse in these use
cases, and be highly confusing. Perhaps we should disable at least
the Lustre read-ahead stuff when we have the minimum sizes to reach
full bandwidth.
- peter -
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel
