Basic gluster questions

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

 



With NFS server problems resolved, I'm seeing what I'd hoped for which
is rsync processes being more or less CPU bound with no i/o wait. Will
start doing some more in depth benchmarks and likely be back later
with more questions. Thanks for your help.

jbh

On Wed, Jun 1, 2011 at 8:48 AM, John Hanks <john.hanks at colorado.edu> wrote:
> The culprit appears to be my source NFS server, looks like some of
> it's RAID sets decided they needed to rebuild at about the same time I
> was doing my testing. One should never assume that because something
> worked well yesterday it will work well today, will retry things with
> a different source that works as expected.
>
> jbh
>
> On Wed, Jun 1, 2011 at 12:44 AM, Pavan <tcp at gluster.com> wrote:
>> On Tuesday 31 May 2011 11:01 PM, John Hanks wrote:
>>> Hi,
>>>
>>> I'm setting up gluster for the first time and have a single server
>>> with two bricks set up for testing:
>>>
>>> [root at filer-jdn1bp1 etc]# gluster volume info
>>>
>>> Volume Name: projects
>>> Type: Distribute
>>> Status: Started
>>> Number of Bricks: 2
>>> Transport-type: tcp
>>> Bricks:
>>> Brick1: filer-jdn1bp1:/glusterfs/0.0
>>> Brick2: filer-jdn1bp1:/glusterfs/0.1
>>> Options Reconfigured:
>>> nfs.disable: on
>>>
>>> Mounting this volume on the server or on a separate client over a 10
>>> Gbps link is working, but I'm seeing weird performance patterns. If I
>>> do this:
>>>
>>> time sh -c "dd if=/dev/zero of=./testfile count=32768 bs=1M; sync"
>>>
>>> in the glusterfs mounted directory on either client I see rates of
>>> ~250 MB/s but if I try to copy files onto the volume with either rsync
>>> or cpio pass-thru, the rates drop to< ?10 MB/s. The directories I am
>>> attempting to copy are mostly large files (> ?10 GB) and as I watch
>>> cpu, network and disk i/o stats, nothing seems to be stressed or
>>> blocked, it's just slow.
>>
>> You cannot just look at the cpu, network, io stats and conclude that
>> things are fine. You will have to look at these values in comparison
>> with dthe dd case where things work according to your expectation.
>>
>> When you say you are "rsync'ing to the volume", *from where* do you rsync?
>>
>> Pavan
>>
>>>
>>> I've been searching for documentation on how to possibly tune this or
>>> track down the bottleneck but not having much luck. Most things that
>>> turn up in searches seem to apply to older gluster versions and the
>>> 3.2 documentation is pretty sparse with respect to tuning things.
>>>
>>> Any suggestions for what I am doing wrong with this setup or any
>>> pointers to documentation on how to troubleshoot/tune this would be
>>> appreciated, especially any "intro for dummies" type docs that could
>>> fill in the big gaps in my understanding of how gluster works. I'm
>>> open to an RTFM reply, just haven't found the right manual yet myself
>>> and would appreciate a pointer :)
>>>
>>> Thanks,
>>>
>>> jbh
>>> _______________________________________________
>>> Gluster-users mailing list
>>> Gluster-users at gluster.org
>>> http://gluster.org/cgi-bin/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