Как читать график нагрузки сервера: память, CPU и диск

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

Что на самом деле измеряет панель#

Прежде чем что-то читать, узнайте, что именно и как часто измеряется, потому что и то и другое меняет выводы, которые вы вправе делать.

Память читается из учёта самого ядра для контейнера, а не из игры. Это вся группа процессов: куча JVM плюс всё за её пределами, либо процесс Node плюс все буферы, плюс всё остальное, что работает в контейнере. Это не то, что указано в -Xmx, и не то, что игра сообщает в /mem или в сводке spark. Сервер Minecraft с кучей 5 ГБ в контейнере на 6 ГБ покажет в панели около 5,5 ГБ, а в игре 5 ГБ, и ни одно из чисел не ошибочно.

Есть тонкость, которую полезно знать: в cgroup v2 сырой счётчик памяти включает page cache, вызванный контейнером, то есть данные файлов, которые ядро держит, потому что их могут прочитать снова. Большинство панелей показывают значение с вычетом неактивного файлового кэша, то же, что показывает docker stats, но не все. Если ваша линия памяти подскакивает во время backup или копирования крупного файла, а потом сама возвращается вниз, ничего не сломав, вы смотрели на кэш, а не на приложение.

CPU - это процент от одного ядра, а потолок задаёт тариф. 100 - одно ядро, 250 - два с половиной. График на 210% не сломан; он означает, что выполняется работа двух ядер. На RE:NODE этот потолок - жёсткое ограничение до купленной доли, поэтому линия, прижатая к нему, - это ограничение, делающее своё дело, а сервер на 100% работает медленно, но не в беде: за это его никогда не приостанавливают.

Интервал выборки - предел того, что может рассказать любой график. Точка на диаграмме - это среднее или выборка за несколько секунд. Всплеск длиной 400 миллисекунд вообще не появится. Это очень важно, потому что то, на что жалуются игроки, - подлаг, откат, замирание - происходит в масштабе миллисекунд, а графики ресурсов - инструмент в лучшем случае секундного масштаба. Если жалоба звучит как «на мгновение залагало», график - неверный инструмент, а верный - внутриигровые метрики тиков. О них рассказано в статье что на самом деле означает tick rate.

Линия памяти#

Память - линия, по которой действуют чаще всего и понимают хуже всего. Пять форм покрывают почти всё.

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

Ровная у потолка с первой минуты. Почти всегда заранее занятая куча. JVM, запущенная с -Xms, равным -Xmx, и -XX:+AlwaysPreTouch, резервирует и трогает всю кучу сразу, намеренно, поэтому график прижат ещё до входа первого игрока. Выглядит тревожно и при этом верно. Проверьте время тика: прижатая память при хорошем времени тика - это просто набор флагов.

Регулярная пила, возвращающаяся к одному и тому же дну. Обычная работа сборщика мусора. Дно - ваши живые данные, зубцы - мусор между сборками. Чинить нечего. Глубокие частые зубцы с заметными паузами означают, что куча немного мала для рабочего набора, а это стоит CPU.

Пила с растущим дном. Каждая сборка освобождает меньше, чем предыдущая. Это утечка, и это самая практичная для действий форма на любом графике. Она закончится сбоем в момент, который вы не выбираете. Для приложения на Node соответствующее измерение описано в статье лимиты памяти Node.js; для Minecraft это обычно плагин, и назовёт его профилировщик spark.

Вертикальный рост до лимита и затем обрыв к нулю. Убийство по нехватке памяти. Контейнер дошёл до лимита, ядро его остановило, и линия начинается снизу, когда сервер поднимается заново. На RE:NODE это намеренное поведение - контейнер останавливается и запускается чистым, а не получает разрешение уходить в swap и тянуть за собой машину, - и оно означает, что консоль обрывается внезапно, без отчёта о сбое. Если эта форма повторяется, у вас цикл перезапусков, а не сбой; полный разбор - в статье почему ваш игровой сервер постоянно перезапускается.

Линия CPU#

