Re: [gpfsug-discuss] Steps for gracefully handling bandwidth reduction during network maintenance

2019-06-17 Thread Marc A Kaplan
Please note that the maxmbps parameter of mmchconfig is not part of the QOS features of the mmchqos command. mmchqos can be used to precisely limit IOPs. You can even set different limits for NSD traffic originating at different nodes. However, use the "force" of QOS carefully! No doubt you can

Re: [gpfsug-discuss] Steps for gracefully handling bandwidth reduction during network maintenance

2019-06-17 Thread Luis Bolinches
Hi Writing from phone so excuse the typos. 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

Re: [gpfsug-discuss] Steps for gracefully handling bandwidth reduction during network maintenance

2019-06-17 Thread Alex Chekholko
Hi all, My experience with MaxMBpS was in the other direction but it did make a difference. We had lots of spare network bandwith (that is, the network was not the bottleneck) and in the course of various GPFS tuning it also looked like the disks were not too busy, and the NSDs were not too

Re: [gpfsug-discuss] Steps for gracefully handling bandwidth reduction during network maintenance

2019-06-17 Thread Christopher Black
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. We've only ever used QoS for throttling

Re: [gpfsug-discuss] Steps for gracefully handling bandwidth reduction during network maintenance

2019-06-17 Thread Skylar Thompson
IIRC, maxMBpS isn't really a limit, but more of a hint for how GPFS should use its in-memory buffers for read prefetches and dirty writes. On Mon, Jun 17, 2019 at 09:31:38AM -0700, Alex Chekholko wrote: > Hi Chris, > > I think the next thing to double-check is when the maxMBpS change takes >

Re: [gpfsug-discuss] Steps for gracefully handling bandwidth reduction during network maintenance

2019-06-17 Thread Luis Bolinches
Hi I would really look into QoS instead. -- Cheers > On 17 Jun 2019, at 19.33, Alex Chekholko wrote: > > Hi Chris, > > I think the next thing to double-check is when the maxMBpS change takes > effect. You may need to restart the nsds. Otherwise I think your plan is > sound. > >

Re: [gpfsug-discuss] Steps for gracefully handling bandwidth reduction during network maintenance

2019-06-17 Thread Alex Chekholko
Hi Chris, I think the next thing to double-check is when the maxMBpS change takes effect. You may need to restart the nsds. Otherwise I think your plan is sound. Regards, Alex On Mon, Jun 17, 2019 at 9:24 AM Christopher Black wrote: > Our network team sometimes needs to take down sections

[gpfsug-discuss] Steps for gracefully handling bandwidth reduction during network maintenance

2019-06-17 Thread Christopher Black
Our network team sometimes needs to take down sections of our network for maintenance. Our systems have dual paths thru pairs of switches, but often the maintenance will take down one of the two paths leaving all our nsd servers with half bandwidth. Some of our systems are transmitting at a