Когда пора менять тариф хостинга, а когда нет

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

Честный итог такой: повышайте тариф, когда ресурс исчерпан в простое, а не на пике, когда ядро что-то убило, когда диск заполнен или когда вы сознательно добавляете нагрузку. Не повышайте, потому что сервер «кажется медленным», потому что график памяти выглядит высоким или потому что кто-то у вас в Discord так сказал. Эта статья - диагностика между этими случаями: точные строки логов, счётчики и формы графиков, которые отделяют одно от другого.

Четыре признака настоящей проблемы размера#

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

• Высокий минимум памяти, а не только пик. Минимум - это самая низкая точка, которой касается линия памяти между всплесками, измеренная за сутки, а не за час. Когда минимум лежит выше примерно 80 процентов лимита, запаса не остаётся ни на цикл сборки мусора, ни на backup, ни на то, чтобы двенадцать человек зашли одновременно. Пик, который касается потолка и сразу возвращается вниз, - это нормально.
• Ядро что-то убило. Остановка из-за нехватки памяти, ошибка выделения памяти в логе или процесс, который исчез без собственной ошибки. Это не мнение о том, достаточно ли большой тариф: это операционная система сообщает вам, что недостаточно.
• Диск заполнен или почти заполнен. Никакая настройка не создаёт место. Можно удалить лишнее, и это часто правильный ответ, но когда реальный рабочий набор превышает тариф, это проблема размера и больше ничего.
• Вы сознательно добавляете нагрузку. Больше игроков, мир побольше, сборка модов, вторая служба, запуск. Повысить тариф до прихода нагрузки - единственный случай, когда покупать ёмкость про запас разумно, потому что вы знаете: число будет расти.

Всё остальное заслуживает десяти минут диагностики в первую очередь.

Смотрите на минимум, а не на пик#

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

Что вам действительно говорит, так это форма графика во времени:

Снимайте показание в самый тихий час, какой у вас есть. Сервер, на котором никого нет, должен быть далеко от своего лимита; если это не так, пик будет болезненным. И снимайте его минимум за двадцать четыре часа, потому что перезапуск сбрасывает всё и первые два часа делает любой тариф достаточным. Формы графиков подробнее разобраны в статье как читать график нагрузки сервера.

Одна ловушка, специфичная для контейнеров: free -m, запущенный внутри контейнера, показывает память хост-машины, а не ваш лимит, так что он бодро сообщит о 60 ГБ свободной памяти, пока ваш процесс вот-вот будет остановлен. Читайте cgroup:

$ cat /sys/fs/cgroup/memory.current   # bytes in use$ cat /sys/fs/cgroup/memory.max       # your limit$ cat /sys/fs/cgroup/memory.events    # includes an oom_kill counter

В старых системах с cgroup v1 эквиваленты - memory.usage_in_bytes, memory.limit_in_bytes и memory.failcnt. В панели график памяти уже показывает использование относительно лимита - та же информация без арифметики.

Как доказать, что дело в памяти#

Если сервер умер, доказательства существуют. Найдите их до того, как что-то покупать, потому что «он упал» и «у него кончилась память» - это разные проблемы с разными способами лечения.

Код выхода 137. В контейнере это 128 плюс сигнал 9, то есть процесс был убит, а не завершился сам. Почти всегда это лимит памяти. Код выхода 143 - это 128 плюс сигнал 15, обычный SIGTERM, то есть нормальная остановка или перезапуск, а вовсе не ошибка.

Сообщение ядра. На машине, которой вы управляете, dmesg -T | grep -i -E "oom|killed process" выдаёт примерно такое:

Memory cgroup out of memory: Killed process 8123 (java)total-vm:9812344kB, anon-rss:4194304kB, file-rss:0kB

Эта строка называет процесс и объём памяти, который он занимал, когда умер. Как ядро выбирает жертву, объясняет статья swap и OOM killer.

Ошибка среды выполнения, а не убийство. Она означает, что процесс упёрся в собственный потолок раньше, чем контейнер в свой:

