- Сообщения
- 2 563
- Решения
- 115
Апнули значится фреймдевовцы тему. Увидел я там ссылочку на их собсна сайт, решил посмотреть что там еще имеется, и собственно не зря.
Наткнулся я там на статью по "оптимизации", после которой у меня сгорела жoпа (хрен вам а не цензура) на столько, что теперь вы читаете вот это.
Будем разбирать сие творение по пунктам как оно и есть в статье.
1) Зачем нужно оптимизировать сервер?
Пропустим данный пунк т.к. кроме вступления там ничего нет.
2) Как проверить оптимизацию сервера?
Ну и вот уже с этого момента начинается веселье.
"Для начала напишите /tps, если показатели у вас в районе 19.9 - 20, значит все хорошо, если ниже — ваш сервер плохо оптимизирован."
Буквально первое же предложение и уже это не корректная информация. Да, 20 тпс может говорить о том, что сервер работает относительно исправно, однако когда речь идет про TPS - нельзя забывать и про такую штуку как MSPT.
TPS - тики в секунду - т.е. сколько игровых тиков за секунду проходит.
MSPT - милисекунда за тик т.е. - сколько милисекунд в среднем занимает один тик.
И тут и кроется основная проблема.
В майнкрафте тик занимает 50 милисекунд. 50 мс * 20 = 1 секунда, следовательно мы получаем 20 тиков в секунду, отсюда и получается 20 тпс.
Однако, (если очень ОЧЕНЬ сильно упрощать) то тики работают следующим образом:
На сервере происходит действие -> это действие занимает условные 5 милисекунд -> остальное время тика (45 секунд) он ничего не делает -> по прошествии 50 милисекунд сервер переходит к следующему тику. И так далее по цепочке.
Главная же проблема заключается в том, что тик сам по себе может быть больше, чем 50 милискунд, в связи с действиями, которые в этот момент выполняются в основном потоке сервера.
В случае, когда один тик занимает больше времени, чем он должен - следующий стартует с опозданием, однако тик луп всё равно выровнится, придя к значению 20, за счет тиков, действие которых заняло меньше 50 милисекунд.
Таким образом мы можем получить то, что хотя ТПС у вас будет 20, мы всё равно можем иметь при себе лаг-всплески (как их принято называть), которые могут оказать огромное влияние на работу сервера (представьте что каждые 5 секунд 1 тик среди 20 будет занимать 100 милисекунд, вместо положенных 50. поверьте, во время геймплея вы это заметите.)
Едем дальше.
Хотя далее идет лишь разбор работы со спарком.
Тут можно сказать лишь одно - замер без only-ticks-over, а также без игроков не может являться объективным.
Если вы хотите узнать как спарком пользоваться, то прочитайте официальные доки:
3) Как повысить оптимизацию сервера?
Просто заголовок для последующих разделов статьи.
3.1) Как прогрузить чанки?
Тут ничего необычного, кроме того, что про Chunky нет ни слова.
3.2) Используйте флаги в запускаторе
Всё стандартно, обычный совет использовать флаги айкара, проблемы нет.
Но вот с этого момента пойдет поток сознания человека, который, мало того, что как ранее выяснилось не вникал в работу со спарком, но и не вникал в тему оптимизации в принципе. (Собственно а зачем вникать, когда хомячки которые качают слив сборки риливрота всё равно схавают, я прав?)
3.3) Установите плагины для оптимизации
Я был бы очень рад закончить разбор данного абзаца статьи одной фразой, а именно - "плагины на защиту от лагов дают лишь больше лагов" но я не админ фреймдева, так что...
"Оптимизация на разных версиях отличается, но на все версии рекомендуем вам ставить плагин Spark (
Дорогой и многонеуважаемый автор данной цитаты, укажите нам пожалуйста, в каком месте спарк вызывает сборщик мусора и в каком месте он даёт прирост производительности сервера?
Разрушу надежды желающих увидеть ответ - его не будет, в связи с тем, что spark ничего из описанного касательно оптимизации не делает.
И даже напротив, бекграунд профайлер способен создать дополнительную нагрузку на ваш процессор своим регулярным замером. Спарк является лишь профилировщиком и ни чем иным.
"Также рекомендуем установить на версию 1.12.2 — ClearLagg (
Возможно для множества людей, которые не смыслят в серверах ничего и никогда не читали ни конфиги ядра ни конфиги данных плагинов данные плагины могут показаться хоть сколь либо полезными, но есть одно небольшое НО
небольшое такое
все "оптимизирующие" функции данных плагинов уже как лет 6 были добавлены в Paper, если не в спигот.
И не нужно большого ума, чтобы данный факт проверить.
Вот все оптимизирующие функции которые есть в ClearLagg:
Option to reduce TNT lag or chain reactions - spigot.yml / max-tnt-per-tick
Option to limit mob spawners - paper.yml / mob-spawner-tick-rate: 5
Locate overcrowded/abused chunks - paper.yml / delay-chunk-unloads-by и max-auto-save-chunks-per-tick
Limit AI processing attributes to save CPU - spigot.yml / nerf-spawner-mobs
Ну и неупомянутый на спиготе очищатель лута с пола - spigot.yml / item-despawn-rate и arrow-despawn-rate
Вероятно не сложно догадаться, что если поверх ядра человек устанавливает плагин который делает буквально то же самое - плагин будет лишь бесполезным придатком, способным лишь на то, чтобы выполнять бесполезные действия создавая бесполезную нагрузку.
3.4) Самое очевидное, но самое важное.
Тут идет перечисление ядер, однако это стоит видеть
"PaperSpigot - 1.8 - 1.18. Больше подойдет под сервера, на которых больше 20 плагинов.
****** - Ядро на версию 1.12.2, которое намного лучше в плане оптимизации PaperSpigot, а также в нем есть много фиксов, например, Log4Shell, которых нет в Paper, и.т.д. Но название указано не будет, это ядро не очень популярное и используется в наших платных сборках (
Pufferfish / Purpur - Идеальное ядро, но для ванильных, или приватных серверов на 1.17+
SSSpigot [Платное ядро] - Очень оптимизированный форк Paper со множеством фиксов (
P.S Если ищите слив в интернете, хоть немного проверяйте код ядра"
Это может показаться придирками, но будем честны - о них я не сказать не мог.
1) PaperSpigot назывался так только на 1.8. Paper уже как 6 лет как Paper. Также Paper поддерживает новейшие версии без каких либо проблем, однако я предположу, что на момент написания статьи 1.18 была последней выпущенной версией.
2) На кой черт было замазано наззвание ядра Dionysus. А так же на кой черт была оставлена ссылка не на ядро, а на студию.
Если же это не он, на что косвенно указывает кол-во звездочек - то что это вообще должно было быть?
3) Почему Pufferfish и PurPur указаны как идеальные для ванилы, в случае, когда они являются в принципе самыми производительными ядрами. (даже на момент написания статьи они 100% таковыми являлись)
4) SSSPigot - настолько ущербен, что просто не может быть использован ни одним человеком, который хочет обеспечить стальность своему серверу (мало того, что он не совместим с некоторыми плагиами (пример - LPX, это не выдумка) так еще и он фактически является полу-заброшенным, т.к. автор никак не поддерживает более старые версии своего ядра)
Но данные огрехи еще можно простить, особенно в свете того, что нас ждет в следующем пункте.
3.5) Bukkit.yml, Spigot.yml, Paper.yml
Итак дамы и господа, мы переходим к апофеозу маразма и очередному доказательству того, что человек, писавший данную статью никогда в своей жизни не вникал ни во что из того, что он пытается донести до своей аудитории с умным видом профессионала.
Bukkit.yml
"1. Установите spawn-limits на monsters: 10, animals: 5, water-animals: 2, ambient: 0. Так вы сократите спавн мобов."
Весьма по лайтовому, но уже тут виден подход к оптимизации из разряда "чем меньше тем лучше и не важно что будет".
"2. Установите chunk-gc: period-in-ticks на 600. Так вы быстрее выгрузите свободные чанки."
Кто нибудь скажите ему, что это стандартное значение из бакит юмл...
Spigot.yml
"Уменьшите entity-activation-range. Поставьте значения как на скриншоте. Мобы за пределами этого диапазона будут отмечаться реже.
Установите nerf-spawner-mobs на true. Это сэкономит вам TPS, мобы перестанут лишний раз двигаться."
Данные пункты конечно вполне могут быть полезными для оптимизации, но вот для обычных игроков показанные значения активации могут быть излишними, а отключенный ИИ у мобов из спавнеров может навредить фермам.
И это был весь спигот юмл. Почему не был указан хотя бы (показанный даже на скрине!) tick-inactive-villagers: true -> false? Не понятно.
Paper.yml
"Установите значение (max-auto-save-chunks-per-tick) на 6. Сохранение мира будет происходить с замедлением сохранения чанков."
А вот этот совет целиком и полностью вам навредит.
Объяснение можете прочесть тут https://spigotmc.ru/threads/sovremennaja-optimizacija-sovremennyx-serverov.4172/post-54608
Но если в двух словах - чем больше чанков прогружено - тем больше нужно сохранять до момента, когда произойдет общее глобальное сохранение. если не сохранять достаточно - в момент глобального сохранения все несохраненные до этого чанки будут сохранены одновременно.
Оптимальное значение - начиная от 8.
"Установите значение (max-entity-collisions) на 2. Сжатые объекты будут меньше сталкиваться. Это экономия TPS."
Тут не облажались.
"Установите значение (prevent-moving-into-unloaded-chunks) на true. Это предотвратит попадание игроков в неактивный чанк."
Тут тоже нет ошибки.
И опять - это был весь разбор paper.yml. Буквально 3 пункта, когда есть и уже упомянутый delay-chunk-unloads-by, container-update-tick-rate, grass-spread-tick-rate, use-faster-eigencraft-redstone и прочие? Либо автор не знал, либо забыл, либо не знал и забыл.
4) Не надейтесь только на количество ОЗУ
Просто приведу цитату
"Как правило, чтобы сервер выдерживал большие нагрузки, на него нужно выделить как можно больше оперативной памяти.
1 ГБ = 15 игроков. То есть сервер, на котором 8ГБ ОЗУ, выдержит примерно 120 игроков. Но даже если вы выделите 64ГБ, но поставите левую сборку с какого-то форума, оптимизированной она все равно не будет. Не надейтесь на одну лишь оперативную память. Давайте беречь наших игроков."
Откуда взята информация про 1 гигабайт на 15 игроков? С каких замеров вышли такие результаты? Лично мне не ясно.
Фактически же кол-во оперативной памяти, которое вам необходимо выделять на сервер зависит строго от вашей сборки. Кол-во плагинов, версия сервера, само ядро и уже потом плюс онлайн - вот то, что является основным параметром по которому вы должны определять кол-во памяти.
Однако дальше идет фраза про 64 гигабайта.
Человек не только за оптимизацию ядер не знает, но не знает и про работу сборщика мусора.
Нет я конечно могу предположить, что это сказано для условного красного словца, но черт возьми это тут неуместно.
И опять минутка занимательных объяснений для людей, которые в данную тему не вникали:
Давайте представим что сервер это бассейн, а выделяемая на него память - это вода, а плагины и т.п. процессы - купающиеся в бассейне люди.
Как вы понимаете - бассейн этот надо иногда чистить от грязи, которая остаётся от людей. И тут приходит Garbage Collector (сборщик мусора) и очищает весь этот бассейн. И чем больше будет бассейн - тем дольше времени будет данный сборщик мусора его убирать. А чем дольше он будет его убирать - тем больше на это потребуется ресурсов, а чем больше ресурсов - тем больше общая нагрузка, в следствии чего мы получаем лаги.
По сему - не нужно выделять на сервер больше памяти, чем ему нужно, но и не меньше, чем ему нужно.
5) CMI или Essentials?
Бесполезный раздел про то, как "оптимизировать" CMI. Хотя про то, что можно включить сохранение файлов в многопотоке не сказано...
6) Устраните багоюзеров
"Есть такие плагины как:
ExploitFixer - Плагин, фиксящий множество эксплоитов на вашем сервере.
AntiRedstoneClock - Плагин, запрещающий создавать лаг-машины.
FiguresFix - Плагин, запрещающий брать читерские вещи, багоюзить, и.т.д.
Все эти плагины желательно иметь на сервере, чтобы избежать багоюзеров."
И вот мне очень интересно, сам автор использовал данные плагины не своём сервере? Может быть он хотя бы заглядывал в их конфигурацию? Ну давайте узнаем.
ExploitFixer - плагин призванный исправлять ПАКЕТНЫЕ эксплоиты и краши. Вероятно, возможно, может быть, автор и имел их в виду, однако выглядит так, будто бы EF призван исправлять эксплоиты завязанные на игровых механиках и т.п.
AntiRedstoneClock - плагин запрещающий создавать зацикленные редстоун механизмы. Тут в точку, если не учитывать лаг машины без участия редстоуна (песок и паутина)
FiguresFix - плагин, призванный защитить от .figure2 и .figure3 из древнего чита джессика (краши которого были исправлены еще в 1.8 paper) а также краш-книг, которые создавались при помощи креатива (может быть исправлено при помощи настроек paper.yml). О каком запрете багоюза и особенно т.п. идет речь - неизвестно.
Ну в 1.5 из 3 - будем честны лучше чем 0... Если бы это не писала студия, претендующая на хотя бы какую-то серьезность.
7) Не используйте слитые плагины с форумов, пабликов ВК и ТГ каналов
Сказано по факту.
8) Забудьте о плагинах, которые заброшены автором.
"На spigotmc.org очень много плагинов, которые уже несколько лет не обновляются и автор на них забил. Плагин остановился, а Minecraft - нет. Поэтому необновленные плагины могут некорректно работать с обновленным Minecraft'ом."
Могу ли я сказать о том, что vault заброшен, раз он не был обновлен на спиготе с 2019 (или 18) года?
Вероятно могу.
Перестал ли ваулт от этого работать? Ответ нет.
Так что в данном случае всё весьма не так однобоко. Некоторые плагины, которые были написаны даже 10 лет назад могут вполне исправно работать на новейших версиях майнкрафта.
9) Не перегружайте сервер плагинами
"Много плагинов = Большая нагрузка. Меньше плагинов = Выше оптимизация. В идеале количество плагинов не должно превышать 45, если у вас больше, то удалите ненужное и уменьшите нагрузку на сервер."
Это абсолютная ложь, еще раз подтверждающая уровень познаний автора статьи. От кол-ва плагинов не зависит буквально ничего. Вы можете иметь сборку с 10 плагинами, которая будет лагать при 5 человеках, а можете иметь сборку из 100 которая и от 200 не шелохнется.
Всё зависит от того, какие плагины вы используете и какова от этих самых планинов нагрузка.
Нет, я не пытаюсь сказать "не бойтесь ставить 100500 плагинов т.к. это не проблема", я говорю о том, что некорректно говорить о том, что чем меньше плагинов - тем быстрее ваш сервер будет работать.
Я могу предположить, что автор пытался донести ту же мысль что и я вот тут -
10) Итог
Ну коль итог автора ничего в себе не несет, выскажу-ка я свой итог от разбора данной статьи.
Исходя из всего того, что я тут перечислил мы можем сделать неутешительный вывод о том, что рассматриваемая статья была сделана человеком, который не имеет достаточных познаний в сфере оптимизации сервера в частности и его работы в целом.
Озвученные в статье предложения, призванные по заявлению оптимизировать ваш сервер - на половину являются информацией некорректной, неполной или вовсе вредящей, а на половину - стандартными фактами, которые узнает любой человек, который хотя бы немного будет заинтересован в повышении производительности или стабильности своего сервера.
Для людей, которые действительно хотят почитать про настоящую оптимизацию - рекомендую к прочтению данную статью https://spigotmc.ru/resources/sovremennaja-optimizacija-sovremennyx-serverov.613/, которая является самым комплексным сборником советов по оптимизации вашего сервера.
Наткнулся я там на статью по "оптимизации", после которой у меня сгорела жoпа (хрен вам а не цензура) на столько, что теперь вы читаете вот это.
Будем разбирать сие творение по пунктам как оно и есть в статье.
1) Зачем нужно оптимизировать сервер?
Пропустим данный пунк т.к. кроме вступления там ничего нет.
2) Как проверить оптимизацию сервера?
Ну и вот уже с этого момента начинается веселье.
"Для начала напишите /tps, если показатели у вас в районе 19.9 - 20, значит все хорошо, если ниже — ваш сервер плохо оптимизирован."
Буквально первое же предложение и уже это не корректная информация. Да, 20 тпс может говорить о том, что сервер работает относительно исправно, однако когда речь идет про TPS - нельзя забывать и про такую штуку как MSPT.
TPS - тики в секунду - т.е. сколько игровых тиков за секунду проходит.
MSPT - милисекунда за тик т.е. - сколько милисекунд в среднем занимает один тик.
И тут и кроется основная проблема.
В майнкрафте тик занимает 50 милисекунд. 50 мс * 20 = 1 секунда, следовательно мы получаем 20 тиков в секунду, отсюда и получается 20 тпс.
Однако, (если очень ОЧЕНЬ сильно упрощать) то тики работают следующим образом:
На сервере происходит действие -> это действие занимает условные 5 милисекунд -> остальное время тика (45 секунд) он ничего не делает -> по прошествии 50 милисекунд сервер переходит к следующему тику. И так далее по цепочке.
Главная же проблема заключается в том, что тик сам по себе может быть больше, чем 50 милискунд, в связи с действиями, которые в этот момент выполняются в основном потоке сервера.
В случае, когда один тик занимает больше времени, чем он должен - следующий стартует с опозданием, однако тик луп всё равно выровнится, придя к значению 20, за счет тиков, действие которых заняло меньше 50 милисекунд.
Таким образом мы можем получить то, что хотя ТПС у вас будет 20, мы всё равно можем иметь при себе лаг-всплески (как их принято называть), которые могут оказать огромное влияние на работу сервера (представьте что каждые 5 секунд 1 тик среди 20 будет занимать 100 милисекунд, вместо положенных 50. поверьте, во время геймплея вы это заметите.)
Едем дальше.
Хотя далее идет лишь разбор работы со спарком.
Тут можно сказать лишь одно - замер без only-ticks-over, а также без игроков не может являться объективным.
Если вы хотите узнать как спарком пользоваться, то прочитайте официальные доки:
Авторизуйтесь для просмотра ссылок.
ну или русскую локализацию от меня: https://spigotmc.ru/resources/rukovodstvo-po-ispolzovaniju-spark.1182/3) Как повысить оптимизацию сервера?
Просто заголовок для последующих разделов статьи.
3.1) Как прогрузить чанки?
Тут ничего необычного, кроме того, что про Chunky нет ни слова.
3.2) Используйте флаги в запускаторе
Всё стандартно, обычный совет использовать флаги айкара, проблемы нет.
Но вот с этого момента пойдет поток сознания человека, который, мало того, что как ранее выяснилось не вникал в работу со спарком, но и не вникал в тему оптимизации в принципе. (Собственно а зачем вникать, когда хомячки которые качают слив сборки риливрота всё равно схавают, я прав?)
3.3) Установите плагины для оптимизации
Я был бы очень рад закончить разбор данного абзаца статьи одной фразой, а именно - "плагины на защиту от лагов дают лишь больше лагов" но я не админ фреймдева, так что...
"Оптимизация на разных версиях отличается, но на все версии рекомендуем вам ставить плагин Spark (
Авторизуйтесь для просмотра ссылок.
). Он не только помогает отследить нагрузку на сервер, но и также дает буст к оптимизации вашего сервера. Используя Garbage Collector, плагин постоянно снижает потребление оперативной памяти, когда оно поднимается высоко."Дорогой и многонеуважаемый автор данной цитаты, укажите нам пожалуйста, в каком месте спарк вызывает сборщик мусора и в каком месте он даёт прирост производительности сервера?
Разрушу надежды желающих увидеть ответ - его не будет, в связи с тем, что spark ничего из описанного касательно оптимизации не делает.
И даже напротив, бекграунд профайлер способен создать дополнительную нагрузку на ваш процессор своим регулярным замером. Спарк является лишь профилировщиком и ни чем иным.
"Также рекомендуем установить на версию 1.12.2 — ClearLagg (
Авторизуйтесь для просмотра ссылок.
), а на версии от 1.14.4 — LaggAssist (
Авторизуйтесь для просмотра ссылок.
)"Возможно для множества людей, которые не смыслят в серверах ничего и никогда не читали ни конфиги ядра ни конфиги данных плагинов данные плагины могут показаться хоть сколь либо полезными, но есть одно небольшое НО
небольшое такое
все "оптимизирующие" функции данных плагинов уже как лет 6 были добавлены в Paper, если не в спигот.
И не нужно большого ума, чтобы данный факт проверить.
Вот все оптимизирующие функции которые есть в ClearLagg:
Option to reduce TNT lag or chain reactions - spigot.yml / max-tnt-per-tick
Option to limit mob spawners - paper.yml / mob-spawner-tick-rate: 5
Locate overcrowded/abused chunks - paper.yml / delay-chunk-unloads-by и max-auto-save-chunks-per-tick
Limit AI processing attributes to save CPU - spigot.yml / nerf-spawner-mobs
Ну и неупомянутый на спиготе очищатель лута с пола - spigot.yml / item-despawn-rate и arrow-despawn-rate
Вероятно не сложно догадаться, что если поверх ядра человек устанавливает плагин который делает буквально то же самое - плагин будет лишь бесполезным придатком, способным лишь на то, чтобы выполнять бесполезные действия создавая бесполезную нагрузку.
3.4) Самое очевидное, но самое важное.
Тут идет перечисление ядер, однако это стоит видеть
"PaperSpigot - 1.8 - 1.18. Больше подойдет под сервера, на которых больше 20 плагинов.
****** - Ядро на версию 1.12.2, которое намного лучше в плане оптимизации PaperSpigot, а также в нем есть много фиксов, например, Log4Shell, которых нет в Paper, и.т.д. Но название указано не будет, это ядро не очень популярное и используется в наших платных сборках (
Авторизуйтесь для просмотра ссылок.
)Pufferfish / Purpur - Идеальное ядро, но для ванильных, или приватных серверов на 1.17+
SSSpigot [Платное ядро] - Очень оптимизированный форк Paper со множеством фиксов (
Авторизуйтесь для просмотра ссылок.
)P.S Если ищите слив в интернете, хоть немного проверяйте код ядра"
Это может показаться придирками, но будем честны - о них я не сказать не мог.
1) PaperSpigot назывался так только на 1.8. Paper уже как 6 лет как Paper. Также Paper поддерживает новейшие версии без каких либо проблем, однако я предположу, что на момент написания статьи 1.18 была последней выпущенной версией.
2) На кой черт было замазано наззвание ядра Dionysus. А так же на кой черт была оставлена ссылка не на ядро, а на студию.
Если же это не он, на что косвенно указывает кол-во звездочек - то что это вообще должно было быть?
3) Почему Pufferfish и PurPur указаны как идеальные для ванилы, в случае, когда они являются в принципе самыми производительными ядрами. (даже на момент написания статьи они 100% таковыми являлись)
4) SSSPigot - настолько ущербен, что просто не может быть использован ни одним человеком, который хочет обеспечить стальность своему серверу (мало того, что он не совместим с некоторыми плагиами (пример - LPX, это не выдумка) так еще и он фактически является полу-заброшенным, т.к. автор никак не поддерживает более старые версии своего ядра)
Но данные огрехи еще можно простить, особенно в свете того, что нас ждет в следующем пункте.
3.5) Bukkit.yml, Spigot.yml, Paper.yml
Итак дамы и господа, мы переходим к апофеозу маразма и очередному доказательству того, что человек, писавший данную статью никогда в своей жизни не вникал ни во что из того, что он пытается донести до своей аудитории с умным видом профессионала.
Bukkit.yml
"1. Установите spawn-limits на monsters: 10, animals: 5, water-animals: 2, ambient: 0. Так вы сократите спавн мобов."
Весьма по лайтовому, но уже тут виден подход к оптимизации из разряда "чем меньше тем лучше и не важно что будет".
"2. Установите chunk-gc: period-in-ticks на 600. Так вы быстрее выгрузите свободные чанки."
Кто нибудь скажите ему, что это стандартное значение из бакит юмл...
Spigot.yml
"Уменьшите entity-activation-range. Поставьте значения как на скриншоте. Мобы за пределами этого диапазона будут отмечаться реже.
Установите nerf-spawner-mobs на true. Это сэкономит вам TPS, мобы перестанут лишний раз двигаться."
Данные пункты конечно вполне могут быть полезными для оптимизации, но вот для обычных игроков показанные значения активации могут быть излишними, а отключенный ИИ у мобов из спавнеров может навредить фермам.
И это был весь спигот юмл. Почему не был указан хотя бы (показанный даже на скрине!) tick-inactive-villagers: true -> false? Не понятно.
Paper.yml
"Установите значение (max-auto-save-chunks-per-tick) на 6. Сохранение мира будет происходить с замедлением сохранения чанков."
А вот этот совет целиком и полностью вам навредит.
Объяснение можете прочесть тут https://spigotmc.ru/threads/sovremennaja-optimizacija-sovremennyx-serverov.4172/post-54608
Но если в двух словах - чем больше чанков прогружено - тем больше нужно сохранять до момента, когда произойдет общее глобальное сохранение. если не сохранять достаточно - в момент глобального сохранения все несохраненные до этого чанки будут сохранены одновременно.
Оптимальное значение - начиная от 8.
"Установите значение (max-entity-collisions) на 2. Сжатые объекты будут меньше сталкиваться. Это экономия TPS."
Тут не облажались.
"Установите значение (prevent-moving-into-unloaded-chunks) на true. Это предотвратит попадание игроков в неактивный чанк."
Тут тоже нет ошибки.
И опять - это был весь разбор paper.yml. Буквально 3 пункта, когда есть и уже упомянутый delay-chunk-unloads-by, container-update-tick-rate, grass-spread-tick-rate, use-faster-eigencraft-redstone и прочие? Либо автор не знал, либо забыл, либо не знал и забыл.
4) Не надейтесь только на количество ОЗУ
Просто приведу цитату
"Как правило, чтобы сервер выдерживал большие нагрузки, на него нужно выделить как можно больше оперативной памяти.
1 ГБ = 15 игроков. То есть сервер, на котором 8ГБ ОЗУ, выдержит примерно 120 игроков. Но даже если вы выделите 64ГБ, но поставите левую сборку с какого-то форума, оптимизированной она все равно не будет. Не надейтесь на одну лишь оперативную память. Давайте беречь наших игроков."
Откуда взята информация про 1 гигабайт на 15 игроков? С каких замеров вышли такие результаты? Лично мне не ясно.
Фактически же кол-во оперативной памяти, которое вам необходимо выделять на сервер зависит строго от вашей сборки. Кол-во плагинов, версия сервера, само ядро и уже потом плюс онлайн - вот то, что является основным параметром по которому вы должны определять кол-во памяти.
Однако дальше идет фраза про 64 гигабайта.
Человек не только за оптимизацию ядер не знает, но не знает и про работу сборщика мусора.
Нет я конечно могу предположить, что это сказано для условного красного словца, но черт возьми это тут неуместно.
И опять минутка занимательных объяснений для людей, которые в данную тему не вникали:
Давайте представим что сервер это бассейн, а выделяемая на него память - это вода, а плагины и т.п. процессы - купающиеся в бассейне люди.
Как вы понимаете - бассейн этот надо иногда чистить от грязи, которая остаётся от людей. И тут приходит Garbage Collector (сборщик мусора) и очищает весь этот бассейн. И чем больше будет бассейн - тем дольше времени будет данный сборщик мусора его убирать. А чем дольше он будет его убирать - тем больше на это потребуется ресурсов, а чем больше ресурсов - тем больше общая нагрузка, в следствии чего мы получаем лаги.
По сему - не нужно выделять на сервер больше памяти, чем ему нужно, но и не меньше, чем ему нужно.
5) CMI или Essentials?
Бесполезный раздел про то, как "оптимизировать" CMI. Хотя про то, что можно включить сохранение файлов в многопотоке не сказано...
6) Устраните багоюзеров
"Есть такие плагины как:
ExploitFixer - Плагин, фиксящий множество эксплоитов на вашем сервере.
AntiRedstoneClock - Плагин, запрещающий создавать лаг-машины.
FiguresFix - Плагин, запрещающий брать читерские вещи, багоюзить, и.т.д.
Все эти плагины желательно иметь на сервере, чтобы избежать багоюзеров."
И вот мне очень интересно, сам автор использовал данные плагины не своём сервере? Может быть он хотя бы заглядывал в их конфигурацию? Ну давайте узнаем.
ExploitFixer - плагин призванный исправлять ПАКЕТНЫЕ эксплоиты и краши. Вероятно, возможно, может быть, автор и имел их в виду, однако выглядит так, будто бы EF призван исправлять эксплоиты завязанные на игровых механиках и т.п.
AntiRedstoneClock - плагин запрещающий создавать зацикленные редстоун механизмы. Тут в точку, если не учитывать лаг машины без участия редстоуна (песок и паутина)
FiguresFix - плагин, призванный защитить от .figure2 и .figure3 из древнего чита джессика (краши которого были исправлены еще в 1.8 paper) а также краш-книг, которые создавались при помощи креатива (может быть исправлено при помощи настроек paper.yml). О каком запрете багоюза и особенно т.п. идет речь - неизвестно.
Ну в 1.5 из 3 - будем честны лучше чем 0... Если бы это не писала студия, претендующая на хотя бы какую-то серьезность.
7) Не используйте слитые плагины с форумов, пабликов ВК и ТГ каналов
Сказано по факту.
8) Забудьте о плагинах, которые заброшены автором.
"На spigotmc.org очень много плагинов, которые уже несколько лет не обновляются и автор на них забил. Плагин остановился, а Minecraft - нет. Поэтому необновленные плагины могут некорректно работать с обновленным Minecraft'ом."
Могу ли я сказать о том, что vault заброшен, раз он не был обновлен на спиготе с 2019 (или 18) года?
Вероятно могу.
Перестал ли ваулт от этого работать? Ответ нет.
Так что в данном случае всё весьма не так однобоко. Некоторые плагины, которые были написаны даже 10 лет назад могут вполне исправно работать на новейших версиях майнкрафта.
9) Не перегружайте сервер плагинами
"Много плагинов = Большая нагрузка. Меньше плагинов = Выше оптимизация. В идеале количество плагинов не должно превышать 45, если у вас больше, то удалите ненужное и уменьшите нагрузку на сервер."
Это абсолютная ложь, еще раз подтверждающая уровень познаний автора статьи. От кол-ва плагинов не зависит буквально ничего. Вы можете иметь сборку с 10 плагинами, которая будет лагать при 5 человеках, а можете иметь сборку из 100 которая и от 200 не шелохнется.
Всё зависит от того, какие плагины вы используете и какова от этих самых планинов нагрузка.
Нет, я не пытаюсь сказать "не бойтесь ставить 100500 плагинов т.к. это не проблема", я говорю о том, что некорректно говорить о том, что чем меньше плагинов - тем быстрее ваш сервер будет работать.
Я могу предположить, что автор пытался донести ту же мысль что и я вот тут -
Авторизуйтесь для просмотра ссылок.
, однако у него не вышло.10) Итог
Ну коль итог автора ничего в себе не несет, выскажу-ка я свой итог от разбора данной статьи.
Исходя из всего того, что я тут перечислил мы можем сделать неутешительный вывод о том, что рассматриваемая статья была сделана человеком, который не имеет достаточных познаний в сфере оптимизации сервера в частности и его работы в целом.
Озвученные в статье предложения, призванные по заявлению оптимизировать ваш сервер - на половину являются информацией некорректной, неполной или вовсе вредящей, а на половину - стандартными фактами, которые узнает любой человек, который хотя бы немного будет заинтересован в повышении производительности или стабильности своего сервера.
Для людей, которые действительно хотят почитать про настоящую оптимизацию - рекомендую к прочтению данную статью https://spigotmc.ru/resources/sovremennaja-optimizacija-sovremennyx-serverov.613/, которая является самым комплексным сборником советов по оптимизации вашего сервера.
Последнее редактирование:
