한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Анатомия игровых лагов › L11 Диск

Ленивая загрузка на сервере Lazy loading on the server

ID причины dk-lazy-load · Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Серверная инфраструктура

Открыть карточку в основной версии с иллюстрациями и экспериментами →

Если сервер читает данные данжа или карты с диска в момент первого запроса, на этот тик останавливаются все.

Почему Кто-то впервые входит в данж или локацию → Следствие Сервер читает данные с диска в игровом потоке → На экране У всех на этом сервере короткий фриз

Симптомы
Фриз
Факторы
Остановка
У кого
Одна локация или канал, Весь сервер
Когда
В движении и при смене локации
Ответственные
Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Серверная инфраструктура
Команда разработки: задачи
Загружать данные заранее при старте сервера, загружать асинхронно.
Команда инфраструктуры: задачи
Сервер, только что созданный из снапшота, перед вводом в работу прогревать (один раз прочитать все блоки диска) или использовать быстрое восстановление из снапшота.
На графике
Случайные всплески · время тика сервера, чтение с диска
Где смотреть
Сопоставить моменты остановок с записями о первом входе в данж или локацию в логе игрового сервера и смотреть в эти моменты чтение с диска игровым сервером (kB_rd/s в pidstat -d) и долгие вызовы read и open через perf trace --duration. Если облачный сервер только что поднят, сравнить VolumeAvgReadLatency в EBS со старыми серверами
Подтверждает
Остановка только в момент первого входа, при повторном входе туда же остановки нет. Во время остановки игровой поток ждёт чтения файла
Опровергает
Если такие же остановки бывают и в уже загруженных локациях, причина другая: превышение бюджета тика, GC
Чем проверить
Нужны логи и метрики игрового сервера или клиента
Подробнее
В облаке сервер, только что созданный из снапшота (копии диска), при первом чтении каждого блока забирает его из удалённого хранилища и работает гораздо медленнее обычного. Если первый вход особенно долгий только на серверах, которые только что поднялись при автомасштабировании, стоит заподозрить эту причину.

Источники

  1. Initialize Amazon EBS volumes AWS
    Том, созданный из снапшота, пока подтягивает блоки из S3, работает с повышенной задержкой и пониженной производительностью. Его заранее инициализируют, прочитав все блоки через dd или fio
  2. Amazon EBS fast snapshot restore AWS
    Быстрое восстановление из снапшота сразу выдаёт инициализированный том, и задержки при первом обращении нет
  3. pidstat(1) — Linux manual page sysstat
    -d: kB_rd/s по процессам (объём чтения с диска в секунду)
  4. perf-trace(1) — Linux manual page perf
    --duration показывает только системные вызовы дольше заданного числа ms
  5. Amazon CloudWatch metrics for Amazon EBS AWS
    VolumeAvgReadLatency: средняя задержка чтения за 1 минуту (инстансы Nitro)

Смотрите также

Тот же слой: L11 Диск

Причины с тем же симптомом (Фриз) на других слоях

Карточка в основной версии с иллюстрациями и экспериментами