Re: Full bore.

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

 



Chris,
 you should really load write-behind (and read-ahead) on the client side to
gain on performance. Also on server side,
server->write-behind->io-theads->posix helps.

avati

2007/11/16, Chris Johnson <johnson@xxxxxxxxxxxxxxxxxxx>:
>
> On Fri, 16 Nov 2007, Anand Avati wrote:
>
>       Doesn't get any simpler than this.
>
> volume client
>    type protocol/client
>    option transport-type tcp/client
>    option remote-host xxx.xxx.xxx.xxx
>    option remote-subvolume brick1
> end-volume
>
>       Tx's are there to protect the inocent.
>
> > Your configuration doesnt seem to be what you want. do it someting like
> this
> > -
> >
> > volume brick1
> >  ..
> > end-volume
> >
> > volume write-behind
> >  ...
> >  subvolume brick1
> > end-volume
> >
> > volume read-ahead
> >  ...
> >  subvolume write-behind
> > end-volume
> >
> > volume server
> >  ...
> >  auth.ip.read-ahead.allow *
> >  subvolume read-ahead
> > end-volume
> >
> >
> > also can you post your client config?
> >
> > avati
> >
> > 2007/11/16, Chris Johnson <johnson@xxxxxxxxxxxxxxxxxxx>:
> >>
> >>       Ok, hi.
> >>
> >>       I think I'm committing a major blunder here which may be why I'm
> >> not seeing better through put.
> >>
> >>       These xlators should be stacked, is that right?  I defined the
> >> following;
> >>
> >> volume brick1
> >>    type storage/posix
> >>    option directory /home/sdm1
> >> end-volume
> >>
> >> volume server
> >>    type protocol/server
> >>    subvolumes brick1
> >>    option transport-type tcp/server     # For TCP/IP transport
> >> #  option client-volume-filename /etc/glusterfs/glusterfs-client.vol
> >>    option auth.ip.brick1.allow *
> >> end-volume
> >>
> >> volume writebehind
> >>    type performance/write-behind
> >>    option aggregate-size 131072 # in bytes
> >>    subvolumes brick1
> >> end-volume
> >>
> >> volume readahead
> >>    type performance/read-ahead
> >>    option page-size 65536 ### in bytes
> >>    option page-count 16 ### memory cache size is page-count x page-size
> >> per file
> >>    subvolumes brick1
> >> end-volume
> >>
> >> Should I have used the 'server' volume as the subvolume for read-ahead
> >> and write-behind in the above?  Or should read-ahead and write-behind
> >> be between the basic brick and the server volume?  Is there a
> >> diffrence in performance?
> >>
> >>       I grabbed 5 volumes from the SATA Beast.  I think the best way to
> >> test this is with the real files and jobs.  So it's go for broke and
> >> full bore time.
> >>
> >>       If I have two front ends I need I'll need the postix lock deal,
> >> the io threader is a must or why bother.  If I unify, both front ends
> >> need access to the same namespace brick so it has to have locks on it
> >> too, yes?
> >>
> >>       Looking at the GlusterFS Translators v1.3 server examples.  Why
> >> is the io thread xlator so high up in the stack?  Would it be better
> >> farther down that stack closer to the basic bricks?  If not, why not?
> >>
> >>
> >>
> -------------------------------------------------------------------------------
> >> Chris Johnson               |Internet: johnson@xxxxxxxxxxxxxxxxxxx
> >> Systems Administrator       |Web:
> >> http://www.nmr.mgh.harvard.edu/~johnson
> >> NMR Center                  |Voice:    617.726.0949
> >> Mass. General Hospital      |FAX:      617.726.7422
> >> 149 (2301) 13th Street      |Knowing what thou knowest not
> >> Charlestown, MA., 02129 USA |is in  a sence omniscience.  Piet Hein
> >>
> >>
> -------------------------------------------------------------------------------
> >>
> >>
> >> _______________________________________________
> >> Gluster-devel mailing list
> >> Gluster-devel@xxxxxxxxxx
> >> http://lists.nongnu.org/mailman/listinfo/gluster-devel
> >>
> >
> >
> >
> > --
> > It always takes longer than you expect, even when you take into account
> > Hofstadter's Law.
> >
> > -- Hofstadter's Law
> >
>
>
> -------------------------------------------------------------------------------
> Chris Johnson               |Internet: johnson@xxxxxxxxxxxxxxxxxxx
> Systems Administrator       |Web:
> http://www.nmr.mgh.harvard.edu/~johnson
> NMR Center                  |Voice:    617.726.0949
> Mass. General Hospital      |FAX:      617.726.7422
> 149 (2301) 13th Street      |For all sad words of tongue or pen, the
> saddest
> Charlestown, MA., 02129 USA |are these: "It might have been".  John G.
> Whittier
>
> -------------------------------------------------------------------------------
>



-- 
It always takes longer than you expect, even when you take into account
Hofstadter's Law.

-- Hofstadter's Law


[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