[Gluster-users] extreme slow recover rate
Wei Dong
wdong.pku at gmail.com
Thu Aug 20 19:05:21 UTC 2009
Hi All,
I'm experiencing extremely slow auto-heal rate with glusterfs and I want
to hear from you guys to see if it seems reasonable or something's wrong.
I did a reconfiguration of the glusterfs running on our lab cluster.
Originally we have 25 nodes, each provide 1 1.5T SATA disk, the data are
not replicated. Now we have expanded the cluster to 66 nodes and I
decided to use all the 4 disks of each node and have the data replicated
3 times on different machines. What I did is to leave the original data
untouched, and reconfigure glusterfs so that the original data volumes
are paired up with new empty mirror volumes. On the server side, I have
each node exports one volume for each of the 4 disks, with an IO-threads
translator with 4 threads running on top of each disk and no other
performance translators. On the client side which is mounted on each of
the 66 nodes, I group all the volumes into mirrors of 3 volumes each,
and then aggregate the mirrors with one DHT, and put a write-behind
translator with window-size 1MB on top of that.
The files are all images, roughly 200K each.
To trigger auto-heal, I split a list of all the files (previously saved
before reconfiguration) among the 66 nodes and have 4 threads on each
nodes running the stat command on the files. The overall rate is about
50 files per second, which I think is very low. And will the auto-heal
is running, all operations like cd and ls on the glusterfs client
becomes extremely slow, each takes like one minute to finish.
On
http://www.gluster.org/docs/index.php/GlusterFS_2.0_I/O_Benchmark_Results,
which uses 5 servers and one raid0 disk each node, with 5 threads
running on 3 clients, about 61K 1M files can be created within 10min, at
an average rate of 130 files/second. The glusterfsd processes are each
taking about 99% CPU time (
we have 8 cores / node, but it seems glusterfsd is able to use only 1).
There only advantage is that they use RAID0 disk and clients and servers
are different machines. Other than that, we have more servers/clients,
more disks on each node, and I have configured IO-thread and
write-behind (which I don't think helps auto heal), and our files are
only about 1/5 their size. Even if I count each file as 3 for
replication, I'm only achieving similar throughput as a much smaller
cluster. I don't know why it's like this and following are my hypothesis:
1. The overall through of glusterfs doesn't scale up to so many nodes;
2. The auto-heal operating is slower than creating the file from scratch;
3. Glusterfs is CPU bound -- it seems to be the case, but I'm unwilling
to accept that a filesystem is CPU bound;
4. The network bandwith is saturated. I think we have 1gigabit
eithernet on the nodes, which are on two racks and connected by some
Foundry switch with 4 gigabit aggregate inter-rack bandwidth;
5. Replication is slow.
Finally, the good news is that all the servers and client processes have
been running for about 2 hours under stress, which I didn't expect in
the beginning. Good job you glusterfs people!
We are desperate for a shared storage and I'm eager to hear any
suggestion you have to make glusterfs perform better.
- Wei
More information about the Gluster-users
mailing list