[Gluster-devel] Unfair scheduling in unify/AFR

[Székelyi Szabolcs]

Hi,

I use a configuration with 3 servers and one client, with client-side
AFR/unify.

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
scheduling.

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?

Thanks,
--
Szabolcs