我在两个节点上设置了DRBD,并于昨天开始使用它。大约一个小时后,它重新整合了50%的分区。又过了12个小时,达到了79%,而且移动非常缓慢。
下面是cat /proc/drbd展示的内容:
1: cs:SyncTarget ro:Primary/Secondary ds:Inconsistent/UpToDate C r-----
ns:464931976 nr:191087032 dw:656013660 dr:214780588 al:100703 bm:21100 lo:7 pe:0 ua:0 ap:7 ep:1 wo:f oos:92241852
[==============>.....] sync'ed: 79.2% (90076/431396)M
finish: 76:13:38 speed: 332 (8,680) want: 19,480 K/sec我查看了网络流量,我在1G接口上使用了1M到20M之间的流量。试着在这一切发生的时候运行iperf,我的阅读量达到了930米。试着将同步率调整为10米、50米、500米,但没有效果。没有运气的情况下调整包的大小。
现在,您可以从状态中看到的警告是,我的主节点是不一致的。因此,我假设操作系统实际上是在处理一个次要节点,而resync正在运行。但考虑到吞吐量如此之低,我不明白为什么同步速度不快。
关于我下一步可以尝试什么有什么想法吗?估计完成76小时并不是我所期待的:(特别是不知道原因,所以出现了某种中断,我不知道如何使数组快速保持一致。
谢谢!
编辑:我在net部分尝试了以下设置,但没有效果:
sndbuf-size 512k;
max-buffers 20480;
max-epoch-size 16384;
unplug-watermark 20480;编辑2:没有明显的原因,速度跳到10~30米,在我停止调整所有的吐露。同步率达98.8%,降至~300 K。两台服务器上的日志中都没有消息。巧合的是,我看到了运行在这个分区之上的MySQL数据库中插入活动的激增。有什么想法吗?
编辑3:版本: 8.4.2 (api:1/proto:86-101)
发布于 2012-12-27 15:59:34
在@Nils评论之后,我开始研究磁盘是如何使用的。并且注意到,在系统重新配置到DRBD之前,我得到的读取比以前多得多。进一步的研究表明磁盘利用率接近100%,并减缓了当时正在运行的批处理过程。修复MySQL配置以增加缓冲池大小以消除大多数读取,看起来解决了这个问题。
所以问题是驱动器太忙了,他们无法处理DRBD想要扔给他们的大量的再同步工作。
发布于 2012-12-26 16:19:51
尝试强制同步速率
drbdsetup /dev/drbd0 syncer -r 100M您还可以通过配置中的syncer {}将其设置为“重新启动后”。
发布于 2012-12-30 22:15:29
你已经找到了问题的根源--严重的阅读。调整sndbuf-size确实有助于解决严重的写io问题(但增加了协议A模式下的异步性),rcvbuf-size可能会在您的情况下有所帮助。
但更好的解决办法是消除问题的根源。
更多的读取也可能与DRBD-元设备有关(虽然我也希望在写的情况下更多)。
https://serverfault.com/questions/460981
复制相似问题