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

Question

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

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

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

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

Кто-нибудь тестировал Windows на вышеуказанных операционных системах?Или предполагается, что за этим не угнаться?

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

Answer 1

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

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

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

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

---

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

Answer 8

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

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