Re: Improving real world performance by moving files closer to their target workloads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martin Fick wrote:
Again, Luke suggested improving the current unify
translator with migration.  Do you think that this
would improve it? The answer I suspect has to do with
your workload, thus the suggestion for multiple
migration schedulers.  Surely some workloads will
benefit from this.  If you have workloads (even
suggested imaginary ones) that will not be improved by
this strategy, by all means, bring them up.  If you
have workloads that will actually be hurt by the
strategy, of course, bring those up first!  I suspect
that some workloads may indeed be hurt by this and may
result in "migration thrashing" where a file keeps
bouncing from node to node -> back to designing good
schedulers with good heuristics.

I think the unify migrator would probably help at least a little in the
case where one node tends to use a file much more often than other
nodes, but how likely is this to be the case?  When this isn't the case,
or when the node that tends to use the file most varies from day to day
or moment to moment, I think you will see the migration thrashing issue
you mentioned.

I think the AFR migrator we were discussing, where copies of files may
be kept in several locations, would be useful in the more general case
where a number of machines tended to read and write a file regularly.

Of course, I can't argue with you over which will be easier to implement.

Regards,

Derek
--
Derek R. Price
Solutions Architect
Ximbiot, LLC <http://ximbiot.com>
Get CVS and Subversion Support from Ximbiot!

v: +1 248.835.1260
f: +1 248.246.1176






[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux