![](https://habrastorage.org/getpro/habr/post_images/201/5f5/289/2015f5289c7b97565da4163f42cdb6ca.png)
Продолжая серию статей что-то против чего-то, мы наконец рассмотрим что-то полезное, а именно сервер Minecraft. Рассмотрим какая операционная система и какая ява все же лучше для того, чтобы хостить лучшую игру человечества. Для сравнения взяты Ubuntu 18.04 LTS и Server Core 2019. На Ubuntu был установлен OpenJDK, а на Windows — Oracle Java и AdoptOpenJDK.
Как и на всех остальных сравнительных тестах, у виртуальных машин не было соседей, на хосте всегда была запущена только одна ВМ.
Серверы запускались с аргументами:
-Xmx8G -server
На Windows Server Core был удален компонент Windows Defender, как в нашем образе с Windows VDS за 99 рублей. Для сравнения, вот что вы теряете, когда оставляете его включенным.
![](https://habrastorage.org/getpro/habr/post_images/c8c/0e0/dae/c8c0e0daed7a87d3b8b61701657830d2.png)
Для каждого из дистрибутивов Java были установлены последние публично доступные версии, а именно:
Oracle: «1.8.0_241»
AdoptOpenJDK: «1.8.0_242»
OpenJDK: «1.8.0_232»
Раунд №1, генерация мира
В этом тесте генерируем мир. В качестве генератора выступал Geographicraft с установленным Biomes’O’Plenty, Dynamic Trees, PVG, worley caves, IC и BC.
Мир отнюдь не классический и генерируется заметно медленнее обычного.
Мир размером в 2704 чанков был отгенерирован:
![](https://habrastorage.org/getpro/habr/post_images/819/5a5/df8/8195a5df875106600abe1d6e7473041c.png)
Windows c AdoptOpenJDK отрывается от своих конкурентов на 5 секунд.
Раунд №2, старт сервера
Замер проходил в три прохода для каждой виртуальной машины. Каждый раз каждый из серверов завершал загрузку мира секунда в секунду по сравнению с прошлым результатом.
![](https://habrastorage.org/getpro/habr/post_images/74f/2df/22f/74f2df22ffbed6476b690b1965935b33.png)
OpenJDK на Windows что и OpenJDK на Linux показывают одинаковые результаты.
Раунд №3, занимаемая память
Процесс начинает потреблять тем больше памяти, чем больше установлено на нем ядер. Ниже приведена таблица занимаемой памяти процесса пустого сервера без загруженного на нем мира.
![](https://habrastorage.org/getpro/habr/post_images/2e3/bbc/879/2e3bbc879f56dca57f398043e73016c7.png)
Oracle JRE потребляла в среднем на 80-100 мегабайт больше на четном количестве ядер. Тоже самое касалось и AdoptOpenJDK, только на нечетном количестве ядер.
Linux не показывал такой странности.
Раунд №4, 32 курицы в коробке 2 на 2
![](https://habrastorage.org/getpro/habr/post_images/585/f50/d71/585f50d714dacf0941d8775269980edb.png)
Сцена представляет из себя расчет коллизии 32 куриц в коробке 2 на 2. Сцена была подготовлена заранее и один и тот же мир был раскидан по серверам, чтобы все было честно.
Для этого теста было установлено одно ядро, а процессу выставлялся приоритет реального времени.
![](https://habrastorage.org/getpro/habr/post_images/539/ba6/336/539ba6336fea3a3d74cb797710444fd9.png)
Рабочий набор OpenJDK в этой сцене был на 40 мегабайт больше чем у соперников.
![](https://habrastorage.org/getpro/habr/post_images/5fd/404/749/5fd40474995d4f2e03ec31772b6185e6.png)
Среднее потребление процесора у Oracle и AdoptOpenJDK одинаковое, но мусор Oracle при всех равных собирает чаще и интенсивнее, что чаще приводит ко всплескам процессорной активности.
Чтобы экстраполировать какое количество подобных сцен мы сможем обработать, давайте просто увеличим тикрейт сервера.
![](https://habrastorage.org/getpro/habr/post_images/577/4e1/43a/5774e143addca3617705e0ac3e87b875.png)
В тесте с повышенной нагрузкой Ubuntu c OpenJDK сравнялся с Windows c AdoptOpenJDk, а Oracle догоняет.
![](https://habrastorage.org/getpro/habr/post_images/e4f/eec/aac/e4feecaac9abe940c6e1fde6950d5a74.png)
Под более высокой нагрузкой OpenJDK на Windows дал лучшие результаты, чем на Ubuntu.
Сервер OpenJDK на Ubuntu постоянно статерил и сцена замирала. Чуть хуже был Windows на этом же OpenJDK. Oracle же справился лучше всех, с наименьшим количеством подвисаний.
![](https://habrastorage.org/getpro/habr/post_images/c54/0c2/07a/c540c207a6b149def6a1cdf6f480b649.png)
Среди прочих, Oracle SE уложился в тот же объем ОЗУ что и OpenJDK.
Раунд №5, 64*64 чанка и Dynamic trees
![](https://habrastorage.org/getpro/habr/post_images/cd3/30c/372/cd330c372cf714780246e41cf364cebb.png)
Эта сцена содержит в себе лес и несколько десятков мобов. Километры деревьев постоянно растут и обновляют положения своих блоков.
Каждое дерево это отдельный тайл, но изначально имеют пониженный тикрейт, тикая лишь 1 раз в 20 игровых тиков. Ниже приведен график утилизации процессора на тикрейт сервера.
![](https://habrastorage.org/getpro/habr/post_images/8fd/9b5/702/8fd9b57021e0ce111fc5de6c81f0ef96.png)
Ubuntu + OpenJDK и Windows Server с Oracle на борту не смогли запустить сервер в ранее обговоренными аргументами, поэтому в график не попали.
Чтобы все же запусить сервер, пришлось изменить флаги на:
-Xms4g -Xmx8G -server -XX:+UseCompressedOops -XX:+AggressiveOpts
Все три экземпляра по началу упирались в 100% процессора, но только Windows Server + AdoptOpenJDK не уронил сервер. После сбора мусора все нормализовалось до графика ниже.
![](https://habrastorage.org/getpro/habr/post_images/029/e53/719/029e53719194f1edd567591f747088ed.png)
При переходе от тикрейта в 60 до 70, на Ubuntu график загрузки процессора стал вести себя как синусоида, из-за чего среднее значение утилизации ЦП внезапно начало падать от роста сложности задачи. Из-за этого график пришлось остановить там, где он есть сейчас.
Вероятно, дело в отличиях планировщика Linux’a и Windows.
Выводы:
Несмотря на объективную разницу в ОС и дистрибутивах JRE невозможно дать конкретную рекомендацию, которая объективно лучше для того, чтобы держать на нем сервер.
В данном случае, наверное, стоит выбирать ту операционную систему, с которой вы лучше знакомы.
![](https://habrastorage.org/webt/ww/d4/ro/wwd4ro5_5a28hvdxyazf3enjxou.png)