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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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