我有一个通过运行Solaris 10的TCP将数据从纽约分发到东京的应用程序。平均吞吐量<1Mbps，峰值吞吐量可以达到每秒20-30Mbps，尽pipe典型的峰值更像是10Mbps。 单个消息大小很小（〜300字节），延迟的一致性是关键。 这意味着我们正试图删除批处理又名，所以老鹰closures＆应用程序被configuration为发送而不是队列然后发送。
纽约和东京之间的RTT约为180ms，TCP窗口调整到理论吞吐量在40Mbps左右，也就是1M tcp_xmit_hiwat / tcp_rcv_hiwat。 tcp_max_buf和tcp_cwnd_max也是1M。
这里的问题是，我们经常会间歇性地看到发件人得到EWOULDBLOCK的神秘“暂停”，导致在内部队列中build立起来，然后释放数据。 这里有两个问题
前者是解决问题的关键，如果我能解决这个问题，那么后者就不会发生。 然而后者很奇怪，我天真地期待它能够迅速攀升到峰值吞吐量，并保持在那里，直到它通过积压。
CPU利用率在两端都不是问题，SA认为盒子看起来不错。 广域网链路上的networking拥塞也不是问题，networking认为networking看起来不错。 事实上，每个人都认为每件作品看起来都不错，但performance依然不佳！
有关如何优化这种情况的任何想法？ 还是要进行调查的事情，可能会提供有关正在发生的事情的暗示？
EWOULDBLOCK / EAGAIN表示无法立即发送数据。 我们需要更多关于你的代码的细节来弄明白。
我不是开发人员，但我build议你尝试用I / O多路复用器replace非阻塞套接字：select或轮询或/ dev / poll并检查套接字是否准备好写入。 它可能会改变你的程序的行为，或者在最坏的情况下给你更多的debugging和暗示真正的问题。
在这么长的距离上，所有的数据包可能使用不同的路由，通过不同的AS，所以没有人能真正评估networking质量。 一个数据包可能需要很长时间才能到达，并且因为互联网深处的问题而得到确认（这可能是接近的，否则人们会报告并修复它），尝试从其他位置join。 如果单个数据包需要很长时间才能得到确认，则TCP窗口将卡住，进一步的数据可能不会被处理。 您可能想尝试将TCP窗口大小调整为更高的值。
此外，您可以简单地运行mtr来快速检查networking质量。 运行它几次，因为数据包可能采取不同的path。
希望这有助于，不知何故：/