Without knowing your setup or what is limiting you; I can suggest two options;
1. Faster hardware (links speed / peer disk) 2. Switch to Protocol C digimer On 2019-10-21 4:36 p.m., G C wrote: > Is there anything that will force the OOS to push what is out of sync? > > > On Mon, Oct 21, 2019 at 11:00 AM Digimer <li...@alteeve.ca > <mailto:li...@alteeve.ca>> wrote: > > Tuning is quite instance-specific. I would always suggest starting by > commenting out all tuning, see how it behaves, then tune. Premature > optimization never is. > > digimer > > On 2019-10-21 1:31 p.m., G C wrote: > > Would any of these values being changed help or would it need to > be the > > actual speed between the two nodes that needs to be increased? > > > > disk { > > on-io-error detach; > > c-plan-ahead 10; > > c-fill-target 24M; > > c-min-rate 80M; > > c-max-rate 720M; > > } > > net { > > protocol A; > > max-buffers 36k; > > sndbuf-size 1024k; > > rcvbuf-size 2048k; > > } > > > > Thank you > > > > > > > > On Mon, Oct 21, 2019 at 10:10 AM Digimer <li...@alteeve.ca > <mailto:li...@alteeve.ca> > > <mailto:li...@alteeve.ca <mailto:li...@alteeve.ca>>> wrote: > > > > I assumed it wasn't paused, but that confirms it. > > > > Protocol A allows for out of sync to grow. It says "when the > data in on > > the network buffer to send to the peer, consider the write > complete". As > > such, data that hasn't made it over to the peer causes oos to > climb. If > > you have a steady write rate that is faster than your transmit > > bandwidth, then seeing fairly steady OOS makes sense. > > > > To "fix" it, you need to increase the connection speed to the > peer node. > > Or, less likely, if the peer's disk is slower than the bandwidth > > connecting it, speed up the disk write speed. > > > > In either case, what you are seeing is not a surprise, and > it's not a > > problem with DRBD. The only other option is to use protocol C, > so that a > > write isn't complete until it reaches the peer, but that will > slow down > > the write performance of the primary node to be whatever speed > you have > > to the peer. That's likely unacceptable. > > > > In short, you have a hardware/resource issue. > > > > digimer > > > > On 2019-10-21 12:19 p.m., G C wrote: > > > version: 8.4.10 > > > Ran the resume-sync all and received: > > > 0: Failure: (135) Sync-pause flag is already cleared > > > Command 'drbdsetup-84 resume-sync 0' terminated with exit > code 10 > > > > > > Protocol used is 'A', our systems are running on a cloud > environment. > > > > > > > > > > > > > > > On Mon, Oct 21, 2019 at 9:09 AM Digimer <li...@alteeve.ca > <mailto:li...@alteeve.ca> > > <mailto:li...@alteeve.ca <mailto:li...@alteeve.ca>> > > > <mailto:li...@alteeve.ca <mailto:li...@alteeve.ca> > <mailto:li...@alteeve.ca <mailto:li...@alteeve.ca>>>> wrote: > > > > > > 8.9.2 is the utils version, what is the kernel module > version? > > > (8.3.x/8.4.x/9.0.x)? > > > > > > It's possible something paused sync, but I doubt it. You > can try > > > 'drbdadm resume-sync all'. The oos number should change > > constantly, any > > > time a block changes it should go up and every time a block > > syncs it > > > should go down. > > > > > > What protocol are you using? A, B or C? > > > > > > digimer > > > > > > -- > > Digimer > > Papers and Projects: https://alteeve.com/w/ > > "I am, somehow, less interested in the weight and convolutions of > > Einstein’s brain than in the near certainty that people of > equal talent > > have lived and died in cotton fields and sweatshops." - > Stephen Jay > > Gould > > > > > -- > Digimer > Papers and Projects: https://alteeve.com/w/ > "I am, somehow, less interested in the weight and convolutions of > Einstein’s brain than in the near certainty that people of equal talent > have lived and died in cotton fields and sweatshops." - Stephen Jay > Gould > -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould _______________________________________________ Star us on GITHUB: https://github.com/LINBIT drbd-user mailing list drbd-user@lists.linbit.com https://lists.linbit.com/mailman/listinfo/drbd-user