2009-12-23 3 views
14

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

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

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

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

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

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

+2

О да, мы могли бы все сделать с другим Java vs C++ flamewar – Patrick

+0

«Solaris кажется естественным кандидатом, так как они создали Java» Серьезно? Это как ненаучный иск, как вы можете сделать. –

+1

Я могу дать вам один совет: 32-разрядная ОС ограничит размер кучи вашего JVM. 32-разрядные операционные системы nix имеют более высокий предел, чем win32; окно резервирует определенные области памяти, что мешает JVM получать непрерывный блок памяти (точный предел меняется, но он находится в приблизительном размере 1,1-1,5 ГБ). Если я правильно помню, ограничение для * nix составляет 2 ГБ. 64-разрядные операционные системы не имеют этого ограничения, но ваше оборудование должно его поддерживать. – RMorrisey

ответ

17

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

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

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

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


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

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

+1

Сколько вам нужно, чтобы тратить на аппаратное обеспечение, чтобы получить такую ​​демонстрацию? В настоящее время у нас около 40 серверов, и я думаю, что мы, вероятно, были слишком маленькими, чтобы делать лабораторную работу поставщика. –

+2

@Ted Грэм. Нуль. Если они хотят продать вам оборудование, они должны продемонстрировать, что он работает. Они любят это делать. Начинайте спрашивать своих продавцов для демонстрации. –

+2

Этот ответ замечательный! Компании-производители оборудования ЛЮБИЛИ попытаться продемонстрировать свое оборудование в лучшем виде. Просто сделайте себе одну услугу: укажите точно, что вы измеряете, прежде чем вы дадите им тестовый код. В частности, вы, вероятно, хотите устойчивую пропускную способность (количество транзакций в течение более длительного периода, например, более одного часа), а не самую быструю единую транзакцию. –

1

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

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

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

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

+0

Мы уже немного настроили GC. –

+0

Разве Windows не разрезает? Или, в чем проблема, которую вы нажимаете? –

+0

Это для торговой системы, вы ВСЕГДА хотите быть быстрее. –

1

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

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

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

+0

Большая часть нашего опыта в Windows; хотя мы были бы готовы нанять администратора Solaris или Linux, если это необходимо. –

0

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

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

+2

Fortran smortran. Вы можете скомпилировать Java на кремнии http://cscott.net/Publications/design.ps и вырезать среднего человека. –

+1

JVM имеют некоторые преимущества в производительности (например, самопрофилирование во время выполнения), которые будут потеряны при компиляции Java в exe или создании его на чипе. –

+0

Компиляция для силикона исключает исходную предпосылку OP того, на какой ОС работать. Если он скомпилирован, вопрос ОС не заботится об исходном языке. – cdkMoose

0

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

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

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

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

5

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

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

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

+0

Я меньше интересуюсь случаями GC, чем с тем, что вы классифицировали как «Активность ОС» Я считаю, что устройства Azul не обеспечивают субмиллисекундную задержку. –

+0

ОК. Никакие виртуальные машины на рынке не обеспечивают задержку субсчета - сборщик G1 позволяет указать максимальную максимальную паузу в мс, но примеры всегда идут вниз по диапазону ms. Когда вы доберетесь до того, что активность os вызывает у вас проблемы, вы получите действительно большой скачок в производительности от RDMA с бесконечным диапазоном. В порядке 10usec, а не около 70usec для 10GigE для передачи. –

+0

Я согласен, что никакая ВМ не предоставляет гарантии на миллисекунды времени для GC, но я считаю, что Azul не обеспечивает латентность sub-ms для обработки событий, когда GC не участвует. Я получил это от http://blogs.azulsystems.com/cliff/webtech/page/2/ (см. Запись от 28 октября 2008 года) –

2

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

+0

Наш бенчмаркинг показал, что Windows пока очень конкурентоспособна. Мы собираемся начать дальнейшее тестирование, поэтому я задал свой вопрос. –

0

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

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