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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20080827/1e01fd05/attachment.html>
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20080828/ee44291c/attachment.html>
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://supercolony.gluster.org/pipermail/gluster-users/attachments/20080829/0ae7704e/attachment.html>
Hi, Thanks a lot for look into this problem. Actually the problem for me is the output file stop growing, and cpu utilization keeps at 100% forever. Best, Manhong On Fri, 2008-08-29 at 11:10 +0400, Raghavendra G wrote:> 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 >