Re: Shard Volume testing (3.7.5)

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

 






From: "Lindsay Mathieson" <lindsay.mathieson@xxxxxxxxx>
To: "Krutika Dhananjay" <kdhananj@xxxxxxxxxx>
Cc: "gluster-users" <gluster-users@xxxxxxxxxxx>
Sent: Wednesday, October 28, 2015 1:08:33 PM
Subject: Re: Shard Volume testing (3.7.5)


On 28 October 2015 at 17:03, Krutika Dhananjay <kdhananj@xxxxxxxxxx> wrote:
So sharding also helps with better disk utilization in distributed-replicated volumes for large files (like VM images).
.. 
There are other long-term benefits one could reap from using sharding: for instance, for someone who might want to use tiering in VM store use-case, having sharding will be beneficial in terms of only migrating the shards between hot and cold tiers, as opposed to moving large files in full, even if only a small portion of the file is changed/accessed. :)


Interesting points, thanks.


Yes. So Paul Cuzner and Satheesaran who have been testing sharding here have reported better write performance with 512M shards. I'd be interested to know what you feel about performance with relatively larger shards (think 512M).

Seq Read speeds basically tripled, and seq writes improved to the limit of the network connection.

OK. And what about the data heal performance with 512M shards? Satisfactory?



Easily satisfactory, a bit slower than the 4MB shard but still way faster than a full multi GB file heal :)


Something I have noticed, is that the heal info (gluster volume heal <datastore> info) can be very slow to return, as in many 10's of seconds - is there a way to speed that up?
With sharding? Or even otherwise? Approximately how many entries did the command list when you found it to be slow?
On a related note, Anuradha (cc'd) is working on an enhancement that would make the 'heal info' reporting faster. She should be able to tell you more about it.


It would be every useful if there was a command that quickly gave summary/progress status, e.g "There are <X> shards to be healed"
Hmmm ... that would have to be an extension of 'heal info' or perhaps post-processing of the 'heal info' output which would group the different shards of a given file that need heal together. Nice suggestion. I will think about it.

-Krutika



--
Lindsay

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users

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

  Powered by Linux