Last modified: 2013-11-13 09:43:59 UTC
GlusterFS performance is not ideal sometimes.
Assuming that Ubuntu 12.04 is used, this would be about glusterfs 3.2.5-1ubuntu1. RedHat ticket (which is in NEEDINFO state) recommends to get more info by: - # gluster volume profile VOLNAME start - Run workload - # gluster volume profile VOLNAME info (Repeat this a few times while the workload is present on the volume) - gluster volume profile VOLNAME stop (once the workload is complete)
No. We're using the newest 3.3 from gluster debs.
Just to give an idea of how a bottleneck it is, even when issuing a zip -9 (slowest read/write possible with zip): 1801 root 20 0 444m 147m 1724 R 103 1.8 96:21.75 glusterfs 29831 nemobis 20 0 20640 11m 712 S 42 0.1 10:11.65 zip Is there a way to enable multithreading for glusterfs? Maybe multiple cores dedicated to it would manage to get enough data for a single CPU core to work on.
The workaround is to either: - use /dev/vdb mounted on /mnt , with the drawback that if the instance dies, the data are loss. - migrate a given labs project to use the shared NFS server as has been done for toollabs and deployment-prep (beta cluster) Closing this bug since we have workarounds.
