search for: gencer

...ng the bandwidth between two nodes. I see up to 102MB/s. Is there anything I can do to optimize more? Or is it last stop? Note: I deleted all files again and reformat then re-create volume with shard then mount it. Tried with 16MB, 32MB and 512MB shard sizes. Results are equal. Thanks, Gencer. From: Krutika Dhananjay [mailto:kdhananj at redhat.com] Sent: Thursday, July 6, 2017 3:30 AM To: gencer at gencgiyen.com Cc: gluster-user <gluster-users at gluster.org> Subject: Re: [Gluster-users] Very slow performance on Sharded GlusterFS What if you disabled eager lock and run yo...

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&g...

...Stripe 2 replica 2: dd performs 250~ mb/s but shard gives 77mb. I attached two logs (shard and stripe logs) Note: I also noticed that you said ?order?. Do you mean when we create via volume set we have to make an order for bricks? I thought gluster handles (and do the math) itself. Gencer From: Krutika Dhananjay [mailto:kdhananj at redhat.com] Sent: Friday, June 30, 2017 3:50 PM To: gencer at gencgiyen.com Cc: gluster-user <gluster-users at gluster.org> Subject: Re: [Gluster-users] Very slow performance on Sharded GlusterFS Just noticed that the way you have configure...

...k10 Options Reconfigured: cluster.eager-lock: off features.shard-block-size: 32MB features.shard: on transport.address-family: inet nfs.disable: on See attached results and sorry for the multiple e-mails. I just want to make sure that I provided correct results for the tests. 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:34 AM To: 'Krutika Dhananjay' <kdhananj at redhat.com> Cc: 'gluster-user' <gluster-users at gluster.org> Sub...

...th sharding because the optimizations eager-locking and delayed post-op will now only be applicable on a per-shard basis. Larger the shard size, the better, to work around this issue. Meanwhile, let me think about how we can get this fixed in code. -Krutika On Mon, Jul 10, 2017 at 7:59 PM, <gencer at gencgiyen.com> wrote: > 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 :) > > > >...

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 Dhananjay' <kdhananj at redhat.com> Cc: 'gluster-user' <gluster-users at gluster.org> Sub...

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: > > > > 1. I have no idea why it did not get distributed over all bricks. > 2. Hm.. This is really weird. > > > > And others; > > > >...

...s. 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: >> >> >> >> 1. I have no idea why it did not get distributed over all bricks. >> 2. Hm.. This is really weird. >>...

...7: sr-10-loc-50-14-18:/bricks/brick7 Brick18: sr-10-loc-50-14-18:/bricks/brick8 Brick19: sr-10-loc-50-14-18:/bricks/brick9 Brick20: sr-10-loc-50-14-18:/bricks/brick10 Options Reconfigured: features.shard-block-size: 32MB features.shard: on transport.address-family: inet nfs.disable: on -Gencer. From: Krutika Dhananjay [mailto:kdhananj at redhat.com] Sent: Friday, June 30, 2017 2:50 PM To: gencer at gencgiyen.com Cc: gluster-user <gluster-users at gluster.org> Subject: Re: [Gluster-users] Very slow performance on Sharded GlusterFS Could you please provide the volume-info ou...

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 unaccept...

...4 MB/s >> dd if=/dev/zero of=/mnt/testfile bs=5G count=1 This also gives same result. (bs and count reversed) And this example have generated a profile which I also attached to this e-mail. Is there anything that I can try? I am open to all kind of suggestions. Thanks, Gencer. From: Krutika Dhananjay [mailto:kdhananj at redhat.com] Sent: Tuesday, July 4, 2017 9:39 AM To: gencer at gencgiyen.com Cc: gluster-user <gluster-users at gluster.org> Subject: Re: [Gluster-users] Very slow performance on Sharded GlusterFS Hi Gencer, I just checked the volume-profi...

