Re: Very slow ls

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

 



In a replicated scheme, it's like a raid 1 (mirror).
You write as slow as the slowest disk. Client will wait for all brick
writes confirmation.

In this scheme, you wouldn't much more than 3 bricks.

I think you mox up with distributed scheme, which is like a raid 0 stripped.
This one get more perf when adding bricks. But a single file is
present only in one brick.



Envoyé de mon iPad

Le 4 août 2015 à 08:32, Florian Oppermann <gluster-users@xxxxxxxxxxx> a écrit :

>> As you are in replicate mode, all write will be send synchronously to all bricks, and in your case to a single hdd.
>
> I thought that every file will be sent to 2 bricks synchronously but if
> I write several files they are distributed between the three pairs of
> bricks. Therefore the performance should become better with more bricks
> (note that the 3×2 bricks are not final but only a test setup, more
> bricks will be added when going to production).
>
>> For sure I wouldn't go for 60+ users with this setup, maybe except if these hdd are ssd
>
> What would be a suitable setup? Or: Which use cases are typical for
> Gluster setups? Maybe I misunderstood the target of Gluster.
>
> Best regards
> Florian
>
>> On 04.08.2015 07:25, Mathieu Chateau wrote:
>> Hello,
>>
>> As you are in replicate mode, all write will be send synchronously to
>> all bricks, and in your case to a single hdd.
>>
>> Writes: you are going to have same perf as 1 single hdd (best case
>> possible, you will have less)
>> read: all brick will be queried for metadata, one will send the file (if
>> I am correct)
>>
>> For sure I wouldn't go for 60+ users with this setup, maybe except if
>> these hdd are ssd
>>
>> just my 2 cents
>>
>> Cordialement,
>> Mathieu CHATEAU
>> http://www.lotp.fr
>>
>> 2015-08-03 23:29 GMT+02:00 Florian Oppermann <gluster-users@xxxxxxxxxxx
>> <mailto:gluster-users@xxxxxxxxxxx>>:
>>
>>> If starting setup right now, you should start with current version (3.7.X)
>>
>>    Is 3.7 stable? I have 60+ potential users and dont want to risk too
>>    much. ;-)
>>
>>> Filesystem
>>
>>    XFS partitions on all bricks
>>
>>> network type (lan, VM...)
>>
>>    Gigabit LAN
>>
>>> where is client (same lan?)
>>
>>    Yep
>>
>>> MTU
>>
>>    1500
>>
>>> storage (raid, # of disks...)
>>
>>    The bricks are all on separate servers. On each is a XFS partition on a
>>    single HDD (together with other partitions for system etc.). All in all
>>    there are currently seven machines involved.
>>
>>    I just noticed that on all servers the
>>    /var/log/glusterfs/etc-glusterfs-glusterd.vol.log is full of
>>    messages like
>>
>>> [2015-08-03 21:24:59.879820] W [socket.c:620:__socket_rwv]
>>    0-management: readv on
>>    /var/run/a91fc43b47272ffaace2a6989e7b5e85.socket failed (Invalid
>>    argument)
>>
>>    I assume this to be part of the problem…
>>
>>    Regards :-)
>>    Florian
>>
>>>    On 03.08.2015 22 <tel:03.08.2015%2022>:41, Mathieu Chateau wrote:
>>> Hello,
>>>
>>> If starting setup right now, you should start with current version (3.7.X)
>>>
>>> We need more data/context as you were able to feed 150GB before having
>>> issue.
>>>
>>> Info:
>>> Filesystem
>>> network type (lan, VM...)
>>> where is client (same lan?)
>>> MTU
>>> storage (raid, # of disks...)
>>>
>>> Cordialement,
>>> Mathieu CHATEAU
>>> http://www.lotp.fr
>>>
>>> 2015-08-03 21:44 GMT+02:00 Florian Oppermann <gluster-users@xxxxxxxxxxx <mailto:gluster-users@xxxxxxxxxxx>
>>> <mailto:gluster-users@xxxxxxxxxxx
>>    <mailto:gluster-users@xxxxxxxxxxx>>>:
>>>
>>>    Dear Gluster users,
>>>
>>>    after setting up a distributed replicated volume (3x2 bricks) on gluster
>>>    3.6.4 on Ubuntu systems and populating it with some data (about 150 GB
>>>    in 20k files) I experience extreme delay when navigating through
>>>    directories or trying to ls the contents (actually the process seems to
>>>    hang completely now until I kill the /usr/sbin/glusterfs process on the
>>>    mounting machine).
>>>
>>>    Is there some common misconfiguration or any performance tuning option
>>>    that I could try?
>>>
>>>    I mount via automount with fstype=glusterfs option (using the native
>>>    fuse mount).
>>>
>>>    Any tips?
>>>
>>>    Best regards,
>>>    Florian Oppermann
>>>    _______________________________________________
>>>    Gluster-users mailing list
>>>    Gluster-users@xxxxxxxxxxx <mailto:Gluster-users@xxxxxxxxxxx>
>>    <mailto:Gluster-users@xxxxxxxxxxx <mailto:Gluster-users@xxxxxxxxxxx>>
>>>    http://www.gluster.org/mailman/listinfo/gluster-users
>>>
>>>
>>
>>
_______________________________________________
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