<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-family:arial">On Sun, Feb 2, 2014 at 7:05 PM, James </span><span dir="ltr" style="font-family:arial"><<a href="mailto:purpleidea@gmail.com" target="_blank">purpleidea@gmail.com</a>></span><span style="font-family:arial"> wrote:</span><br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Feb 2, 2014 at 12:46 AM, Andrew Lau <<a href="mailto:andrew@andrewklau.com" target="_blank">andrew@andrewklau.com</a>> wrote:<br>
> Hi all,<br>
Hi,<br>
<div><br>
><br>
> Sadly my google skills aren't finding me any results - is there an option to<br>
> limit the CPU usage and/or the disk IO intensity of glusterfsd.<br>
</div>This is what cgroups are for. Looking forward to you setting this up<br>
and telling us how it goes and what the optimized values are. AFAIK,<br>
gluster doesn't have anything built in to limit this. I actually don't<br>
think that it makes sense for it to either.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks for the suggestions on cgroups, I actually did not think about that. I'll try that and report my findings.</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
><br>
> Example scenario, oVirt + gluster on the same host when it comes to adding<br>
> an extra host + replicated brick the original host with the brick goes crazy<br>
> with 500% cpu as it copies just under 1TB of data across to the new<br>
> replicated brick. Going crazy I mean everything else will hang, simple "ls"<br>
> command will take 30+ seconds.<br>
</div>Not sure what the correct solution is here. Maybe other gluster dev's<br>
can comment. Although it's really not detailed and you comment is<br>
unclear, so i'd elaborate before expecting a good response.<br>
<div><br></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Sorry for the poor choice of wordings - here's attempt 2:</div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Host 1 (1TB brick w/ no replica)</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Host 2 (NEW - 1TB brick to join Host 1 as replica 2)</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Top will report glusterfsd with up to 500% CPU usage (combined processes). Causing the system to grind to a halt very quickly. </div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
><br>
> Limiting the network bandwidth to 200Mbps seems to solve this issue, I'm<br>
> quite sure this is a CPU issue rather than IO so I was wondering if there's<br>
> any possibility to limit this down so the nic's itself don't have to get<br>
> rate limited.<br>
</div>I occasionally use shorewall+puppet-gluster to rate limit the network<br>
interfaces. Puppet-Gluster could do per interface and per port/gluster<br>
connection throttling.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Rate limiting seems to be only solution right now (until I take a look into cgoups). It seems the CPU cannot handle the high cpu usage that glusterfsd will create.</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> Thanks,<br>
> Andrew<br>
<br>
HTH,<br>
James<br>
</blockquote></div><br></div></div>