[Gluster-devel] Unfair scheduling in unify/AFR
krishna at zresearch.com
Mon Nov 19 20:31:30 UTC 2007
In case you have not put io-threads, can you test it with that and see
how it behaves?
When you copy, are the source and destination files both on the glusterfs
Can you mail the client spec file?
On Nov 20, 2007 1:24 AM, Székelyi Szabolcs <cc at avaxio.hu> wrote:
> I use a configuration with 3 servers and one client, with client-side
> It looks like the unify and AFR translators (with the new load-balancing
> code) do unfair scheduling among concurrent threads.
> I tried to copy two files with two concurrent (ie. parallel) threads,
> and one of the threads always gets much more bandwidth than the other.
> When the threads start to run, actually only one of them get served by
> the GlusterFS client at a reasonable performance, the other (almost)
> starves. When the first thread finishes, comes the other one.
> The order of the threads seems constant over consecutive runs.
> Even more, a thread started when one thread is already running, the
> second one can steal performance from the first.
> The preference of the threads is determined by the remote server. (I
> mean a thread served by a particular host always gets more performance
> than another one. This is how a thread started later can steal
> performance from the other.)
> Doing the same thing with two GlusterFS clients (mounting the same
> configuration on two different directories) gives absolutely fair
> The trouble with this is that this way one can't benefit from AFR
> load-balancing. We would like to exceed the physical disk speed limit by
> spreading the reads over multiple GlusterFS servers, but they cannot be
> spread this way; only one server does the work at a given point in time.
> Do you have any idea what could be wrong and how to fix it?
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
More information about the Gluster-devel