CPU - линия, которую игнорируют, и зря.

Всплески до потолка на несколько секунд. Сохранение мира, всплеск генерации чанков, начало backup, плановая задача плагина. Почти всегда нормально. Всплеск, совпадающий с замиранием, которое заметили игроки, стоит засечь: если он повторяется каждые пять минут, это интервал автосохранения, и его можно сдвинуть или сократить.

Постоянно на потолке часами. Симуляция не успевает, и никакая память этого не изменит. Это троттлинг: контейнер раз за разом останавливается на квоте, посреди тика. С доступом к оболочке это можно доказать:

$ cat /sys/fs/cgroup/cpu.statnr_periods 940213nr_throttled 71204throttled_usec 902133945

nr_throttled, делённое на nr_periods, - доля окон планирования, в которых вы упирались в лимит. Если оно выше нескольких процентов, а серверу плохо, у вас определённый ответ, а не теория.

Прижато ровно к 100% на тарифе, допускающем 200 или 250. Самое неверно читаемое состояние на любой панели. Один поток загружен полностью, а остальная часть выделения простаивает, и это нормальное состояние занятого игрового сервера, потому что почти любой движок выполняет симуляцию в одном потоке. Больше ядер тут ничего не даст; поможет более быстрое ядро. Различие подробно разобрано в статье CPU или RAM: что на самом деле тормозит ваш сервер.

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

Регулярный пульс с фиксированным интервалом. Что-то по расписанию. Сверьте период с интервалом автосохранения, расписанием backup и расписанием хостера. Если он на целом часе, то и у всех остальных тоже; сдвинуть собственные расписания с :00 бесплатно и порой заметно. Синтаксис описан в статье cron-выражения простыми словами.

Линия диска#

Дисками называют две разные вещи, и обычно на графике только одна.

Использование диска - гигабайты, занятые из выделенного тарифом. Оно движется медленно и важно только наверху, но там очень важно: сервер, который не может писать, не может сохраняться, а сохранение, прерванное полным диском, - способ, которым миры не просто теряются, а портятся. Считайте 85% уровнем, с которого надо разбираться, а не 99%.

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

