similar to: Basic gluster questions

Hi- I'm new to Gluster, but am trying to get it set up on a new compute cluster we're building. We picked Gluster for one of our cluster file systems (we're also using Lustre for fast scratch space), but the Gluster performance has been so bad that I think maybe we have a configuration problem -- perhaps we're missing a tuning parameter that would help, but I can't find

Hello, I'm driving some experiments on grid'5000 with GlusterFS 3.2 and, as a first point, i've been unable to start a volume featuring 128bricks (64 ok) Then, due to the round-robin scheduler, as the number of nodes increase (every node is also a brick), the performance of an application on an individual node decrease! So my question is : how to STOP the round-robin distribution

Hi Nag Pavan Chilakam Can I use this command "gluster vol add-brick vol1 replica 2 file01g:/brick3/data/vol1 file02g:/brick4/data/vol1" in both file server 01 and 02 exited without add new servers. Is it ok for expanding volume? Thanks for your support Regards, Giang 2017-06-14 22:26 GMT+07:00 Nag Pavan Chilakam <nag.chilakam at gmail.com>: > Hi, > You can use add-brick

This has probably been discussed before, but since I'm new on the list I hope You have patience with me. I have a four brick distributed/replicated setup. The computers are multi-core 16GB memory and 2*2.0TB in raid1 SATA-disks locally. The nodes are connected by 1 GB ethernet. All nodes have glusterfs 3.3beta2 installed and they are running debian 6 64bit. The underlying filesystems are

Hi.... I have setup a 4 node cluster on virtual servers on RHEL platform. Not able to get better performance statistics on glusterFS as compared to local file system. Kindly suggest a test run that can be checked to differentiate between them. Regards, Anish Kumar "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). are

Hi everyone, I am seeing slower-than-expected performance in Gluster 3.2.3 between 4 hosts with 10 gigabit eth between them all. Each host has 4x 300GB SAS 15K drives in RAID10, 6-core Xeon E5645 @ 2.40GHz and 24GB RAM running Ubuntu 10.04 64-bit (I have also tested with Scientific Linux 6.1 and Debian Squeeze - same results on those as well). All of the hosts mount the volume using the FUSE

Hello, I have several systems which I recently updated with yum -y update to all the latest packages. These systems use yum-priorities and use the CentOS (priority 1) EPEL (priority 5) and rpmforge (priority 10) repositories. After the updates, dhcpd stopped working with a SIGPIPE error which occurs shortly after it attempts to fork into the background. I worked around that problem by building

Thanks. I think reusing the same volume was the cause of lack of IO distribution. The latest profile output looks much more realistic and in line with i would expect. Let me analyse the numbers a bit and get back. -Krutika On Tue, Jul 4, 2017 at 12:55 PM, <gencer at gencgiyen.com> wrote: > Hi Krutika, > > > > Thank you so much for myour reply. Let me answer all: > >

Hi Krutika, Thank you so much for myour reply. Let me answer all: 1. I have no idea why it did not get distributed over all bricks. 2. Hm.. This is really weird. And others; No. I use only one volume. When I tested sharded and striped volumes, I manually stopped volume, deleted volume, purged data (data inside of bricks/disks) and re-create by using this command: sudo gluster

Ki Krutika, After that setting: $ dd if=/dev/zero of=/mnt/ddfile bs=1G count=1 1+0 records in 1+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.7351 s, 91.5 MB/s $ dd if=/dev/zero of=/mnt/ddfile2 bs=2G count=1 0+1 records in 0+1 records out 2147479552 bytes (2.1 GB, 2.0 GiB) copied, 23.7351 s, 90.5 MB/s $ dd if=/dev/zero of=/mnt/ddfile3 bs=1G count=1 1+0 records

What if you disabled eager lock and run your test again on the sharded configuration along with the profile output? # gluster volume set <VOL> cluster.eager-lock off -Krutika On Tue, Jul 4, 2017 at 9:03 PM, Krutika Dhananjay <kdhananj at redhat.com> wrote: > Thanks. I think reusing the same volume was the cause of lack of IO > distribution. > The latest profile output

Hi Gencer, I just checked the volume-profile attachments. Things that seem really odd to me as far as the sharded volume is concerned: 1. Only the replica pair having bricks 5 and 6 on both nodes 09 and 10 seems to have witnessed all the IO. No other bricks witnessed any write operations. This is unacceptable for a volume that has 8 other replica sets. Why didn't the shards get distributed

Hi Krutika, I also did one more test. I re-created another volume (single volume. Old one destroyed-deleted) then do 2 dd tests. One for 1GB other for 2GB. Both are 32MB shard and eager-lock off. Samples: sr:~# gluster volume profile testvol start Starting volume profile on testvol has been successful sr:~# dd if=/dev/zero of=/testvol/dtestfil0xb bs=1G count=1 1+0 records in 1+0

Krutika, I?m sorry I forgot to add logs. I attached them now. Thanks, Gencer. From: gluster-users-bounces at gluster.org [mailto:gluster-users-bounces at gluster.org] On Behalf Of gencer at gencgiyen.com Sent: Thursday, July 6, 2017 10:27 AM To: 'Krutika Dhananjay' <kdhananj at redhat.com> Cc: 'gluster-user' <gluster-users at gluster.org> Subject: Re:

Hi Krutika, Is it anything in the profile indicating what is causing this bottleneck? In case i can collect any other info let me know. Thanx On Sep 5, 2017 13:27, "Abi Askushi" <rightkicktech at gmail.com> wrote: Hi Krutika, Attached the profile stats. I enabled profiling then ran some dd tests. Also 3 Windows VMs are running on top this volume but did not do any stress

Hi Krutika, May I kindly ping to you and ask that If you have any idea yet or figured out whats the issue may? I am awaiting your reply with four eyes :) Apologies for the ping :) -Gencer. From: gluster-users-bounces at gluster.org [mailto:gluster-users-bounces at gluster.org] On Behalf Of gencer at gencgiyen.com Sent: Thursday, July 6, 2017 11:06 AM To: 'Krutika

Hi all, I have a gluster volume used to host several VMs (managed through oVirt). The volume is a replica 3 with arbiter and the 3 servers use 1 Gbit network for the storage. When testing with dd (dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct) out of the volume (e.g. writing at /root/) the performance of the dd is reported to be ~ 700MB/s, which is quite decent. When testing the dd on

Hi, Sorry for the late response. No, so eager-lock experiment was more to see if the implementation had any new bugs. It doesn't look like it does. I think having it on would be the right thing to do. It will reduce the number of fops having to go over the network. Coming to the performance drop, I compared the volume profile output for stripe and 32MB shard again. The only thing that is

Hi Krutika, I already have a preallocated disk on VM. Now I am checking performance with dd on the hypervisors which have the gluster volume configured. I tried also several values of shard-block-size and I keep getting the same low values on write performance. Enabling client-io-threads also did not have any affect. The version of gluster I am using is glusterfs 3.8.12 built on May 11 2017

I tried to follow step from https://wiki.centos.org/SpecialInterestGroup/Storage to install latest gluster on the first node. It installed 3.10 and not 3.11. I am not sure how to install 3.11 without compiling it. Then when tried to start the gluster on the node the bricks were reported down (the other 2 nodes have still 3.8). No sure why. The logs were showing the below (even after rebooting the