<div dir="auto">Thanks Andreas ! </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Got a little update ! </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I have noticed, that I reach limit up to 17Gb/s per client in different benchmarks. </div><div dir="auto">If I use IOR I got on write: </div><div dir="auto"><br></div><div dir="auto">1 client - 15-17Gb/s (mpirun -np 64)</div><div dir="auto">2 client - 30-34Gb/s ( mpirun -np 128)</div><div dir="auto">3 client - 45-50Gb/s (mpirun -np 192)</div><div dir="auto">4 client - 60-67Gb/s (mpirun -np 256) </div><div dir="auto"><br></div><div dir="auto">Each client have 64 threads and runs all of them. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">If I use FIO benchmark on a directory, I reach 17Gb/s as a limit to, starts from —jobs=32 and iodepth=1. </div><div dir="auto"><br></div><div dir="auto">Is there a way to overpass this limit ? Is it depend on kernel properties? What parameters determine the throughput of a single client?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Thanks, </div><div dir="auto">Stepan</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Вт, 31 марта 2026 г. в 12:23, Andreas Dilger <<a href="mailto:adilger@thelustrecollective.com">adilger@thelustrecollective.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" dir="auto">On Mar 29, 2026, at 11:33, Stepan Beskrovnyy <<a href="mailto:bsm099@gmail.com" target="_blank">bsm099@gmail.com</a>> wrote:<br>
> Hello everyone! <br>
> <br>
> I made a bunch of self-tests about EC branch performance so far. <br>
<br>
Thank you for testing this code.  It is still under heavy development,<br>
so the performance is not the central focus yet.<br>
<br>
> About my network config, I got:<br>
> <br>
> 7 servers with Mellanox ConnectX-7 with 2x100G ports. <br>
> <br>
> Lustre topology: <br>
> 1 MGS/MDT server <br>
> 6 servers with 2 OSS <br>
> <br>
> At all 12 OSS’s and 1 MDT. All OSS sit on spdk raid0 of 8 nvme with big throughputput. <br>
> <br>
> Using EC 10+2 on cluster and 1M stripe pattern. <br>
> <br>
> ib_write/read work well between nodes, shows 100G per interface. All the packets send to prio3. <br>
<br>
So this would be about 6 x 2 x 100Gbit/s ~= 120 GB/s maximum network speed,<br>
but unclear what the storage throughput is.<br>
<br>
> But at IOR benchmark I got only 65Gib/s on read and write both(—posix.odirect, no caching). <br>
<br>
Note that O_DIRECT will perform better with larger IO sizes (8MiB+ or larger).<br>
<br>
> Network utilization due tests is only about 20%. <br>
> <br>
> How can I tune my configuration more ? Any Ideas? <br>
<br>
Have you tested the ISA-L assembly-optimized patches that were very recently<br>
added at the top of the EC patch series?  Those improve EC calculation speed<br>
from about 550MB/s up to 20GB/s for x86_64, so will improve performance very<br>
significantly for the EC calculation part.  Whether that is your bottleneck<br>
remains to be seen.<br>
<br>
> And another question, is there any way in Erasure Coding branch to choose parity-block OSS’s manually? <br>
<br>
Yes, later in the patch series there is a "failure_domain" configuration<br>
parameter added for OSTs that allows grouping OSTs into failure domains<br>
(as you see fit, whether per-OSS, per-failover pair, per-rack, etc.  The<br>
object allocator will not allocate multiple objects from the same failure<br>
domain for data or parity stripes into a raidset (e.g. 8+2 data+parity<br>
grouping of stripes).<br>
<br>
If the file is widely striped then it will be split into multiple raidsets<br>
with the requested geometry so that each raidset is independently recoverable,<br>
but allows using the full bandwidth of the storage.<br>
<br>
Cheers, Andreas<br>
---<br>
Andreas Dilger<br>
Principal Lustre Architect<br>
<a href="mailto:adilger@thelustrecollective.com" target="_blank">adilger@thelustrecollective.com</a><br>
<br>
<br>
<br>
<br>
</blockquote></div></div>