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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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