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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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