[gpfsug-discuss] GPFS 5.1.9.4 on Windows 11 Pro. Performance issues, write.
Uwe Falke
uwe.falke at kit.edu
Wed Sep 4 15:46:32 BST 2024
On 04.09.24 15:59, Henrik Cednert wrote:
> Thanks Uwe
>
> I will have to digest what you write for a while, at this time of day
> some of it flies over my head (...and some probably will no matter the
> time of day). =)
>
> But to add some info about the file system.
>
> File system attributes for /dev/mmfs1:
> ======================================
> flag value description
> ------------------- ------------------------
> -----------------------------------
> -f 8192 Minimum fragment
> (subblock) size in bytes (system pool)
> 131072 Minimum fragment
> (subblock) size in bytes (other pools)
> -i 512 Inode size in bytes
> -I 32768 Indirect block size in bytes
> -m 2 Default number of
> metadata replicas
> -M 2 Maximum number of
> metadata replicas
> -r 1 Default number of data
> replicas
> -R 2 Maximum number of data
> replicas
> -j scatter Block allocation type
> -D nfs4 File locking semantics in
> effect
> -k nfs4 ACL semantics in effect
> -n 32 Estimated number of nodes
> that will mount file system
> -B 524288 Block size (system pool)
> 8388608 Block size (other pools)
>
>
> Regarding,
> >The iohist snippet for reads comprises 74 IOs in about 0.854s, this
> relates to roughly 690MiB/s, far from the 10-fold value you reported.
>
> I'm not sure about that 10-fold value you refer to here. 690MiB is
> pretty much exactly what I saw reported in the disk speed test I was
> running when extracting that data.
I referred to numbers like in
> Job: seqrw-10gb-1mb-t4
> • Write: 549 MB/s (7 ms)
> • Read: 6987 MB/s (1 ms)
was I mistaken ?
>
>
> I will re-run my fio-tests on the other systems so that I have fresh
> values. If I'm sure that they are trustworthy...? Can one ever be?
> Network graphs and reported fio results are all I have to lean
> against. Attaching a few lines of --iohist for one of those 10GbE
> clients that currently is running my batch fio test.
>
> <--------------------------------------snip------------------------------------>
There is always bit of uncertainty but one could try to minimize that
and also look for signs of it. Caching effects are prone to be a vivid
source of errors in benchmarks. I am not sure we have it here but
thought there are serious indicators. but i might have mixed up your
tests.
also I see you do not run concurring reads and writes , but just read or
write tests at a time.
but it remains from your waiters list: GPFS doesn't seem to be (held)
busy (by the test app). If there are 74 IO requests in 0.85secs each one
taking less than 6ms that accounts for less than just 0.444s -- about
half of the time GPFS is idling. with full IO queues you should see at
least about 1.3GiB/s (which is still not 3, but would be better than
what you had now). But the next thing to explore is: while many read IOs
take about 5..6ms (mind: that is supsiciously low!) what is causing the
others to take 20..40ms (or even more). You could also check the
iohistory on the NSD servers where you'd see the times it takes the IO
requests issued by the NSD server against the storage backend. But you
should not post the output. You may send the output as an attachment
(but maybe not to the entire mailing list :-).
Can you start your tests with multiple threads (or maybe multiple tests
in parallel)?
Uwe
--
Karlsruhe Institute of Technology (KIT)
Scientific Computing Centre (SCC)
Scientific Data Management (SDM)
Uwe Falke
Hermann-von-Helmholtz-Platz 1, Building 442, Room 187
D-76344 Eggenstein-Leopoldshafen
Tel: +49 721 608 28024
Email:uwe.falke at kit.edu
www.scc.kit.edu
Registered office:
Kaiserstraße 12, 76131 Karlsruhe, Germany
KIT – The Research University in the Helmholtz Association
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20240904/a6dc44b7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5814 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20240904/a6dc44b7/attachment-0001.bin>
More information about the gpfsug-discuss
mailing list