java.lang.OutOfMemoryError: Java heap spaceFATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memoryMemoryError

Различие важно, и это самая частая причина, по которой люди покупают тариф, который ничего не исправляет. Java-сервер с -Xmx4G выбросит ошибку кучи и на тарифе с 12 ГБ, потому что лимит задаёт флаг, а не тариф. У процесса Node есть собственный потолок old-space, заданный независимо от контейнера, и это тема статьи почему ваше приложение на Node умирает на 2 ГБ при тарифе в 4 ГБ. Проверяйте флаг раньше, чем тариф.

Обратная ловушка на JVM встречается так же часто. Куча - это не весь процесс: metaspace, кэш кода, стеки потоков и прямые буферы лежат вне -Xmx и добавляют несколько сотен мегабайт. Если задать -Xmx равным лимиту контейнера, остановка из-за нехватки памяти гарантирована рано или поздно, потому что процессу нужно больше, чем его куча. На сервере Minecraft оставляйте вне кучи 20-25 процентов тарифа.

Ещё одно, что стоит знать, прежде чем тратить на это вечер: сервер, который многократно перезапускается, замечают. Наблюдатель раз в пару минут проверяет, не откатился ли uptime назад и не ушёл ли сервер в офлайн, а перезапуски, которые запросили вы, не учитываются. Три неожиданных перезапуска за час выводят предупреждение на странице сервера и автоматически открывают тикет; шесть приводят к приостановке. Если ваш сервер в таком состоянии, решение о повышении тарифа - не самое срочное.

Как доказать, что дело в CPU: троттлинг - это не нехватка#

Сервер, который рывками работает при спокойной памяти, - это проблема CPU, и покупка памяти не изменит ничего. Различить это легко, и почти никто этого не делает.

CPU на контейнерном тарифе - это жёсткое ограничение до купленной доли. Когда вы её превышаете, ядро не замедляет вас постепенно: оно прекращает планировать ваш процесс до конца периода и возобновляет в следующем. Поэтому сервер, упёршийся в CPU, дёргается в регулярном ритме, а не деградирует плавно. Счётчик можно прочитать:

$ cat /sys/fs/cgroup/cpu.statnr_periods 184320nr_throttled 41277throttled_usec 892134000

Доказательство - рост nr_throttled относительно nr_periods. В cgroup v1 файл лежит в /sys/fs/cgroup/cpu/cpu.stat, а поле называется throttled_time и измеряется в наносекундах. В панели то же самое сигнализирует график CPU, ровно прижатый к вашей доле, - без файла.

Для игрового сервера собственное измерение игры обычно нагляднее. На Paper или Spigot команда /tps показывает тики в секунду относительно целевых 20, а MSPT - сколько на самом деле занял тик относительно бюджета в 50 мс. Сервер с 18 TPS, тиками по 55 мс и загрузкой памяти 40 процентов - случай однозначный: памяти в тарифе хватает с запасом, а тактов мало. Новые сборки Paper заменили timings на spark, так что проверьте, что есть в вашей, и профилируйте через /spark profiler, если он там есть. Дальше - статьи почему падает TPS и как читать отчёт spark.

Неприятная часть: более крупный тариф обычно даёт вам больше доли vCPU, а не более быстрое ядро. Большинство игровых серверов ограничены производительностью одного потока, поэтому переход с 1,5 до 2,5 vCPU помогает серверу, который упирался в троттлинг, и почти ничего не даёт серверу, у которого главный поток тиков просто делает слишком много работы. Выясните, какой случай ваш, до того, как платить. Тридцать секунд диагностики, которые экономят много денег, описаны в статье CPU или RAM.

Сервер, работающий на 100 процентах CPU, медленный, но не сломан, и за это его никогда не приостанавливают.

Диск - единственное, что нельзя вылечить настройкой#

Нехватка диска - самая неинтересная и самая внезапная неисправность в хостинге. Заполненный диск останавливает запись в базу данных, портит сохранение мира на середине записи и не даёт ротироваться логу - всё сразу и без предупреждения.

