Il 2020-11-27 09:40 Amar Tumballi ha scritto:
Let's get to longer look into performance:
Amar, Xavi, thanks for your input - very appreciated.
However, I found that when facing sync writes (ie: fsync) gluster
performances are very low - too much for a kernel/syscall overhead.
For more information you can read here:
https://lists.gluster.org/pipermail/gluster-users/2020-January/037601.html
Short summary: with RAM disk based bricks I got ~250 IOPs when
replicating a 2-way test cluster via 1 Gb/s ethernet, and at most
500-600 IOPs when running two RAM disk bricks inside the same host (so
excluding both disk and network overhead).
When not using fsync I was capped by glusterd taking 100% of a single
CPU core (at about 5500 IOPs, which is not bad on the ancient machine I
used for testing).
Any suggestion on how to improve fsync speed?
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
________
Community Meeting Calendar:
Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users
