Hi,
As part of identifying performance bottlenecks within gluster stack for VM image store use-case, I loaded io-stats at multiple points on the client and brick stack and ran randrd test using fio from within the hosted vms in parallel.3 FUSE clients, one per node in the cluster (which implies reads are served from the replica that is local to the client).
io-stats was loaded at the following places:Translator Position Avg Latency of READ fop as seen by this translator
1. parent of client-io-threads 1666us
∆ (1,2) = 50us
2. parent of protocol/client-0 1616us
∆ (2,3) = 1453us
----------------- end of client stack ---------------------
----------------- beginning of brick stack -----------
3. child of protocol/server 163us
∆ (3,4) = 7us
4. parent of io-threads 156us
∆ (4,5) = 20us
5. child-of-io-threads 136us
∆ (5,6) = 11us
6. parent of storage/posix 125us
...
...
---------------- end of brick stack ------------------------
So it seems like the biggest bottleneck here is a combination of the network + epoll, rpc layer?
I must admit I am no expert with networks, but I'm assuming if the client is reading from the local brick, then
even latency contribution from the actual network won't be much, in which case bulk of the latency is coming from epoll, rpc layer, etc at both client and brick end? Please correct me if I'm wrong.
I will, of course, do some more runs and confirm if the pattern is consistent.
-Krutika
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel