Хорошие люди собрались и сделали полезную страницу со ссылками на все известные дистрибутивы Java. Теперь любой разработчик легко может пройти по ссылкам и скачать любую JVM, чтобы пощупать, померять, сравнить.
Данная статья является частью более общей статьи об оптимизациях торговой системы на всех уровнях.
JVM предназначена для запуска широкого спектра Java-приложений. Для общего случая параметры, используемые JVM по умолчанию, вполне подойдут. Но если мы хотим добиться определенных результатов производительности, требуется тонкая настройка JVM с помощью определенных стартовых параметров.
Не существует «волшебных» параметров, которые делают в момент ваше приложение быстрее, секретных параметров, которые подходят для всех приложений и ситуаций. Каждый выбранный параметр и измененное значение в нем следует проверять на специальной тестовой платформе. По нескольку раз. По нескольку часов. А потом долго думать, почему результаты тестов показывают снижение или улучшение производительности.
Каждая новая версия Java приносит новые параметры и удаляет другие. Каждая новая версия или билд Java может влиять на производительность в лучшую или худшую сторону. Так что при каждом обновлении версии все замеры производительности надо производить заново.
Следует отметить, что и изменения на уровне железа и операционной системы также могут сказываться на производительности JVM. Какой-то параметр JVM, который улучшал производительность приложения до изменения в ОС, может привести к ухудшению производительности после патча ядра ОС или после изменения какой-то настройки в ней. Так что при каждом обновлении ОС или изменении настройки ОС все замеры производительности надо опять производить заново.
Все приведенное ниже не гарантирует, что в конкретно в вашей ситуации ваше приложение будет работать быстрее. Не следует надеяться, что криво написанное приложение заработает автоматически быстрее при включении тех или иных «волшебных» параметров JVM или настроек ОС. Для достижения low-latency само приложение должно писаться с учетом low-latency.
Параметры приведены для Java 8 HotSpot JVM.
Все настройки JVM можно разбить условно на четыре группы:
Как видно из предыдущих статей JIT-компилятор на 4-ом уровне способен создавать высокопроизводительный нативный код. В некоторых случаях, благодаря сбору статистки в реальном рабочем окружении, нативный код получается даже лучше, чем код созданный статическим компилятором из исходников C/C++. Именно поэтому Java-программисты заявляют, что Java-приложение по скорости может превзойти приложение, написанное на C/C++.
Как же нам достичь этого уровня компиляции, если для его достижения требуется 15.000 исполнений?
JIT-компилятор — встроенный в JVM компилятор байткода в машинный код. Проведя множество интервью с кандидатами на роль Core Java Developer, я был удивлен тем, что многие кандидаты даже не подозревали о существовании такой технологии в JVM, а те, кто краем уха что-то слышал, не могли объяснить, как она работает. Может быть для написания J2EE или веб-приложений этих знаний и не требуется, но для работы в области low-latency trading эти знания — ключевые.
Описание JIT-компилятора хорошо дано в книгах:
В данной статье я просто изложу основы, без знания которых непонятны будут другие статьи по low-latency оптимизации JVM.
В предыдущей статье я говорил об оптимизации вообще, а теперь приведу несколько советов по low-latency оптимизациях в Java-приложениях на всех уровнях торговой системы:
Несколько мыслей об оптимизации вообще, оптимизации Java-приложений и оптимизации для достижения low-latency.
Интересная статья на habr.com о том, как писать на Java low-latency приложения так, чтобы в heap не создавался мусор и значит не вызывался сборщик мусора, который может привести к непредсказуемым задержкам в самый непододящий момент торгового дня. Почитайте также и комментарии.
Чтобы посмотреть, какие опции поддерживает ваша версия Java, запускаем:
java -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal
и получаем на экране полный список:
Жил был программист Richard Rose.
После работы на ведущие банки мира (Goldman Sachs, Morgan Stanley, Bank of America, UBS и прочее), он решил, что настало время уйти на вольные хлеба и реализовать свои идеи и наработки в коммерческом продукте. План состоял в том, чтобы создать движок, совмещавший OMS и соединение с рынком, который бы способен был перемещать сообщения с задержкой в микросекунды и даже меньше. Движок был написан на Java.
