我们有一个用Java编写的低延迟交易系统（Feed处理程序，分析，订单输入）。它广泛使用TCP和UDP，它不使用Infiniband或其他非标准网络。
有人可以评论各种操作系统或操作系统配置的权衡来部署这个系统吗？虽然吞吐量对于跟上现代价格源非常重要，但延迟是我们的首要任务。
Solaris因为创建Java而成为一个自然的候选者;我应该使用Sparc还是x64处理器？
我听说过关于RHEL和SLERT的好东西，是那些在我们的基准测试中使用的Linux版本。
是否有人针对上述操作系统测试了Windows？还是假设跟不上？
我想将Java与C ++争论留给另一个线程。
答案 0 :(得分：17)
供应商喜欢这种基准。你有代码，对吗？
IBM，Sun / Oracle，惠普都希望在他们的设备上运行您的应用程序以展示其优势。
让他们这样做。如果您有代码，请让供应商在他们的装备上进行演示，以显示哪种代码最符合您的需求。
这很容易，无痛，免费，而且是事实。最终决定将是容易和明显的。您将了解如何安装和调整以最大限度地提高性能。
我讨厌做的是在编写代码之前预测这类事情。在我们完成所有用例的识别之前，有太多客户要求提供H / W和OS建议。要求这种预知是简单的疯狂。
但你有代码。您可以生成运行代码的测试用例。那是完美的。
答案 1 :(得分：5)
对于交易环境，除了低延迟之外，您可能还会关注一致性和延迟，因此尽可能地关注减少GC暂停的影响可能会比不同的OS选择带来更多好处。
但是，如果您计划在每微秒计数的环境中使用您的交易系统，那么您真的将不得不忍受从当前一代VM中获得的缺乏一致性 - 没有一个（除了实时）保证低微秒GC暂停。当然，在这个级别上，您将遇到来自OS活动（进程抢占，中断处理，页面错误等）的相同问题。在这种情况下，Linux的一个实时变体将帮助您。
答案 2 :(得分：2)
我不会因为它是Windows而排除Windows。我在过去几年中的经验是，与同一硬件上的Linux或Soaris x86相比，Windows版本的Sun JVM通常是最成熟的性能。适用于Solaris SPARC的JVM也可能不错，但我想在x86上安装Windows可以获得更多功能，而且花费更少。
答案 3 :(得分：1)
我可能会担心垃圾收集会在操作系统之前造成延迟;你有没有考虑调整它？
如果我愿意花时间试用不同的操作系统，我会尝试使用Solaris 10和NetBSD，可能还有一个Linux版本。
我试验了32位vs 64位架构; 64位将为您提供更大的堆地址空间...但是需要更长的时间来处理每个内存位。
我假设您已经分析了您的应用程序，并知道瓶颈在哪里;关于GC的评论，你已经做到了。在这种情况下，您的应用程序不应受CPU限制，芯片架构不应成为主要问题。
答案 4 :(得分：1)
我强烈建议您查看一下您已经体验过的操作系统。如果您只了解Linux，Solaris就是一个奇怪的野兽，例如
此外，我强烈建议您使用Sun实际支持的平台，因为这将使您在真正需要它时更容易获得专业协助。
http://java.sun.com/javase/6/webnotes/install/system-configurations.html
答案 5 :(得分：0)
我认为托管代码环境和实时处理并不是很好。如果您真的关心延迟，请删除托管代码强加的层。这不是Java vs C ++参数，而是Java / C＃/ ... vs C / C ++ / FORTRAN / ...参数，我相信这是一个有效的设计讨论。
是的，我的意思是FORTRAN，我们运行了许多具有FORTRAN基础的近实时系统。
答案 6 :(得分：0)
管理延迟的一种方法是让多个JVM将工作分成较小的堆，以便在发生垃圾收集时不会耗费时间并且影响较少的进程。
另一种方法是加载具有足够内存的JVM集群并分配进程以确保在您关注延迟的时间内不会停止世界垃圾收集（如果这不是24/7） app），并在非工作时间重启JVM。
您还应该考虑其他JVM实现（例如JRocket）。当然，如果其中任何一个是合适的，完全取决于您的具体应用。
如果上述任何问题对您的方法有影响，则会影响操作系统的选择。例如，如果您使用另一个JVM实现，这可能会限制操作系统选择，如果您使用群集或以其他方式为应用程序运行多个JVM，则可能需要一些更好的底层操作系统工具来有效管理，从而进一步影响操作系统选择
答案 7 :(得分：0)
考虑到更快的网络结构的可用性，操作系统或可配置的选择完全是多余的。
使用ToE NIC查看10GigE，或使用4X QDR（40Gbs）InfiniBand的更快解决方案，但IPoIB提供标准以太网接口和路由。