[Gluster-users] write performance is not good

[Mingfan Lu]

In the client's log, I found:

[2014-01-28 17:54:36.839220] I [afr-self-heal-data.c:712:afr_sh_data_fix]
0-sh-ugc1-mams-replicate-7: no active sinks for performing self-heal on
file /fytest/46
[2014-01-28 17:55:05.251490] I [afr-self-heal-data.c:712:afr_sh_data_fix]
0-sh-ugc1-mams-replicate-7: no active sinks for performing self-heal on
file /fytest/49

the /fytest/46 & /fytest/49 are BAD files.

What does "no active sinks for performing" means?




On Tue, Jan 28, 2014 at 4:56 PM, Dan Mons <dmons at cuttingedge.com.au> wrote:

> Is your write single or multi-threaded?
>
> If it's single threaded, try writing your files across as many threads
> as possible, and see what the performance improvement is like.
>
> -Dan
> ----------------
> Dan Mons
> Skunk Works
> Cutting Edge
> http://cuttingedge.com.au
>
>
> On 28 January 2014 18:49, Mingfan Lu <mingfan.lu at gmail.com> wrote:
> >
> > Hi,
> >   I have a  distributed and replica=3 volume (not to use stripe ) in a
> > cluster. I used dd to write 120 files to test. I foundthe write
> performane
> > of some files are much lower than others. all these "BAD" files are
> stored
> > in the same three brick servers for replication (I called node1 node2
> node3)
> >
> > e.g the bad write performance could be 10MBps while good performance
> could
> > be 150Mbps+
> >
> > there are no problems about raid and networks.
> > If i stopped node1 & node2, the write performance of "BAD" files are the
> > similar to (even better) GOOD ones.
> >
> > One thing I must metion is  the raids of node1 and node2 are reformated
> for
> > some reason, there are many self-heal activities to restore files in
> node1
> > and node2.
> > Is the BAD write performance caused by aggresive self-heal?
> > How could I slow down the self-heal?
> > Any advise?
> >
> >
> >
> > _______________________________________________
> > Gluster-users mailing list
> > Gluster-users at gluster.org
> > http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140128/bfdef2c9/attachment.html>