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