[Gluster-devel] Performance report and some issues

Jordi Moles jordi at cdmon.com
Thu Mar 6 12:58:49 UTC 2008


Hi,

I want to report back the performance issues i've had so far with 
glusterfs mainline 2.5, patch 690 and fuse-2.7.2glfs8.

I'm setting a mail system, which is all ran by Xen 3.2.0 and every 
"actual" piece of the mail system is a virtual machine from xen.

Anyway... the virtual machines accessing glusterfs are 6 dovecots and 4 
postfixs.  There are also 6 nodes, which share their own disk to the 
gluster filesystem. Two of the nodes, share 2 disks, one for the 
glusterfs, and the other for the namespace

these are the conf files:

****nodes with namespace****

volume esp
    type storage/posix
    option directory /mnt/compartit
end-volume

volume espa
    type features/posix-locks
    subvolumes esp
end-volume

volume espai
   type performance/io-threads
   option thread-count 15
   option cache-size 512MB
   subvolumes espa
end-volume

volume nm
    type storage/posix
    option directory /mnt/namespace
end-volume

volume ultim
    type protocol/server
    subvolumes espai nm
    option transport-type tcp/server
    option auth.ip.espai.allow *
    option auth.ip.nm.allow *
end-volume

*************


***nodes without namespace*****

volume esp
    type storage/posix
    option directory /mnt/compartit
end-volume

volume espa
    type features/posix-locks
    subvolumes esp
end-volume

volume espai
   type performance/io-threads
   option thread-count 15
   option cache-size 512MB
   subvolumes espa
end-volume

volume ultim
    type protocol/server
    subvolumes espai
    option transport-type tcp/server
    option auth.ip.espai.allow *
end-volume

*****************************


***clients****

volume espai1
    type protocol/client
    option transport-type tcp/client
    option remote-host 192.168.1.204
    option remote-subvolume espai
end-volume

volume espai2
    type protocol/client
    option transport-type tcp/client
    option remote-host 192.168.1.205
    option remote-subvolume espai
end-volume

volume espai3
    type protocol/client
    option transport-type tcp/client
    option remote-host 192.168.1.206
    option remote-subvolume espai
end-volume

volume espai4
    type protocol/client
    option transport-type tcp/client
    option remote-host 192.168.1.207
    option remote-subvolume espai
end-volume

volume espai5
    type protocol/client
    option transport-type tcp/client
    option remote-host 192.168.1.213
    option remote-subvolume espai
end-volume

volume espai6
    type protocol/client
    option transport-type tcp/client
    option remote-host 192.168.1.214
    option remote-subvolume espai
end-volume

volume namespace1
    type protocol/client
    option transport-type tcp/client
    option remote-host 192.168.1.204
    option remote-subvolume nm
end-volume

volume namespace2
    type protocol/client
    option transport-type tcp/client
    option remote-host 192.168.1.205
    option remote-subvolume nm
end-volume

volume grup1
    type cluster/afr
    subvolumes espai1 espai2
end-volume

volume grup2
    type cluster/afr
    subvolumes espai3 espai4
end-volume

volume grup3
    type cluster/afr
    subvolumes espai5 espai6
end-volume

volume nm
    type cluster/afr
    subvolumes namespace1 namespace2
end-volume

volume ultim
    type cluster/unify
    subvolumes grup1 grup2 grup3
    option scheduler rr
    option namespace nm
end-volume

************

The thing is that in earlier patches, the whole system used to hang, 
with many different error messages.

Right now, it's been on for days without any hang at all, but i'm facing 
serious performance issues.

By only running an "ls" command, it can take like 3 seconds to show 
something when the system is "under load". It doesn't happen at all when 
there's no activity, so i don't thing has anything to do with xen. Well, 
actually, "under load" can mean 3 mails arriving per second. I'm 
monitoring everything, and no virtual machine is using more than 20% of 
cpu or so.

First, i had log level on both nodes and clients set to DEBUG, but now 
is just WARNING, and i've restarted everything so many times.

I was suggested to use "type performance/io-threads" on the node side. 
It actually worked, before that, it wasn't 3 seconds, but 5 or more. 
I've set the "thread-count" value to different values and also "cache-size"

The system is supposed to handle a big amount of traffic, far more than 
3 mails a second.

What do you think about the whole set up? Should i keep using namespace? 
Should i use new nodes for namespaces? Should i use different values for 
iothread?

One last thing... i'm using reiserfs on the "storage devices" that nodes 
share. Should i be using XFS or something else?

Logs don't show any kind of error now... i don't have a clue of what is 
failing now....

I would be pleased if you could give some ideas.

Thank you.





More information about the Gluster-devel mailing list