<html><body><p><font size="2">Hi<br></font><font size="2"><br></font><font size="2">Writing from phone so excuse the typos. <br></font><font size="2"><br></font><font size="2">Assuming you have a system pool (metadata) and some other pool/s you can set limits on maintenance class that you done already and on other class that would affect all the other ops. You can add those per node or nodeclass that can be matched to what part/s of network you are working with. <br></font><font size="2"><br></font><font size="2">Changes are online and immediate. And you can measure normal load just by having QoS activated and looking into the values for few days. <br></font><font size="2"><br></font><font size="2">Hope makes some sense the above. <br></font><font size="2"><br></font><font size="2">--<br></font><font size="2">Cheers<br></font><font size="2"><br></font><font size="2">> On 17 Jun 2019, at 19.48, Christopher Black <cblack@nygenome.org> wrote:<br></font><font size="2">> <br></font><font size="2">> The man page indicates that maxMBpS can be used to "artificially limit how much I/O one node can put on all of the disk servers", but it might not be the best choice. Man page also says maxmbps is in the class of mmchconfig changes take place immediately.<br></font><font size="2">> We've only ever used QoS for throttling maint operations (restripes, etc) and are unfamiliar with how to best use it to throttle client load.<br></font><font size="2">> <br></font><font size="2">> Best,<br></font><font size="2">> Chris<br></font><font size="2">> <br></font><font size="2">> On 6/17/19, 12:40 PM, "gpfsug-discuss-bounces@spectrumscale.org on behalf of Skylar Thompson" <gpfsug-discuss-bounces@spectrumscale.org on behalf of skylar2@uw.edu> wrote:<br></font><font size="2">> <br></font><font size="2">> IIRC, maxMBpS isn't really a limit, but more of a hint for how GPFS should<br></font><font size="2">> use its in-memory buffers for read prefetches and dirty writes.<br></font><font size="2">> <br></font><font size="2">>> On Mon, Jun 17, 2019 at 09:31:38AM -0700, Alex Chekholko wrote:<br></font><font size="2">>> Hi Chris,<br></font><font size="2">>> <br></font><font size="2">>> I think the next thing to double-check is when the maxMBpS change takes<br></font><font size="2">>> effect. You may need to restart the nsds. Otherwise I think your plan is<br></font><font size="2">>> sound.<br></font><font size="2">>> <br></font><font size="2">>> Regards,<br></font><font size="2">>> Alex<br></font><font size="2">>> <br></font><font size="2">>> <br></font><font size="2">>> On Mon, Jun 17, 2019 at 9:24 AM Christopher Black <cblack@nygenome.org><br></font><font size="2">>> wrote:<br></font><font size="2">>> <br></font><font size="2">>>> Our network team sometimes needs to take down sections of our network for<br></font><font size="2">>>> maintenance. Our systems have dual paths thru pairs of switches, but often<br></font><font size="2">>>> the maintenance will take down one of the two paths leaving all our nsd<br></font><font size="2">>>> servers with half bandwidth.<br></font><font size="2">>>> <br></font><font size="2">>>> Some of our systems are transmitting at a higher rate than can be handled<br></font><font size="2">>>> by half network (2x40Gb hosts with tx of 50Gb+).<br></font><font size="2">>>> <br></font><font size="2">>>> What can we do to gracefully handle network maintenance reducing bandwidth<br></font><font size="2">>>> in half?<br></font><font size="2">>>> <br></font><font size="2">>>> Should we set maxMBpS for affected nodes to a lower value? (default on our<br></font><font size="2">>>> ess appears to be maxMBpS = 30000, would I reduce this to ~4000 for 32Gbps?)<br></font><font size="2">>>> <br></font><font size="2">>>> Any other ideas or comments?<br></font><font size="2">>>> <br></font><font size="2">>>> Our hope is that metadata operations are not affected much and users just<br></font><font size="2">>>> see jobs and processes read or write at a slower rate.<br></font><font size="2">>>> <br></font><font size="2">>>> <br></font><font size="2">>>> <br></font><font size="2">>>> Best,<br></font><font size="2">>>> <br></font><font size="2">>>> Chris<br></font><font size="2">>>> ------------------------------<br></font><font size="2">>>> This message is for the recipient???s use only, and may contain<br></font><font size="2">>>> confidential, privileged or protected information. Any unauthorized use or<br></font><font size="2">>>> dissemination of this communication is prohibited. If you received this<br></font><font size="2">>>> message in error, please immediately notify the sender and destroy all<br></font><font size="2">>>> copies of this message. The recipient should check this email and any<br></font><font size="2">>>> attachments for the presence of viruses, as we accept no liability for any<br></font><font size="2">>>> damage caused by any virus transmitted by this email.<br></font><font size="2">>>> _______________________________________________<br></font><font size="2">>>> gpfsug-discuss mailing list<br></font><font size="2">>>> gpfsug-discuss at spectrumscale.org<br></font><font size="2">>>> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br></font><font size="2">>>> <br></font><font size="2">> <br></font><font size="2">>> _______________________________________________<br></font><font size="2">>> gpfsug-discuss mailing list<br></font><font size="2">>> gpfsug-discuss at spectrumscale.org<br></font><font size="2">>> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br></font><font size="2">> <br></font><font size="2">> <br></font><font size="2">> --<br></font><font size="2">> -- Skylar Thompson (skylar2@u.washington.edu)<br></font><font size="2">> -- Genome Sciences Department, System Administrator<br></font><font size="2">> -- Foege Building S046, (206)-685-7354<br></font><font size="2">> -- University of Washington School of Medicine<br></font><font size="2">> _______________________________________________<br></font><font size="2">> gpfsug-discuss mailing list<br></font><font size="2">> gpfsug-discuss at spectrumscale.org<br></font><font size="2">> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br></font><font size="2">> <br></font><font size="2">> <br></font><font size="2">> ________________________________<br></font><font size="2">> <br></font><font size="2">> This message is for the recipient’s use only, and may contain confidential, privileged or protected information. Any unauthorized use or dissemination of this communication is prohibited. If you received this message in error, please immediately notify the sender and destroy all copies of this message. The recipient should check this email and any attachments for the presence of viruses, as we accept no liability for any damage caused by any virus transmitted by this email.<br></font><font size="2">> _______________________________________________<br></font><font size="2">> gpfsug-discuss mailing list<br></font><font size="2">> gpfsug-discuss at spectrumscale.org<br></font><font size="2">> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a> <br></font><font size="2">> <br></font><BR>
Ellei edellä ole toisin mainittu: / Unless stated otherwise above:<BR>
Oy IBM Finland Ab<BR>
PL 265, 00101 Helsinki, Finland<BR>
Business ID, Y-tunnus: 0195876-3 <BR>
Registered in Finland<BR>
<BR>
</body></html>