java – EC2上jgroups通道丢失数据包的问题
作者：互联网
在尝试在亚马逊的64位Linux AMI上运行的Jgroups 3.1.0-FINAL上设置EC2(大型实例)上的Infinispan时,我们一直看到不一致的网络故障.空缓存启动正常并且似乎工作了一段时间但是一旦缓存已满,新服务器获得同步会导致缓存锁定.
我们决定推出自己的缓存,但看到大致相同的行为.在同步期间正在交换10兆字节但它们没有被淹没.有来回的数据 – >应用程序级别的ack会话,但看起来某些消息传递永远不会到达远程.
在查看UNICAST跟踪日志记录时,我看到以下内容：
# my application starts a cache refresh operation
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] DEBUG c.m.e.q.c.l.DistributedMapManager - i-f6a9d986: from i-d2e29fa2: search:REFRESH
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] INFO c.m.e.q.c.l.DistributedMapRequest - starting REFRESH from i-d2e29fa2 for map search, map-size 62373
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] DEBUG c.m.e.q.c.l.DistributedMapManager - i-f6a9d986: to i-d2e29fa2: search:PUT_MANY, 50 keyValues
# transmits a block of 50 values to the remote but this never seems to get there
01:02:12.004 [Incoming-1,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> DATA(i-d2e29fa2: #11, conn_id=10)
# acks another window
01:02:12.004 [Incoming-1,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> ACK(i-d2e29fa2: #4)
# these XMITs happen for over and over until 01:30:40
01:02:12.208 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #6)
01:02:12.209 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #7)
01:02:12.209 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #8)
...
这是我们的Jgroups stack.我们在运行时使用我们自己的EC2_PING版本替换PING协议,该版本使用AWS调用来查找其他集群成员候选者.这不是连接问题.
有什么想法为什么有些数据包没有到达目的地？
解决方法:
Any ideas why some of the packets are not arriving at their destination?
这是一个有趣的追踪问题.它似乎比其他实例更多地影响某些EC2实例.问题在于通过UDP在EC2实例之间发送大数据包.
缓存同步代码向远程服务器发送大约300k的消息,该消息被分段(使用FRAG2)为4个60k(默认大小)的数据包和1个43k的数据包,这些数据包被发送到远程信箱.由于某些网络限制,远程盒仅接收最后(第5个)43k消息. 60k的消息永远不会到来.这似乎只发生在某些主机对之间 – 其他对可以与大数据包大小进行良好通信.这不是普遍的是我花了这么长时间来隔离诊断问题.
我最初认为这是一个UDP接收器窗口大小问题,并试图调整它(sysctl -w net.core.rmem_max = 10240000),但这没有帮助.看看tcpdump显示60k数据包没有到达远程主机.只有43k包.
解决方案是将碎片尺寸减小到16k(32k可能没问题,但我们保守).对于数据包大小存在一些内部AWS限制,因为它们围绕亚马逊的虚拟网络传输,该网络正在过滤大于5万的大型UDP数据包.默认的Jgroups片段大小(60k)是大IMO,可能应该减少到32k或其他东西.
我们向亚马逊提交了这张票,他们承认了这个问题,但一般的回答是他们很难修复.我们调整了片段大小并且正在工作,因此票据已关闭.从机票中引用：
From: Amazon Web Services
This is an update for case XXXXXXXXX. We are currently limited to packet sizes of 32k and below on Amazon EC2 and can confirm the issues you are facing for larger packet sizes. We are investigating a solution to this limitation. Please let us know if you can keep your packet sizes below this level, or if this is severe problem blocking your ability to operate.
We are actively looking into increasing the packet size along with other platform improvements, and apologize for this inconvenience.
关于EC2的其他评论.首先,我们看到同一可用区域中的主机所需的TTL大于> 8.如果您使用多播,请确保您的TTL设置为128或其他.我们认为这最初是问题,但最终并非如此.
希望这有助于其他人.
标签：udp,java,amazon-ec2,infinispan,jgroups 来源： https://codeday.me/bug/20190517/1120668.html