• Файлы журналов, которые никто не ротирует. Годы logs/*.log.gz - самая частая причина, и её проще всего исправить.
• Отчёты о сбоях и дампы кучи, которые пишутся именно тогда, когда никто не смотрит.
• Резервные копии мира на месте - те, что игра пишет рядом с миром сама; это не backup в полезном смысле, потому что они делят диск с тем, что защищают.
• Скачанный контент мастерской или модов, накапливающийся между версиями.
• Для приложений: деревья зависимостей, дублируемые на каждый deploy, и кэши сборки.

$ du -sh /home/container/* | sort -h | tail -20$ find /home/container -type f -size +100M -exec ls -lh {} \;

На RE:NODE собственные backup панели хранятся вне машины, которую защищают, поэтому они не расходуют выделенный серверу диск, а вот всё, что игра пишет в свою папку, расходует. Разница между ними описана в статье резервные копии, которые действительно восстанавливаются.

Пропускная способность диска - чтения и записи в секунду - редко рисуется на панели и проявляется симптомом: краткое полное замирание по расписанию при ничем не примечательных CPU и памяти. О нём сообщают как о лаге и покупают CPU. Что скорость накопителя исправляет, а что нет, описано в статье что на самом деле меняет NVMe.

Каталог форм#

Чтение трёх графиков вместе#

Одна линия сама по себе - догадка. Приём всегда один и тот же:

1. Узнайте время. Спросите, когда было плохо, с точностью до десяти минут. Без этого вы смотрите на весь день, и подозрительно всё.
2. Найдите, какая линия сдвинулась первой. Не та, что выглядит хуже всех, а та, что изменилась раньше остальных. Память, которая растёт и потом тянет за собой CPU, - проблема памяти. CPU, который насыщается и потом позволяет нарасти очереди, - проблема CPU.
3. Прочитайте консоль на то же время. График говорит, что что-то изменилось; журнал обычно говорит что. На RE:NODE консоль и графики на одной странице, а значит, на одних часах. Что искать, описано в статье как читать консоль.
4. Спросите, что изменилось в тот день. Мод, плагин, правка конфига, рекорд по числу игроков, обновление игры. В таком порядке, потому что это порядок вероятности.

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

Как установить собственную норму#

Правильного числа нет, есть только норма для вашего сервера. Сервер Minecraft на 4 ГБ с 3,6 ГБ занятых - либо совершенно здоров, либо в двух часах от сбоя, и по одному графику не отличить. Отличает сравнение с тем же сервером в хороший вечер.

Поэтому снимайте базовую линию намеренно, пока всё в порядке:

• В хороший вечер, на пике, запишите вместе память, CPU и число игроков. Снимок экрана с датой лучше воспоминания о том, как это выглядело.
• Запишите те же три числа в 04:00, когда никто не играет. Это ваш холостой минимум, а расстояние между холостым ходом и пиком - число, которое действительно описывает ваш запас.
• Занесите их в текстовый файл с датой. История в панели конечна, а сравнение, которое вам понадобится через три месяца, - с неделей, которая уже пролистнулась.
• Повторяйте после любого заслуживающего названия изменения: новый плагин, обновление версии, смена тарифа, импорт мира.

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

Разбор всего метода на примере. Сервер Paper на 6 ГБ и 2 vCPU, двадцать постоянных игроков, жалобы на вечерние лаги.

memory  5.9 GB of 6.0 GB, flat from the first minute, no cliffscpu     40% overnight, 185% of an allowed 200% from 19:00 to 23:00disk    41 GB of 50 GB, up from 33 GB nine days ago

Читаем по порядку: линия памяти прижата, но обрывов нет и прижата она с самого начала, значит, это -Xms5G -Xmx5G с pre-touch, и проблема не в ней, как бы ни была похожа. Линия CPU насыщается точно в часы, когда люди жалуются, и это ответ на заданный вопрос. А линия диска, о которой никто не спрашивал, растёт примерно на 900 МБ в день и упрётся в лимит примерно через девять дней, и тогда сервер перестанет мочь сохраняться. Жалоба на лаги - проблема CPU; а вот что готовило отказ - 14 ГБ неротируемых журналов.

Когда проблема не на графике#

Четыре случая, когда линии честны и бесполезны:

• Плохо только одному игроку. Проблема маршрута между ним и машиной. Графики её не покажут, traceroute покажет.
• Подлаг короче секунды. Ниже интервала выборки, а значит, по построению невидим. Используйте внутриигровые тайминги тиков: они измеряют с нужным разрешением. Для Minecraft это /mspt и профилировщик; длинная версия - в статье почему падает TPS и что с этим делать.
• Сервер ждёт чего-то внешнего. База данных, веб-API, проверка лицензии. CPU низкий, память ровная, всё медленно.
• Проблема в клиенте. Особенно с модифицированными клиентами, где опыт определяет частота кадров у самого игрока, а сервер ни при чём.

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

FAQ#

Память на 95%. Нужно ли переходить на другой тариф?

Не по одному этому числу. Если она стоит на 95% с самого запуска, это заранее занятая куча, и всё в порядке. Если она за несколько часов растёт до 95%, а потом сервер сам перезапускается, это убийство по нехватке памяти, и либо куча настроена неверно, либо вам действительно нужно больше. Прежде чем тратить деньги, сверьте настройку кучи с лимитом контейнера.

Почему CPU показывает 200%, когда у меня всего 2 vCPU?

Потому что значение - процент от одного ядра, а не от всего вашего выделения. Два vCPU - это 200%, так что график на 200% означает полностью использованное выделение, а не вдвойне перегруженное. Та же конвенция у top в Linux.

Плох ли скачущий график CPU?

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

График выглядел нормально, пока сервер лагал. Что случилось?

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

Как долго смотреть на график, прежде чем что-то решать?

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

Исправляет ли перезапуск растущее дно памяти?

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