$ df -h /$ du -sh /* 2>/dev/null | sort -h | tail -20$ du -sh ./* | sort -h | tail -20

Что на самом деле заполняет тариф, примерно в порядке частоты:

• Логи, которые никогда не ротируются. Болтливый сервер с отладочным выводом может выдавать гигабайты в неделю. На машинах с systemd - journalctl --disk-usage, затем journalctl --vacuum-time=7d.
• Резервные копии рядом с тем, что они защищают. Встроенная папка backup в игре - это не backup, а вторая копия на том же диске, и она растёт бесконечно. Держите настоящие копии вне машины: бэкапы, которые действительно восстанавливаются - как раз про ту половину, которую все пропускают.
• Старые миры, старые карты, старые сборки модов. Мир прошлого сезона никто не удаляет.
• Артефакты сборки. node_modules от трёх деплоев назад, кэш менеджера пакетов, каталог Cargo target, образ Docker, который никто не чистит.
• Загрузки. Присланные пользователями картинки веб-приложения в полном разрешении, навсегда.

Сначала почистите. Большинство заполненных дисков на 70 процентов состоит из мусора, а удалять мусор бесплатно. Если реальный рабочий набор действительно превышает тариф, это проблема размера, и нужно переезжать. Стоит знать и то, что тариф не меняет тип хранилища: NVMe стоит на каждом тарифе, так что повышение даёт место, а не скорость. Какие именно операции это затрагивает, чётко описано в статье что на самом деле меняет NVMe.

Три симптома, которые выглядят как проблема размера, но ею не являются#

Периодические рывки в регулярном ритме. Подвисание каждые несколько минут через предсказуемый интервал - это сохранение, автосохранение или backup, то есть проблема диска и паузы, а не нехватка. Сравните интервал с настройкой сохранения мира или с вашими запланированными задачами, прежде чем делать что-либо ещё. На игровом сервере увеличение интервала делает подвисания реже, а возможную потерю больше; уменьшение делает каждое подвисание короче. Ни то ни другое память не исправляет.

Низкий tick rate при спокойной памяти. Описано выше, и стоит повторить, потому что это самая дорогая ошибка диагностики в игровом хостинге. Больший тариф по памяти ничего не даёт для цикла тиков, упёршегося в CPU. Если на графике память на 50 процентах, а сервер выдаёт 14 TPS, проблема ни в каком смысле не в памяти.

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

Четвёртое, тоже заслуживающее упоминания: сервер, который стал ощущаться медленнее после начала чужого часа пик. Это конкуренция за ресурсы, а не ваше выделение, и это совсем другой разговор: что на самом деле гарантирует доля и как отличить одно от другого, рассказано в статье общий CPU и шумные соседи.

Попробуйте это, прежде чем платить#

По порядку: от меньших усилий с большим эффектом к большим. Для игрового сервера:

1. Уменьшите дальность прорисовки и симуляции. В Minecraft view-distance и simulation-distance в server.properties по умолчанию равны 10. Снижение дальности симуляции до 6 резко сокращает работу на каждый тик и почти незаметно игрокам. Это самое ценное отдельное изменение из доступных.
2. Посчитайте плагины и моды. Двадцать плагинов - это двадцать вещей, работающих на каждом тике. Уберите те, которыми никто не пользовался с марта, а остальные профилируйте, а не гадайте. Файлы конфигурации, которые важны, разобраны в статье оптимизация Paper.
3. Проверьте количество сущностей. Фермы мобов, стаки предметов на земле и предметы в рамках - частая причина сервера, который замедлился, хотя никто ничего не менял.
4. Исправьте флаги памяти, а не тариф. Слишком низкий -Xmx вызывает ошибки кучи на любом тарифе; слишком высокий гарантирует остановку контейнера. Разумные цифры по числу игроков и сборкам модов есть в статье сколько RAM нужно серверу Minecraft.
5. Перезапускайте по расписанию. Память, которая растёт днями на долгоживущем сервере, - это часто обычное накопление, а не утечка, и еженедельный перезапуск в 5 утра держит её ровной бесплатно.

Для приложения:

1. Кэшируйте ответы, которые не зависят от пользователя. Обычно самый большой выигрыш, и бесплатный.
2. Найдите медленный запрос. Один отсутствующий индекс регулярно отвечает за большую часть CPU базы данных.
3. Ограничьте каждую коллекцию, которой владеет ваш код. Кэш без вытеснения - это утечка по расписанию.
4. Задавайте размер кучи или число воркеров сознательно, а не наследуйте значение по умолчанию, рассчитанное на ноутбук.

Если вы сделали всё это, а ресурс всё равно упирается в предел, у вас проблема размера, и теперь вы знаете, какой ресурс покупать.

Выбор следующего тарифа и то, чего он не изменит#

Выбирайте тариф по минимуму, а не по пику. Возьмите значение памяти в простое, прибавьте разрыв между пиком и минимумом, который вы наблюдали, прибавьте 25 процентов и купите тариф выше этого числа. Удвоение потому, что цифры выглядят приятнее, - вот как люди платят за 8 ГБ ради задачи, которой было нужно 3.

Чётко понимайте, что смена тарифа делает, а чего не делает:

• Меняет лимиты памяти, диска и доли CPU на сервере, который у вас уже есть. Смена тарифа не пересоздаёт сервер, поэтому мир, файлы, слот базы данных и домен остаются ровно на месте.
• Не меняет класс хранилища, потому что NVMe есть на каждом тарифе; локацию, потому что она одна; производительность одного потока у ядра, на котором работает ваш цикл тиков; сетевой путь между игроком и машиной; и ошибку в конфигурации.
• Не лечит утечку. Процесс, у которого память растёт без границ, доходит до более высокого потолка медленнее. В пятницу вечером это чего-то стоит, а в долгосрочной перспективе не стоит ничего.

Дайте любому повышению честную проверку. Наблюдайте полные сутки при той же нагрузке, смотрите на тот же минимум, который вы измеряли раньше, и будьте готовы заключить, что это не помогло, - это тоже информация, и она указывает на конфигурацию. Более длинные сроки оплаты в три, шесть и двенадцать месяцев дешевле в пересчёте на месяц, поэтому стоит определиться с правильным тарифом, прежде чем брать любой из них.

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

FAQ#

Как понять, нужно мне больше RAM или больше CPU?

Посмотрите оба графика в плохой момент. Память на потолке и процесс убивают - это память. CPU прижат к вашей доле при комфортной памяти - это CPU. Если игра сообщает о низком TPS или высоком MSPT при спокойной памяти, это CPU, и никакой тариф по памяти не поможет.

Мой график памяти всё время у верхней границы. Это плохо?

Обычно нет. Java и некоторые другие среды выполнения берут выданную им кучу и используют её, так что высокая линия пилообразной формы - это здоровое состояние. Важен минимум между всплесками и то, возвращается ли пила на тот же уровень. Минимум, который ползёт вверх за несколько дней, - вот что нужно исследовать.

Перезапустится ли мой сервер при смене тарифа?

Смена тарифа не пересоздаёт сервер: файлы, мир, слот базы данных и настройки остаются на месте. Ожидайте, что сам процесс поднимется заново уже с новыми лимитами, так что выберите спокойный момент, как для любого перезапуска.

Можно ли вернуться на тариф ниже, если повышение не помогло?

Тарифы не односторонние, но сначала проверьте диск, потому что это единственное измерение, которое не сокращается безболезненно: тариф поменьше должен быть достаточно велик для того, что вы реально храните. Очистите старые миры и устаревшие backup до перехода, а если не уверены, спросите через тикет.

Почему мой сервер сам перезапустился, а не просто замедлился?

Потому что при достижении лимита памяти контейнер останавливается и чисто перезапускается, а не остаётся в swap. Это выглядит как сбой, но им не является. Проверьте код выхода 137 и строку о нехватке памяти, и если вы их нашли, то тариф или флаг кучи действительно слишком малы.

Стоит ли повышать тариф перед крупным событием или запуском?

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