<font><font face="arial,helvetica,sans-serif"><font><font>Hi David,<br><br><font>Yes <font>this<font> is one strange <font>f<font>ormula... There are two ways of reading it:<br><br><font>- </font>"one thread per 12<font>8MB of <font>RAM, times the number of CPUs in the system"<font><br>
On<font> one of <font>our typical OSSes<font> (2<font>4 GB, <font>8 cores), that would give: <font>((24*1024) / 128</font>) * 8 = 1536<br><font>And<font> that's waaaay out there...<br><br><font>- "<font>as many threads as you c<font>an fit (<font>128MB * numbers o<font>f CPUs) in the RAM of your system<font>"</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font><br>
<font><font>Which would then give: (24<font>*1024) / (128<font>*8) = 24<br><font><font>For a whole system, that's really low. But for <font>one single OST, i<font>t al<font>most makes sense, in <font>which case you'd want to multiply that by the number of OSTs connected to your OSS.</font></font></font></font></font></font><br>
</font></font></font></font><br><font>The way <font>we did <font>it here is that we identified that <font>the ma<font>jor limiting parameter is the software RAID<font>, b<font>oth in terms of bandwidth performance and CPU use<font>. So I did some tests on a spare machine to get so<font>me <font>load <font>and perf figures <font>for one array, <font>using sgpdd-survey<font>. Then<font>, taking <font>into account the number of<font> <font>OST per OSS (4) and the over<font>head of Lustre,<font> <font>I figured out<font></font> that the best thread coun<font>t would be <font>around 96<font> (which is 24*4, s<font>pot on).</font></font><br>
<br><font>One major <font>limit<font>ation i<font>n Lustre 1.8.x (I don't know <font>if it has changed in 2.x) is that only the global thread count for the OSS can <font>be specified. W<font><font>e ha<font>ve cases where all OSS threads are used on a single OST, and that <font>completely trashe<font>s the bandwidth and latency.<font> We would really need a max thread coun<font>t per OST too, s<font>o that no single OST<font> would get <font>hit <font>that way. <font>On ou<font>r systems</font></font>, I'd put the max OST thread count at <font>32 (to stay in the <font>software RAID performa<font>nce sweet spot)</font></font> and <font>the ma<font>x OSS <font>thread count at 96 (to <font>limit CPU <font>load)</font></font>.<br>
<br><font>Thanks!<br><font>JF<br></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font><br>
<br><br><div class="gmail_quote">On Mon, Oct 15, 2012 at 2:20 PM, David Noriega <span dir="ltr"><<a href="mailto:tsk133@my.utsa.edu" target="_blank">tsk133@my.utsa.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How does one estimate a good number of service threads? I'm not sure I<br>
understand the following: 1 thread / 128MB * number of cpus<br>
<div><div class="h5"><br>
On Wed, Oct 10, 2012 at 9:17 AM, Jean-Francois Le Fillatre<br>
<<a href="mailto:jean-francois.lefillatre@clumeq.ca">jean-francois.lefillatre@clumeq.ca</a>> wrote:<br>
><br>
> Hi David,<br>
><br>
> It needs to be specified as a module parameter at boot time, in<br>
> /etc/modprobe.conf. Check the Lustre tuning page:<br>
> <a href="http://wiki.lustre.org/manual/LustreManual18_HTML/LustreTuning.html" target="_blank">http://wiki.lustre.org/manual/LustreManual18_HTML/LustreTuning.html</a><br>
> <a href="http://wiki.lustre.org/manual/LustreManual20_HTML/LustreTuning.html" target="_blank">http://wiki.lustre.org/manual/LustreManual20_HTML/LustreTuning.html</a><br>
><br>
> Note that once created, the threads won't be destroyed, so if you want to<br>
> lower your thread count you'll need to reboot your system.<br>
><br>
> Thanks,<br>
> JF<br>
><br>
><br>
> On Tue, Oct 9, 2012 at 6:00 PM, David Noriega <<a href="mailto:tsk133@my.utsa.edu">tsk133@my.utsa.edu</a>> wrote:<br>
>><br>
>> Is this a parameter, ost.OSS.ost_io.threads_max, when set via lctl<br>
>> conf_parm will persist between reboots/remounts?<br>
>> _______________________________________________<br>
>> Lustre-discuss mailing list<br>
>> <a href="mailto:Lustre-discuss@lists.lustre.org">Lustre-discuss@lists.lustre.org</a><br>
>> <a href="http://lists.lustre.org/mailman/listinfo/lustre-discuss" target="_blank">http://lists.lustre.org/mailman/listinfo/lustre-discuss</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Jean-François Le Fillâtre<br>
> Calcul Québec / Université Laval, Québec, Canada<br>
> <a href="mailto:jean-francois.lefillatre@clumeq.ca">jean-francois.lefillatre@clumeq.ca</a><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
David Noriega<br>
CSBC/CBI System Administrator<br>
University of Texas at San Antonio<br>
One UTSA Circle<br>
San Antonio, TX 78249<br>
Office: BSE 3.114<br>
Phone: <a href="tel:210-458-7100" value="+12104587100">210-458-7100</a><br>
<a href="http://www.cbi.utsa.edu" target="_blank">http://www.cbi.utsa.edu</a><br>
<br>
Please remember to acknowledge the RCMI grant , wording should be as<br>
stated below:This project was supported by a grant from the National<br>
Institute on Minority Health and Health Disparities (G12MD007591) from<br>
the National Institutes of Health. Also, remember to register all<br>
publications with PubMed Central.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Lustre-discuss mailing list<br>
<a href="mailto:Lustre-discuss@lists.lustre.org">Lustre-discuss@lists.lustre.org</a><br>
<a href="http://lists.lustre.org/mailman/listinfo/lustre-discuss" target="_blank">http://lists.lustre.org/mailman/listinfo/lustre-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jean-François Le Fillâtre<br>Calcul Québec / Université Laval, Québec, Canada<br><a href="mailto:jean-francois.lefillatre@clumeq.ca" target="_blank">jean-francois.lefillatre@clumeq.ca</a><br>
<br>