Hi, Even I ran into 100% cpu utilization with patch-796. But it was due to badly configured aggregate-size. An aggregate-size of 1KB kept the cpu usage well around 54%. regards, On Thu, Aug 28, 2008 at 5:12 PM, Dai, Manhong <daimh at umich.edu> wrote: > Hi, > > > Repository revision: glusterfs--mainline--2.5--patch-795 is the > version > I am using. > > > Our cluster is in use, so I cannot confirm this problem on other > releases. Since removing write-behind can get rid of this problem, I can > live with that. > > > > Best, > Manhong > > > On Thu, 2008-08-28 at 07:48 +0400, Raghavendra G wrote: > > Hi, > > > > what patch are you using? with glusterfs--mainline--3.0--patch-329 and > > a basics setup of write-behind over protocol/client, glusterfs cpu > > usage never went above 65% in my tests. Can you please confirm whether > > the problem persists in patch-329? > > > > regards, > > > > On Thu, Aug 28, 2008 at 6:27 AM, Dai, Manhong <daimh at umich.edu> wrote: > > Hi, > > > > client.vol is > > > > volume unify-brick > > type cluster/unify > > option scheduler rr # round robin > > option namespace muskie-ns > > # subvolumes muskie-brick pike1-brick pike2-brick pike3-brick > > subvolumes muskie-brick pike1-brick pike3-brick > > end-volume > > > > volume wb > > type performance/write-behind > > option aggregate-size 1MB > > option flush-behind on > > subvolume > > client.vol is > > > > volume unify-brick > > type cluster/unify > > option scheduler rr # round robin > > option namespace muskie-ns > > # subvolumes muskie-brick pike1-brick pike2-brick pike3-brick > > subvolumes muskie-brick pike1-brick pike3-brick > > end-volume > > > > volume wb > > type performance/write-behind > > option aggregate-size 1MB > > option flush-behind on > > subvolumes unify-brick > > end-volume > > > > > > yes abcdefghijklmn | while read l; do echo $l; done > a > > > > would cause glusterfs process 100% busy and files system hang > > when the output size is around the aggregate-size. > > > > > > removing write-behind translator would get rid of this > > problem. > > > > > > s unify-brick > > end-volume > > > > > > command "yes abcdefghijklmn | while read l; do echo $l; done > > > a" would cause glusterfs process 100% busy and files system > > hang when the output size is around the aggregate-size. > > removing write-behind translator would get rid of this > > problem. > > > > > > > > > > Best, > > Manhong > > > > > > > > _______________________________________________ > > Gluster-users mailing list > > Gluster-users at gluster.org > > http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users > > > > > > > > > > -- > > Raghavendra G > > > > A centipede was happy quite, until a toad in fun, > > Said, "Prey, which leg comes after which?", > > This raised his doubts to such a pitch, > > He fell flat into the ditch, > > Not knowing how to run. > > -Anonymous > > > -- Raghavendra G A centipede was happy quite, until a toad in fun, Said, "Prey, which leg comes after which?", This raised his doubts to such a pitch, He fell flat into the ditch, Not knowing how to run. -Anonymous -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zresearch.com/pipermail/gluster-users/attachments/20080829/0ae7704e/attachment.htm
