部署低延迟 Java 应用程序的最佳操作系统？
我们有一个用 Java 编写的低延迟交易系统（提要处理程序、分析、订单输入）。它广泛使用 TCP 和 UDP，不使用 Infiniband 或其他非标准网络。
任何人都可以评论部署该系统的各种操作系统或操作系统配置的权衡吗？虽然吞吐量对于跟上现代价格供给显然很重要，但延迟是我们的第一要务。
自从 Java 诞生以来，Solaris 似乎就是一个自然的候选者。我应该使用 Sparc 还是 x64 处理器？
我听说过有关 RHEL 和 SLERT 的好消息，它们是适合在我们的基准测试中使用的 Linux 版本吗？
有人针对上述操作系统测试过 Windows 吗？或者假设它跟不上？
我想把 Java 与 C++ 的争论留给另一个话题。
We have a low latency trading system (feed handlers, analytics, order entry) written in Java. It uses TCP and UDP extensively, it does not use Infiniband or other non-standard networking.
Can anyone comment on the tradeoffs of various OSes or OS configurations to deploy this system? While throughput is obviously important to keep up with modern price feeds, latency is our #1 priority.
Solaris seems like a natural candidate since they created Java; should I use Sparc or x64 processors?
I've heard good things about RHEL and SLERT, are those the right versions of Linux to use in our benchmarking.
Has anyone tested Windows against the above OSes? Or is it assumed to not keep up?
I'd like to leave the Java vs C++ debate for a different thread.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
供应商喜欢这种基准。你有代码，对吗？
IBM、Sun/Oracle、HP 都喜欢在他们的设备上运行您的应用程序以展示他们的优势。
让他们这样做。如果您有代码，请让供应商在他们的设备上运行演示，以展示哪种设备最适合您的需求。
它简单、无痛、免费并且真实。最终的决定将是简单而明显的。您将了解如何安装和调整以最大限度地提高性能。
我讨厌做的是在编写代码之前预测这种事情。在我们完成识别所有用例之前，太多客户要求提供硬件和操作系统建议。要求这种预知简直就是疯狂。
但你有代码。您可以生成测试用例来测试您的代码。那很完美。
Vendors love this kind of benchmark. You have code, right?
IBM, Sun/Oracle, HP will all love to run your app on their gear to demonstrate their advantages.
Make them do this. If you have code, make the vendors run a demonstration on their gear to show which is best for your needs.
It's easy, painless, free, and factual. The final decision will be easy and obvious. And you will know how to install and tune to maximize performance.
What I hate doing is predicting this kind of thing before the code is written. Too many customers have asked for a H/W and OS recommendation before we've finished identifying all the use cases. Asking for that kind of precognition is simple craziness.
But you have code. You can produce test cases that exercise your code. That's perfect.
对于交易环境，除了低延迟之外，您可能还担心一致性和延迟，因此专注于尽可能减少 GC 暂停的影响可能会比选择不同的操作系统为您带来更多好处。
但是，如果你计划在每一微秒都很重要的环境中使用你的交易系统，你真的会拥有要忍受当前一代虚拟机缺乏一致性的情况——它们（除了实时）都不能保证低微秒的 GC 暂停。当然，在这个级别，您将遇到操作系统活动中的相同问题（进程抢占、中断处理、页面错误等）。在这种情况下，Linux 的实时变体之一将为您提供帮助。
For a trading environment, in addition to low latency you are probably concerned about consistency as well as latency so focusing on reducing the impact of GC pauses as much as possible may well give you more benefit than differnt OS choices.
However, if your planning on using your trading system in an environment where every microsecond counts, you're really going to have to live with the lack of consistency you will get from the current generation of VM's - none of them (except realtime) guarantees low microsecond GC pauses. Of course, at this level your going to run into the same issues from OS activity (process pre-emption, interrupt handling, page faults, etc.). In this case one of the real time variants of Linux is going to help you.
我不会仅仅因为它是 Windows 就将 Windows 排除在外。我过去几年的经验是，与相同硬件上的 Linux 或 Soaris x86 相比，Windows 版本的 Sun JVM 通常在性能方面是最成熟的。用于 Solaris SPARC 的 JVM 可能也不错，但我想使用 x86 上的 Windows，您会以更少的钱获得更多的功能。
I wouldn't rule out Windows from this just because it's Windows. My expirience over the last few years has been that the Windows versions of the Sun JVM was usually the most mature performance wise in contrast to Linux or Soaris x86 on the same hardware. The JVM for Solaris SPARC may be good too, but I guess with Windows on x86 you'll get more power for less money.
我强烈建议您研究一下您已经使用过的操作系统。如果您只了解 Linux，Solaris 就是一个奇怪的野兽，例如
，我还强烈建议您使用 Sun 支持的平台，因为这将使您在真正需要时更容易获得专业帮助它。
http://java.sun.com/javase/6/ webnotes/install/system-configurations.html
I would strongly recommend that you look into an operating system you already have experience with. Solaris is a strange beast if you only know Linux, e.g.
Also I would strongly recommend to use a platform actually supported by Sun, as this will make it much easier to get professional assistance when you REALLY, REALLY need it.
http://java.sun.com/javase/6/webnotes/install/system-configurations.html
我可能会担心垃圾收集会在操作系统之前导致延迟；你有没有考虑过调整它？
如果我愿意花时间尝试不同的操作系统，我会尝试 Solaris 10 和 NetBSD，并且可能还会尝试 Linux 变体。
我会尝试 32 位架构与 64 位架构； 64 位将为您提供更大的堆地址空间...但需要更长的时间来寻址每一位内存。
我假设您已经分析了您的应用程序并知道瓶颈在哪里；通过关于 GC 的评论，你已经做到了。在这种情况下，您的应用程序不应受 CPU 限制，并且芯片架构不应成为主要问题。
I'd probably worry about garbage collection causing latency well before the operating system; have you looked into tuning that at all?
If I were willing to spend the time to trial different OSs, I'd try Solaris 10 and NetBSD, and probably a Linux variant for good measure.
I'd experiment with 32-vs-64 bit architectures; 64 bit will give you a larger heap address space... but will take longer to address each bit of memory.
I'm assuming you've profiled your application and know where the bottlenecks are; by the comment about GC, you've done that. In that case, your application shouldn't be CPU-bound, and chip architecture shouldn't be a primary concern.
我认为托管代码环境和实时处理不能很好地结合在一起。如果您确实关心延迟，请删除托管代码强加的层。这不是 Java 与 C++ 的争论，而是 Java/C#/... 与 C/C++/FORTRAN/... 的争论，我相信这是一个有效的设计讨论。
是的，我指的是 FORTRAN，我们运行许多以 FORTRAN 为基础的近实时系统。
I don't think managed code environments and real-time processing go together very well. If you really care about latency, remove the layer imposed by the managed code. This is not a Java vs C++ argument, but a Java/C#/... vs C/C++/FORTRAN/... argument, and I believe that is a valid design discussion to have.
And yes, I do mean FORTRAN, we run a number of near real-time systems with a FORTRAN foundation.
管理延迟的一种方法是让多个 JVM 将工作划分为较小的堆，以便停止世界垃圾收集发生时不会那么耗时，并且影响的进程也较少。
另一种方法是为 JVM 集群加载足够的内存并分配进程，以确保在您关心延迟的时间内不会停止世界垃圾收集（如果这不是 24/7 应用程序），并在下班时间重新启动 JVM。
您还应该考虑其他 JVM 实现（例如 JRocket）。当然，其中任何一个是否合适完全取决于您的具体应用。
如果上述任何一项对您的方法很重要，它将影响操作系统的选择。例如，如果您使用另一个 JVM 实现，这可能会限制操作系统的选择，如果您使用集群或以其他方式为应用程序运行多个 JVM，则可能需要一些更好的底层操作系统工具来有效管理，从而进一步影响操作系统的选择。
One way to manage latency is to have several JVM's dividing the work with smaller heaps so that a stop the world garbage collection isn't as time consuming when it happens and affects less processes.
Another approach is to load up a cluster of JVM's with enough memory and allocate the processes to ensure there won't be a stop the world garbage collection during the hours you care about latency (if this isn't a 24/7 app), and restart JVMs on off hours.
You should also look at other JVM implementations as a possibility (such as JRocket). Of course if any of them are appropriate depends entirely on your specific application.
If any of the above matters to your approach, it will affect the choice of OS. For example, if you go with another JVM implementation, that might limit OS choices, and if you go with clustering or otherwise running a several JVM's for the application, that might require some better underlying OS tools to manage effectively, further influencing the OS choice.
考虑到更快的网络结构的可用性，操作系统或可配置的选择是完全多余的。
看看带有 ToE NIC 的 10GigE，或者更快的 4X QDR (40Gbs) InfiniBand 解决方案，但带有 IPoIB 呈现标准以太网接口和路由。
The choice of operating system or configurable is completely redundant considering the availability of faster network fabrics.
Look at 10GigE with ToE NICs, or the faster solution of 4X QDR (40Gbs) InfiniBand but with IPoIB presenting a standard Ethernet interface and routing.