Hi Krutika, Have you be able to look out my profiles? Do you have any clue, idea or suggestion? Thanks, -Gencer From: Krutika Dhananjay [mailto:kdhananj at redhat.com] Sent: Friday, June 30, 2017 3:50 PM To: gencer at gencgiyen.com Cc: gluster-user <gluster-users at gluster.org> Subject: Re: [Gluster-users] Very slow performance on Sharded GlusterFS Just noticed that the way you have configure...

...speed or maybe little slower. What I get is 5-10x slower. I play with Gluster?s threads count, performance tweaks, caches and etc. Nothing helped. In fact, the performance tweaks that I apply for stripe makes sharded volume much much more worse. Default values are better on sharded volume. -Gencer. From: gencer at gencgiyen.com [mailto:gencer at gencgiyen.com] Sent: Saturday, July 1, 2017 9:49 AM To: 'Gandalf Corvotempesta' <gandalf.corvotempesta at gmail.com> Cc: 'Krutika Dhananjay' <kdhananj at redhat.com>; 'gluster-user' <gluster-users at gluste...

...as completed, run `gluster volume profile <VOL> info` and redirect its output to a tmp file. 4. Stop profile # gluster volume profile <VOL> stop And attach the volume-profile output file that you saved at a temporary location in step 3. -Krutika On Fri, Jun 30, 2017 at 5:33 PM, <gencer at gencgiyen.com> wrote: > Hi Krutika, > > > > Sure, here is volume info: > > > > root at sr-09-loc-50-14-18:/# gluster volume info testvol > > > > Volume Name: testvol > > Type: Distributed-Replicate > > Volume ID: 30426017-59d5-4091-b6bc-279a...

...tweak/tuning out there to make it fast? Or is this an expected behavior? If its, It is unacceptable. So slow. I cannot use this on production as it is terribly slow. The reason behind I use shard instead of stripe is i would like to eleminate files that bigger than brick size. Thanks, Gencer. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170630/263735fe/attachment.html>

Could you please provide the volume-info output? -Krutika On Fri, Jun 30, 2017 at 4:23 PM, <gencer at gencgiyen.com> wrote: > Hi, > > > > I have an 2 nodes with 20 bricks in total (10+10). > > > > First test: > > > > 2 Nodes with Distributed ? Striped ? Replicated (2 x 2) > > 10GbE Speed between nodes > > > > ?dd? performance: 400mb/s...

I did the changes (one brick from 09th server and one replica from 10th server and continued with this order) and re-test. Nothing changed. Still slow. (exactly same result.) -Gencer. From: Gandalf Corvotempesta [mailto:gandalf.corvotempesta at gmail.com] Sent: Friday, June 30, 2017 8:19 PM To: gencer at gencgiyen.com Cc: Krutika Dhananjay <kdhananj at redhat.com>; gluster-user <gluster-users at gluster.org> Subject: Re: [Gluster-users] Very slow performance on...

...tweak/tuning out there to make it fast? Or is this an expected behavior? If its, It is unacceptable. So slow. I cannot use this on production as it is terribly slow. The reason behind I use shard instead of stripe is i would like to eleminate files that bigger than brick size. Thanks, Gencer. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170630/b8a5bfec/attachment.html>

The current sharding has very limited use cases like vmstore where the clients accessing the sharded file will always be one. Krutuka will be the right person to answer your questions . Regards Rafi KC On 06/30/2017 04:28 PM, gencer at gencgiyen.com wrote: > > Hi, > > > > I have an 2 nodes with 20 bricks in total (10+10). > > > > First test: > > > > 2 Nodes with Distributed ? Striped ? Replicated (2 x 2) > > 10GbE Speed between nodes > > > > ?dd? performance:...

Il 30 giu 2017 3:51 PM, <gencer at gencgiyen.com> ha scritto: Note: I also noticed that you said ?order?. Do you mean when we create via volume set we have to make an order for bricks? I thought gluster handles (and do the math) itself. Yes, you have to specify the exact order Gluster is not flexible in this way and doesn...