similar to: Performance issues on GlusterFS with KVM

hi, all: I'm now working on constructing KVM servers based on glusterfs. After many times searching on web, i found just a little information for this task, so I had to write this email for seeking systematically instruction of how to make glusterfs and KVM working together perfectly. And here are some questions I can not find any clearly answers: 1. what are the

i'm having difficulty running KVM virtual machines off of a glusterFS volume mounted using the glusterFS client. i am running centOS 6, 64-bit. i am using virt-install to create my images but encountering the following error: qemu: could not open disk image /mnt/myreplicatestvolume/testvm.img: Invalid argument (see below for a more lengthy version of the error) i have found an example of

Hi guys, I have spent many days on debuging read/write performance of glusterfs with samba-gluster-vfs plugin recently. The write performance is okay, but the read speed is always dispirited. The testing environment is like this: OS: centos 6.4 hosts: two hosts, one for samba server which glusterfs with samba-glusterfs-vfs runs on it, the other for samba client glusterfs version:

Mandi! Rowland Penny via samba In chel di` si favelave... >> In samba the share is: > I wish people wouldn't do this, if you are going to post a share, > please post the global section as well. Sorry. # Global parameters [global] log file = /var/log/samba/log.%M map to guest = Bad User netbios aliases = CUPSSV FILESV HOMESV ntlm auth = mschapv2-and-ntlmv2-only panic

Hello folks, We test samba performance with local ext4 and glusterfs backends, it shows performance is very different. The samba server has 4 1Gbps NICs and bond with mode 6, backend storage is raid0 with 12 SAS disks. A LUN is created over all disks, make as EXT4 file system, and used as glusterfs brick. On the samba server, use dd test local ext4 and glusterfs, write bandwidth are 477MB/s and

Hello folks, We test samba performance with local ext4 and glusterfs backends, it shows performance is very different. The samba server has 4 1Gbps NICs and bond with mode 6, backend storage is raid0 with 12 SAS disks. A LUN is created over all disks, make as EXT4 file system, and used as glusterfs brick. On the samba server, use dd test local ext4 and glusterfs, write bandwidth are 477MB/s and

I would go with at least 4 HDDs per host in RAID 10. Then focus on network performance where bottleneck usualy is for gluster. On Sat, Mar 24, 2018, 00:44 Jayme <jaymef at gmail.com> wrote: > Do you feel that SSDs are worth the extra cost or am I better off using > regular HDDs? I'm looking for the best performance I can get with glusterFS > > On Fri, Mar 23, 2018 at

I wanted to call out Marco Agostini, who so kindly wrote up a post on using various tools to monitor GlusterFS performance: http://community.gluster.org/p/some-tools-to-monitor-performance/ Please review and comment as you see fit. If you find it helpful, let Marco know by clicking the "like" button. While we're on the subject of Monitoring GlusterFS, Gluster Superstar Craig

Hi folks, We found that samba performance downgrade a lot with glusterfs backend. volume info as followed, Volume Name: vol1 Type: Distribute Status: Started Number of Bricks: 1 Transport-type: tcp Bricks: Brick1: pana53:/data/ Options Reconfigured: auth.allow: 192.168.* features.quota: on nfs.disable: on Use dd (bs=1MB) or iozone (block=1MB) to test write performance, about 400MB/s. #dd

Hi, I want to give an update for this. I also tested READ speed. It seems, sharded volume has a lower read speed than striped volume. This machine has 24 cores with 64GB of RAM . I really don?t think its caused due to low system. Stripe is kind of a shard but a fixed size based on stripe value / filesize. Hence, I would expect at least the same speed or maybe little slower. What I get is

No, you don't need to do any of that. Just executing volume-set commands is sufficient for the changes to take effect. -Krutika On Wed, Jun 21, 2017 at 3:48 PM, Chris Boot <bootc at bootc.net> wrote: > [replying to lists this time] > > On 20/06/17 11:23, Krutika Dhananjay wrote: > > Couple of things: > > > > 1. Like Darrell suggested, you should enable

[replying to lists this time] On 20/06/17 11:23, Krutika Dhananjay wrote: > Couple of things: > > 1. Like Darrell suggested, you should enable stat-prefetch and increase > client and server event threads to 4. > # gluster volume set <VOL> performance.stat-prefetch on > # gluster volume set <VOL> client.event-threads 4 > # gluster volume set <VOL>

There are options that can help a little bit with the ls/find. Still, many devs will need to know your settings, so the volume's info is very important. Try the 'noatime,nodiratime' (if ZFS supports them). Also, as this is a new cluster you can try to setup XFS and verify if the issue is the same. RedHat provide an XFS options' calculator but it requires aby kind of subscription

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

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: > > >

My take is that unless you have loads of data and are trying to optimize for cost/TB, HDDs are probably not the right choice. This is particularly true for random I/O workloads for which HDDs are really quite bad. I'd recommend a recent gluster release, and some tuning because the default settings are not optimized for performance. Some options to consider: client.event-threads

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 and higher Downloading a large file from internet and directly to the gluster: 250-300mb/s Now same test without Stripe but with sharding. This results are same when I set shard size 4MB or

Hi, First I appreciate for you all, with your last week's points mentioned in the problem I meet with slow samba vfs write performance. Then I use fastcopy software to test windows clients write performance, it tells the same performance with iozone rewrite results, reach 450MB/s each client. Then I use the same smb.conf test read performance, it shows slow read performance compare with

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't help you at all. -------------- next part -------------- An

I haven't test it completely for Apache , when I finish that I will post it ASAP. BTW, Have you archieved the same goal with gold-plugin???I once tried it but just got a failure for llvm tools is not completely compatible with GNU ones. ----- Original Message ----- From: "Keppler, Dave" <dkeppler at mitre.org> To: "Nan Zhu" <zhunansjtu at gmail.com>;