[Gluster-users] GlusterFS performance

[Nikita A Kardashin]

No, I am speaking about stranges in write to existing files. Maybe
'broken', but maybe root of trouble in my options (flush-behind or some
else)?

Illtustration of my situation:
root at virtual:~# rm testfile.bin # removing old file
root at virtual:~# dd if=/dev/zero of=testfile.bin bs=100M count=3 # testing
speed on new file
3+0 records in
3+0 records out
314572800 bytes (315 MB) copied, 0.268943 s, 1.2 GB/s
root at virtual:~# dd if=/dev/zero of=testfile.bin bs=100M count=3 # testing
speed on existing file. WOW!
3+0 records in
3+0 records out
314572800 bytes (315 MB) copied, 290.361 s, 1.1 MB/s

Why writing to existing file is soooooooooooooooo slooooooooooooow?


2013/3/1 Brian Candler <B.Candler at pobox.com>

> On Fri, Mar 01, 2013 at 03:30:07PM +0600, Nikita A Kardashin wrote:
> >    If I try to execute above command inside virtual machine (KVM), first
> >    time all going right - about 900MB/s (cache effect, I think), but if I
> >    run this test again on existing file - task (dd) hungs up and can be
> >    stopped only by Ctrl+C.
> >    Overall virtual system latency is poor too. For example, apt-get
> >    upgrade upgrading system very, very slow, freezing on "Unpacking
> >    replacement" and other io-related steps.
> >    Does glusterfs have any tuning options, that can help me?
>
> If you are finding that processes hang or freeze indefinitely, this is not
> a question of "tuning", this is simply "broken".
>
> Anyway, you're asking the wrong person - I'm currently in the process of
> stripping out glusterfs, although I remain interested in the project.
>
> I did find that KVM performed very poorly, but KVM was not my main
> application and that's not why I'm abandoning it.  I'm stripping out
> glusterfs primarily because it's not supportable in my environment, because
> there is no documentation on how to analyse and recover from failure
> scenarios which can and do happen. This point in more detail:
> http://www.gluster.org/pipermail/gluster-users/2013-January/035118.html
>
> The other downside of gluster was its lack of flexibility, in particular
> the
> fact that there is no usage scaling factor on bricks, so that even with a
> simple distributed setup all your bricks have to be the same size.  Also,
> the object store feature which I wanted to use, has clearly had hardly any
> testing (even the RPM packages don't install properly).
>
> I *really* wanted to deploy gluster, because in principle I like the idea
> of
> a virtual distribution/replication system which sits on top of existing
> local filesystems.  But for storage, I need something where operational
> supportability is at the top of the pile.
>
> Regards,
>
> Brian.
>



-- 
With best regards,
differentlocal (www.differentlocal.ru | differentlocal at gmail.com),
System administrator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130301/47e64f68/attachment.html>