Лучшая ОС для развертывания Java-приложения с низкой задержкой?

Question

У нас есть торговая система с низкой задержкой (обработчики каналов, аналитика, ввод заказов), написанная на Java.Он широко использует TCP и UDP, не использует Infiniband или другие нестандартные сети.

Может кто-нибудь прокомментировать компромиссы различных ОС или конфигурации ОС для развертывания этой системы?Хотя пропускная способность, очевидно, важна для того, чтобы идти в ногу с современными ценовыми потоками, задержка является нашим приоритетом № 1.

Solaris кажется естественным кандидатом, поскольку они создали Java;я должен использовать процессоры Sparc или x64?

Я слышал хорошие отзывы о RHEL и SLERT, это те версии Linux, которые следует использовать в нашем тестировании.

Кто-нибудь проверял Windows на вышеуказанных ОС?Или предполагается не отставать?

Я бы хотел оставить дискуссию о Java и C ++ для другой темы.

Answer 1

Продавцы любят этот тип эталона. У вас есть код, верно?

IBM, Sun / Oracle, HP будут любить запускать ваше приложение на своих устройствах, чтобы продемонстрировать свои преимущества.

Заставь их сделать это. Если у вас есть код, сделайте так, чтобы продавцы провели демонстрацию своего оборудования, чтобы показать, что лучше всего соответствует вашим потребностям.

Это просто, безболезненно, бесплатно и фактично. Окончательное решение будет легким и очевидным. И вы будете знать, как установить и настроить, чтобы максимизировать производительность.

---

Я ненавижу делать предсказания такого рода вещи до того, как будет написан код. Слишком много клиентов спрашивали рекомендации H / W и OS, прежде чем мы закончили определять все варианты использования. Запрашивать такое предвидение - просто сумасшествие.

Но у вас есть код. Вы можете создавать контрольные примеры, которые используют ваш код. Это прекрасно.

Answer 2

В торговой среде, помимо низкой задержки, вы, вероятно, беспокоитесь как о согласованности, так и о задержке, поэтому сосредоточение на максимально возможном уменьшении воздействия пауз в GC может дать вам больше преимуществ, чем различные варианты ОС.

• Сборщик мусора G1 в последних версиях Suns Hotspot VM улучшает остановку мира, делает много пауз, подобно JRockit VM
• Тем не менее, для реальных гарантий производительности версия компилятора Hotspot Azul Systems на их Java Appliance обеспечивает наименьшие доступные гарантированные паузы, а также масштабируется до 100 ГБ стека и 100 ядер.
• Я бы отказался от Java Realtime - хотя вы получите гарантии ответа, вы пожертвуете пропускной способностью, чтобы получить эти гарантии

Однако, если вы планируете использовать свою торговую систему в среде, где каждая микросекунда имеет значение, вам действительно придется мириться с отсутствием последовательности, которую вы получите от текущего поколения виртуальных машин - ни одна из них (кроме в реальном времени) гарантирует низкие микросекундные паузы ГХ. Конечно, на этом уровне вы столкнетесь с теми же проблемами, что и действия ОС (перегрузка процессов, обработка прерываний, сбои страниц и т. Д.). В этом случае вам поможет один из вариантов Linux в реальном времени.

Answer 3

Я бы не исключал Windows из этого только потому, что это Windows. Мой опыт за последние несколько лет заключался в том, что версии Sun JVM для Windows, как правило, были наиболее зрелыми по производительности в отличие от Linux или Soaris x86 на том же оборудовании. JVM для Solaris SPARC тоже может быть хорошей, но я думаю, что с Windows на x86 вы получите больше энергии за меньшие деньги.

Answer 4

Я настоятельно рекомендую вам взглянуть на операционную систему, с которой у вас уже есть опыт работы. Solaris - странный зверь, если вы знаете только Linux, например,

Кроме того, я настоятельно рекомендую использовать платформу, фактически поддерживаемую Sun , поддерживаемую Sun , поскольку это значительно облегчит получение профессиональной помощи, когда она ДЕЙСТВИТЕЛЬНО, ДЕЙСТВИТЕЛЬНО нужна.

http://java.sun.com/javase/6/webnotes/install/system-configurations.html

Answer 5

Я бы, вероятно, беспокоился о том, что сборка мусора приводит к задержке задолго до появления операционной системы; Вы смотрели на тюнинг это вообще?

Если бы я хотел потратить время на тестирование разных ОС, я бы попробовал Solaris 10 и NetBSD и, возможно, вариант Linux для хорошей меры.

Я бы экспериментировал с 32-х-64-битными архитектурами; 64-битная даст вам больше адресного пространства кучи ... но займет больше времени для адресации каждого бита памяти.

Я предполагаю, что вы профилировали свое приложение и знаете, где находятся узкие места; благодаря комментарию о GC, вы сделали это. В этом случае ваше приложение не должно быть привязано к процессору, а архитектура микросхемы не должна быть главной задачей.

Answer 6

Выбор операционной системы или настраиваемой полностью избыточен, учитывая наличие более быстрых сетевых структур.

Посмотрите на 10GigE с сетевыми картами ToE или на более быстрое решение InfiniBand с 4X QDR (40 Гбит / с), но с IPoIB , представляющим стандартный интерфейс Ethernet и маршрутизацию.

Answer 7

Один из способов управления задержкой состоит в том, чтобы несколько JVM разделяли работу на меньшие кучи, чтобы остановка сбора мусора в мире не занимала столько времени, когда это происходит, и затрагивает меньше процессов.

Другой подход заключается в загрузке кластера JVM с достаточным объемом памяти и распределении процессов, чтобы гарантировать, что не произойдет остановка сбора мусора в мире в те часы, когда вы заботитесь о задержке (если это не круглосуточно). app) и перезапустите JVM в нерабочее время.

Вы должны также рассмотреть возможность других реализаций JVM (например, JRocket). Конечно, если какой-либо из них подходит, полностью зависит от вашего конкретного применения.

Если что-то из вышеперечисленного имеет значение для вашего подхода, это повлияет на выбор ОС. Например, если вы работаете с другой реализацией JVM, это может ограничить выбор ОС, и если вы собираетесь кластеризовать или иным образом запустить несколько JVM для приложения, для этого могут потребоваться более эффективные инструменты ОС для эффективного управления, что еще больше повлияет на выбор ОС. .

Answer 8

Я не думаю, что среды с управляемым кодом и обработка в реальном времени идут очень хорошо Если вы действительно заботитесь о задержке, удалите слой, наложенный управляемым кодом. Это не аргумент Java против C ++, а аргумент Java / C # / ... vs C / C ++ / FORTRAN / ..., и я считаю, что это правильное обсуждение проекта.

И да, я имею в виду FORTRAN, мы запускаем несколько систем, близких к реальному времени, на основе FORTRAN.