[Gluster-users] glsuterfs cpu parallelism option?
tobias at linuxdingsda.de
Thu Mar 14 12:10:22 UTC 2013
it seems the problem only occurs when dealing with a lot of small files.
The performance drops to ~30-50MB/s while the glusterfs tasks peaks at
200%CPU on the brick where the data is being written to gluster.
Writing big files still isn't nearly as fast as the blockdevice but at
least it can easily handle 450-500mb/s which is about 50% of hardware
We fiddled a bit with gluster and were hoping that we could reduce CPU
load but so far with no luck. Does anyone have some insight into how to
reduce the cpu load of glusterfs or how to spread it over more than 2 CPUS?
Is that something that gets better with the current beta release?
backup-eu1:~# gluster volume info gv0
Volume Name: gv0
Volume ID: 0d2e9442-8109-46db-bd6a-84d4f2148bb3
Number of Bricks: 1 x 2 = 2
global config file options:
option transport-type tcp
option transport.socket.keepalive-time 10
option transport.socket.nodelay on
option transport.socket.keepalive-interval 2
option transport.socket.read-fail-log off
Any hints are greatly appreciated.
On 03/13/2013 02:07 PM, Tobias Winter wrote:
> we're setting up a glusterfs server apir with replication and am testing
> performance. While doing that we stumbled over that in top:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 5151 root 20 0 6184m 5.9g 2540 R 200 9.3 28:27.99 glusterfs
> 5618 root 20 0 392m 34m 2116 S 38 0.1 24:53.10 glusterfsd
> When under heavy load, CPU usage will not exceed 200% hence I'm assuming
> it only spawns two threads. Can that be tweaked?
> My hope is that when that is increased and glusterfs can use more cpus,
> the overall performance will increase drastically.
> Gluster-users mailing list
> Gluster-users at gluster.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 263 bytes
Desc: OpenPGP digital signature
More information about the Gluster-users