Как повысить производительность GTA-сервера: оптимизация и снижение задержек

Признаки проблем производительности GTA-сервера

Проблемы, заметные игрокам

• высокий или нестабильный ping;
• телепортация транспорта и персонажей;
• задержка выполнения команд;
• медленная авторизация;
• долгая загрузка имущества;
• зависание интерфейсов;
• позднее сохранение данных;
• обрывы соединения;
• долгая загрузка ресурсов;
• падение FPS клиента рядом с большим количеством объектов.

Проблемы на стороне сервера

• одно ядро процессора постоянно загружено;
• память игрового процесса непрерывно растёт;
• активно используется swap;
• диск занят чтением или записью;
• SQL-запросы выполняются слишком долго;
• появляются hitch warnings;
• серверный цикл не успевает завершаться вовремя;
• увеличивается очередь запросов к базе;
• журнал быстро занимает диск;
• сервер регулярно перезапускается.

Не путайте серверные и клиентские проблемы

Низкий FPS одного игрока может быть связан с его компьютером или графическими модами. Серверная проблема обычно одновременно затрагивает множество игроков и отражается в журналах или системных метриках.

Правильный порядок оптимизации GTA-сервера

1. Зафиксируйте текущие показатели.
2. Определите момент появления лагов.
3. Проверьте CPU, RAM, swap, диск и сеть.
4. Найдите самый нагруженный процесс.
5. Проверьте игровые скрипты и ресурсы.
6. Найдите медленные SQL-запросы.
7. Измените только один компонент.
8. Повторите тот же тест.
9. Сравните показатели до и после.
10. Оставьте изменение только при подтверждённом улучшении.

Сначала ищите узкое место

Высокий CPU → скрипты, циклы, большое число сущностей
Высокий RAM → утечка, кэш, слишком много ресурсов
Высокий disk I/O → база, журналы, резервное копирование
Высокий ping → сеть, перегрузка CPU, потеря пакетов
Медленный вход → SQL, авторизация, внешние API
Hitch warnings → медленный ресурс или обработчик

Не оптимизируйте по ощущениям

Фраза «сервер стал работать быстрее» должна подтверждаться временем выполнения, графиком нагрузки, задержкой игрового цикла или результатом одинакового теста.

Фиксация исходных показателей

Перед изменениями запишите состояние сервера в спокойный период и во время максимального онлайна.

Основные показатели

• текущий онлайн;
• CPU всего VPS;
• CPU игрового процесса;
• нагрузка каждого ядра;
• занятая и доступная RAM;
• использование swap;
• свободное место на диске;
• дисковая задержка;
• сетевой трафик;
• потеря пакетов;
• число подключений к базе;
• время медленных запросов;
• число перезапусков;
• время запуска сервера.

Пример таблицы измерений

Показатель До оптимизации
Игроки 120
CPU игрового процесса 92%
RAM процесса 3.1 GB
Swap 850 MB
Свободный диск 18%
Вход игрока 4.8 секунды
Сохранение аккаунта 1.2 секунды
Hitch warnings 17 за час

Проводите тест в одинаковых условиях

Нельзя сравнивать пустой тестовый сервер с рабочим сервером во время вечернего пика.

Анализ нагрузки процессора

Высокий общий CPU

Если загружены все виртуальные ядра, проверьте:

• игровой процесс;
• MySQL или MariaDB;
• веб-панель;
• сжатие резервных копий;
• антивирус;
• индексацию файлов;
• другие игровые серверы на VPS;
• посторонние процессы.

Высокая нагрузка одного процесса

Она может быть вызвана:

• бесконечным циклом;
• слишком частым таймером;
• массовой обработкой игроков;
• постоянным перебором сущностей;
• тяжёлым сериализатором;
• большим количеством сетевых событий;
• плохим SQL-запросом;
• зависшим ресурсом.

Проверьте процесс Linux

ps aux \
--sort=-%cpu |
head -n 20

Нагрузка по потокам

top -H \
-p PID_СЕРВЕРА

Проверьте частоту процессора

lscpu

grep MHz \
/proc/cpuinfo |
head

Высокий steal time

На перегруженном виртуальном хостинге гипервизор может не предоставлять VPS заявленное процессорное время. Это проявляется нестабильной производительностью даже без изменения игрового кода.

Почему GTA-серверу важна производительность одного ядра

Многие игровые операции выполняются последовательно в основном серверном цикле. Поэтому большое количество медленных виртуальных ядер не всегда лучше нескольких быстрых.

При выборе VPS учитывайте

• производительность одного ядра;
• поколение процессора;
• стабильность частоты;
• отсутствие сильного overselling;
• быстрый локальный диск;
• расположение дата-центра;
• защиту игрового трафика.

Когда добавление vCPU не помогает

Если основной поток уже упирается в одно ядро, увеличение числа ядер без оптимизации скрипта может почти не изменить производительность.

Когда дополнительные ядра полезны

• база работает на том же VPS;
• используются веб-панель и API;
• выполняются резервные копии;
• платформа распределяет отдельные задачи по потокам;
• работает несколько игровых процессов.

Проверка оперативной памяти и swap

Общая память Linux

free -h

Процессы по использованию RAM

ps aux \
--sort=-%mem |
head -n 20

Память конкретного процесса

ps \
-o pid,%cpu,%mem,rss,vsz,etime,cmd \
-p PID_СЕРВЕРА

Что означает RSS

RSS показывает объём физической памяти, используемой процессом в текущий момент.

Признаки утечки памяти

• RSS постоянно растёт;
• память не освобождается после выхода игроков;
• после перезапуска потребление резко уменьшается;
• через несколько часов появляются лаги;
• сервер завершается из-за нехватки памяти.

Проверка OOM Killer

sudo journalctl \
-k |
grep -iE \
'out of memory|killed process|oom'

Swap

Небольшое наличие swap полезно как аварийный резерв, но активная постоянная запись в swap обычно означает нехватку RAM.

swapon --show

vmstat 1

Не отключайте swap вслепую

Сначала определите, почему системе не хватает памяти. Без swap ядро может быстрее завершить MySQL или игровой процесс.

Анализ дисковой нагрузки

Свободное место

df -h

Размер каталогов сервера

sudo du \
-xh \
--max-depth=1 \
/opt/gta-server |
sort -h

Поиск крупных файлов

sudo find \
/opt/gta-server \
-type f \
-size +100M \
-printf '%s %p\n' |
sort -nr |
head -n 30

Нагрузка диска

sudo apt install sysstat -y

iostat -xz 1

Процессы, работающие с диском

sudo apt install iotop -y

sudo iotop -oPa

Причины высокой дисковой нагрузки

• медленные запросы без индексов;
• маленький кэш базы;
• слишком подробные журналы;
• резервное копирование в часы пик;
• архивация больших ресурсов;
• частая запись состояния каждого игрока;
• нехватка RAM и использование swap;
• медленный сетевой или HDD-диск.

Не допускайте полного заполнения диска

При отсутствии свободного места база может перестать записывать данные, а игровой процесс — создавать журналы и сохранения.

Проверка сети и задержек

Ping до сервера

ping play.example.com

Маршрут Linux

traceroute play.example.com

Маршрут Windows

tracert play.example.com

Более подробная проверка Linux

sudo apt install mtr-tiny -y

mtr \
--report \
--report-cycles 100 \
play.example.com

Сетевые счётчики

ip -s link

sudo ss -s

Причины высокой задержки

• далёкий дата-центр;
• неудачный маршрут провайдера;
• потеря пакетов;
• перегруженный сетевой канал;
• DDoS-атака;
• слишком большой сетевой трафик ресурсов;
• перегрузка CPU;
• медленная обработка игровых событий.

Ping и задержка скрипта — разные показатели

Низкий сетевой ping не гарантирует мгновенное выполнение команды. Обработчик может ждать завершения SQL-запроса или выполнения другого ресурса.

Диагностика GTA-сервера на Linux

Общее состояние

uptime
free -h
df -h
top

Удобный интерактивный монитор

sudo apt install htop -y

htop

Состояние службы

sudo systemctl \
status gta-server.service

Журнал службы

sudo journalctl \
-u gta-server.service \
-n 200 \
--no-pager

Журнал в реальном времени

sudo journalctl \
-u gta-server.service \
-f

Число перезапусков

systemctl show \
gta-server.service \
--property=NRestarts

Проверка системных ошибок

sudo dmesg \
--level=err,warn |
tail -n 100

Диагностика GTA-сервера на Windows

Процессы PowerShell

Get-Process |
Sort-Object CPU -Descending |
Select-Object -First 20 `
Name,
Id,
CPU,
WorkingSet64,
PrivateMemorySize64

Процессы по памяти

Get-Process |
Sort-Object WorkingSet64 -Descending |
Select-Object -First 20 `
Name,
Id,
WorkingSet64,
PrivateMemorySize64

Свободное место

Get-Volume |
Select-Object `
DriveLetter,
FileSystemLabel,
SizeRemaining,
Size

Сетевые соединения

Get-NetTCPConnection |
Group-Object State |
Sort-Object Count -Descending

Инструменты Windows

• Диспетчер задач;
• Монитор ресурсов;
• Монитор производительности;
• Просмотр событий;
• Process Explorer;
• Windows Performance Recorder.

Антивирусное сканирование

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

Проверка игрового процесса

Найдите PID Linux

pgrep -af \
'samp|omp|FXServer|altv|gta-server'

Наблюдение за процессом

pidstat \
-p PID_СЕРВЕРА \
-rud \
1

Открытые файлы процесса

sudo lsof \
-p PID_СЕРВЕРА |
head -n 100

Количество файловых дескрипторов

ls \
/proc/PID_СЕРВЕРА/fd |
wc -l

Следите за изменением показателей

Одно измерение не показывает динамику. Наблюдайте процесс до пика, во время пика и после выхода игроков.

Оптимизация игровых скриптов

Частые причины нагрузки

• перебор всех игроков каждый кадр;
• перебор всех автомобилей без необходимости;
• синхронное чтение файлов;
• SQL-запросы внутри частого обработчика;
• создание объектов при каждом событии;
• повторная загрузка одинаковых данных;
• неограниченный рост массивов;
• обработка события несколькими ресурсами;
• тяжёлые вычисления в основном потоке;
• отсутствие кэширования.

Плохой подход

Каждые 10 миллисекунд:
 перебрать всех игроков
 запросить данные из базы
 пересчитать все зоны
 записать результат в журнал

Более эффективный подход

При изменении данных:
 обновить состояние в памяти

Раз в разумный интервал:
 сохранить изменённые записи пакетно

При входе игрока:
 загрузить только нужные данные

Сначала измерьте обработчик

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

Оптимизация таймеров и циклов

Не запускайте частый таймер без необходимости

Проверка раз в секунду обычно не должна выполняться каждые 10 миллисекунд.

Объединяйте похожие задачи

Вместо сотен отдельных таймеров можно использовать один диспетчер, который обрабатывает только активные элементы.

Разделяйте частоту задач

Положение и критическая синхронизация → часто
Интерфейс и подсказки → реже
Автосохранение → раз в несколько минут
Очистка журналов → раз в сутки
Резервная копия → по расписанию

Не перебирайте неактивные сущности

Храните отдельные списки активных игроков, транспорта, зон или заданий.

Избегайте блокирующего ожидания

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

Оптимизация игровых событий

Проверяйте частые события

• движение игрока;
• изменение позиции;
• урон;
• вход и выход из зоны;
• сетевые события клиента;
• обновление интерфейса;
• синхронизация транспорта.

Не доверяйте клиенту

Проверка входящих данных нужна для безопасности, но её следует выполнять без повторных тяжёлых запросов и ненужного копирования больших структур.

Не отправляйте всем игрокам одинаковые данные повторно

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

Ограничьте пользовательские события

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

Оптимизация стриминга объектов и сущностей

Большой радиус увеличивает нагрузку

Чем больше объектов и игроков одновременно попадает в область видимости, тем больше данных требуется обработать серверу и клиентам.

Проверьте

• радиус стриминга;
• частоту пересчёта стриминга;
• количество объектов в одной зоне;
• дублирующиеся объекты;
• удаление временных сущностей;
• количество транспорта;
• интерьеры и виртуальные миры;
• дальность синхронизации.

Разделяйте игровые пространства

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

Не создавайте объект заново при каждом входе

Статические сущности лучше создавать один раз и корректно удалять при остановке ресурса.

Оптимизация журналов

Избыточное журналирование создаёт нагрузку

• частые операции записи на диск;
• увеличение размера файлов;
• медленный поиск ошибок;
• заполнение раздела;
• нагрузка при резервном копировании.

Не записывайте каждое движение игрока

Для аудита сохраняйте важные действия: вход, изменение денег, покупку имущества, административные команды и ошибки.

Настройте ротацию Linux

sudo nano \
/etc/logrotate.d/gta-server

Пример

/opt/gta-server/logs/*.log {
 daily
 rotate 14
 compress
 delaycompress
 missingok
 notifempty
 copytruncate
}

Проверьте конфигурацию

sudo logrotate \
-d \
/etc/logrotate.d/gta-server

Настройка производительности open.mp

Параметры серверного цикла и сетевой синхронизации влияют одновременно на нагрузку CPU, качество синхронизации и объём трафика.

Пример фрагмента config.json

{
 "network": {
 "port": 7777,
 "stream_radius": 200.0,
 "stream_rate": 1000
 },
 "sleep": 5.0
}

Параметр sleep

Уменьшение значения может повысить частоту серверного цикла, но увеличивает использование CPU. Повышение уменьшает нагрузку, но способно ухудшить качество синхронизации.

Не меняйте sleep первым шагом

Сначала исправьте тяжёлые скрипты, запросы и циклы. Изменение sleep не устраняет причину медленного кода.

stream_radius

Большой радиус увеличивает число сущностей, которые клиент может видеть и получать по сети.

stream_rate

Меньший интервал означает более частый пересчёт условий стриминга и дополнительную нагрузку процессора.

Сетевые частоты

Более частая синхронизация может улучшить плавность, но увеличивает объём трафика и обработку пакетов.

Изменяйте параметры постепенно

1. Запишите текущую нагрузку.
2. Измените один параметр.
3. Перезапустите тестовый сервер.
4. Повторите одинаковый сценарий.
5. Сравните CPU, server FPS, трафик и жалобы игроков.

Профилирование FiveM-сервера

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

Запуск профилирования

profiler record 500

Просмотр результата

profiler view

Сохранение результата

profiler saveJSON gta-profile.json

Что искать

• ресурс с большим временем выполнения;
• длинные тики;
• часто вызываемый обработчик;
• постоянно работающий поток;
• тяжёлый экспорт;
• синхронный SQL;
• большой объём сериализации;
• массовые сетевые события.

Профилируйте во время проблемы

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

Оптимизация ресурсов FiveM

Проверьте resmon

Клиентский монитор ресурсов помогает найти скрипты, создающие нагрузку на FPS клиента.

Типичные проблемы Lua и JavaScript

• цикл с ожиданием 0 без необходимости;
• частый поиск ближайшей сущности;
• повторное получение неизменяемых данных;
• создание больших таблиц;
• неограниченное накопление обработчиков;
• частая отправка событий всем игрокам;
• обращение к базе внутри игрового цикла;
• загрузка больших JSON-файлов;
• частое кодирование и декодирование JSON.

Плохой цикл

CreateThread(function()
 while true do
 Wait(0)

 -- Тяжёлые проверки каждый кадр
 end
end)

Более разумная частота

CreateThread(function()
 while true do
 Wait(500)

 -- Проверка, которой не требуется каждый кадр
 end
end)

Событийный подход

Когда возможно, обновляйте состояние при событии, а не постоянным опросом.

Не перезапускайте ресурсы вместо исправления

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

Анализ нагрузки MySQL и MariaDB

Проверьте активные подключения

SHOW STATUS
LIKE 'Threads_connected';

Запущенные запросы

SHOW FULL PROCESSLIST;

Размер базы

SELECT
 table_schema AS database_name,
 ROUND(
 SUM(data_length + index_length)
 / 1024 / 1024,
 2
 ) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'gta_server'
GROUP BY table_schema;

Самые крупные таблицы

SELECT
 table_name,
 table_rows,
 ROUND(
 (data_length + index_length)
 / 1024 / 1024,
 2
 ) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'gta_server'
ORDER BY
 data_length + index_length DESC
LIMIT 20;

Что обычно замедляет базу

• отсутствие индекса;
• выборка всех столбцов;
• поиск по неиндексированному полю;
• слишком большой результат;
• запрос внутри частого цикла;
• отдельная запись каждого небольшого изменения;
• долгая транзакция;
• блокировка строки или таблицы;
• слишком много одновременных соединений;
• медленный диск.

Включение журнала медленных запросов

Slow query log помогает найти запросы, которые выполняются дольше заданного времени.

Проверьте текущие параметры

SHOW VARIABLES
LIKE 'slow_query_log';

SHOW VARIABLES
LIKE 'long_query_time';

SHOW VARIABLES
LIKE 'slow_query_log_file';

Пример конфигурации MySQL

[mysqld]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = OFF

Пример конфигурации MariaDB

[mariadb]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 1

Перезапустите соответствующую службу

sudo systemctl restart mysql

или:

sudo systemctl restart mariadb

Просмотр журнала

sudo tail \
-f \
/var/log/mysql/mysql-slow.log

Сводка MySQL

sudo mysqldumpslow \
-s t \
-t 20 \
/var/log/mysql/mysql-slow.log

Не оставляйте слишком низкий порог без контроля

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

Проверка SQL-запросов через EXPLAIN

Пример

EXPLAIN
SELECT
 id,
 name,
 money
FROM accounts
WHERE name = 'Player_Name';

Обратите внимание на

• тип доступа;
• выбранный индекс;
• число проверяемых строк;
• дополнительную сортировку;
• временную таблицу;
• полное сканирование;
• условия фильтрации.

EXPLAIN ANALYZE

В поддерживаемой версии позволяет увидеть фактическое выполнение запроса, но сам запрос будет выполнен. Не запускайте изменяющие запросы на рабочей базе без понимания последствий.

EXPLAIN ANALYZE
SELECT
 id,
 owner_id
FROM vehicles
WHERE owner_id = 1250;

Не добавляйте индекс по каждому столбцу

Индексы ускоряют чтение, но занимают место и увеличивают стоимость INSERT, UPDATE и DELETE.

Оптимизация индексов базы данных

Проверка индексов таблицы

SHOW INDEX
FROM accounts;

Индекс для поиска аккаунта

CREATE UNIQUE INDEX
idx_accounts_name
ON accounts(name);

Индекс владельца транспорта

CREATE INDEX
idx_vehicles_owner_id
ON vehicles(owner_id);

Составной индекс

CREATE INDEX
idx_logs_player_created
ON player_logs(
 player_id,
 created_at
);

Порядок столбцов имеет значение

Состав индекса должен соответствовать реальным условиям WHERE, JOIN и ORDER BY.

Проверьте дублирующиеся индексы

Несколько почти одинаковых индексов занимают память и замедляют запись.

Перед добавлением индекса

1. Найдите медленный запрос.
2. Посмотрите его EXPLAIN.
3. Создайте резервную копию.
4. Добавьте индекс на тестовой базе.
5. Повторите измерение.
6. Проверьте скорость операций записи.

Оптимизация подключений к базе

Не создавайте новое соединение для каждого запроса

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

Проверьте максимальное число соединений

SHOW VARIABLES
LIKE 'max_connections';

SHOW STATUS
LIKE 'Max_used_connections';

Слишком большое max_connections опасно

Каждое соединение может потреблять дополнительную память. Увеличение лимита не исправляет утечку соединений или медленные запросы.

Закрывайте незавершённые операции

• освобождайте результат запроса;
• завершайте транзакции;
• не оставляйте соединение в ожидании;
• обрабатывайте ошибку подключения;
• используйте timeout;
• не выполняйте бесконечные повторные подключения.

База на удалённом сервере

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

Базовая настройка InnoDB

Buffer pool хранит часто используемые данные и индексы в памяти. Если он слишком мал, база чаще обращается к диску.

Проверьте размер

SHOW VARIABLES
LIKE 'innodb_buffer_pool_size';

Пример конфигурации

[mysqld]
innodb_buffer_pool_size = 2G

Не копируйте значение без расчёта

Подходящий размер зависит от общей RAM, размера базы и наличия на VPS игрового сервера, панели и других приложений.

Если база находится на отдельном сервере

Для buffer pool можно выделить большую долю памяти, оставив запас операционной системе и соединениям базы.

Если база и игра находятся на одном VPS

Оставьте достаточно памяти игровому процессу, системе и файловому кэшу. Иначе увеличение buffer pool приведёт к swap.

Проверьте текущую конфигурацию

mysql \
-u root \
-p \
-e "
SHOW VARIABLES
WHERE Variable_name IN (
 'innodb_buffer_pool_size',
 'max_connections',
 'tmp_table_size',
 'max_heap_table_size'
);
"

Настройка не заменяет исправление SQL

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

Обслуживание базы данных

Обновление статистики таблицы

ANALYZE TABLE accounts;
ANALYZE TABLE vehicles;
ANALYZE TABLE houses;

Проверка таблицы

CHECK TABLE accounts;

Не выполняйте тяжёлое обслуживание в часы пик

Некоторые операции могут создавать нагрузку, блокировки или временно требовать дополнительное место.

Удаляйте ненужную историю по расписанию

DELETE FROM player_logs
WHERE created_at
< NOW() - INTERVAL 180 DAY;

Удаляйте данные небольшими пакетами

Массовое удаление миллионов строк одной транзакцией способно создать длительную нагрузку и большой журнал изменений.

Архивируйте важные записи

Перед очисткой перенесите необходимые журналы в отдельную архивную таблицу или хранилище.

Кэширование часто используемых данных

Что можно хранить в памяти

• настройки сервера;
• справочники предметов;
• описания транспорта;
• параметры работ;
• данные организаций;
• неизменяемые координаты;
• часто используемые права;
• результаты дорогих вычислений.

Что нельзя бесконтрольно кэшировать

• пароли;
• неограниченные журналы;
• все данные всех игроков навсегда;
• результаты без срока действия;
• объекты без механизма удаления;
• данные, изменяемые несколькими серверами.

Используйте явную инвалидацию

При изменении данных обновляйте или удаляйте соответствующую запись кэша.

Кэш не должен быть единственным хранилищем

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

Пакетное сохранение

Можно накапливать изменённые поля в памяти и сохранять их пакетно, но необходимо предусмотреть:

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

Оптимизация файлов и игровых ресурсов

Удалите неиспользуемые ресурсы

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

Проверьте каталоги

• resources;
• plugins;
• filterscripts;
• cache;
• logs;
• backups;
• временные файлы;
• старые сборки.

Не храните резервные копии внутри рабочей папки

Архиватор или система синхронизации может повторно включить их в следующую копию.

Сжимайте веб-ресурсы

Для интерфейсов уменьшайте размер изображений, JavaScript, CSS, аудио и других загружаемых файлов.

Не загружайте огромный ресурс одним пакетом

Разделяйте содержимое и используйте кэш клиента, если это поддерживается платформой.

Проверяйте манифесты

Не подключайте клиенту серверные исходники, резервные файлы и данные, которые не требуются для игры.

Настройка операционной системы

Обновите систему

sudo apt update
sudo apt upgrade -y

Удалите ненужные службы

systemctl \
--type=service \
--state=running

Не отключайте службы вслепую

Сначала определите их назначение. Отключение сети, журналирования, SSH или синхронизации времени может нарушить работу сервера.

Проверьте лимит файлов

ulimit -n

Лимит службы systemd

[Service]
LimitNOFILE=65535

Применение изменения

sudo systemctl daemon-reload
sudo systemctl restart gta-server.service

Не повышайте лимиты без причины

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

Разделите рабочие задания

Резервное копирование, архивацию и тяжёлое обслуживание базы запускайте вне максимального онлайна.

Перезапуски и утечки памяти

Плановый перезапуск

Он может очищать временное состояние, но не должен быть единственным методом оптимизации.

Признаки скрытой проблемы

• после перезапуска сервер работает быстро;
• через несколько часов нагрузка растёт;
• память не возвращается;
• число таймеров увеличивается;
• повторно регистрируются обработчики;
• растёт число соединений с базой.

Автоматический перезапуск systemd

[Service]
Restart=on-failure
RestartSec=10

Контролируйте число перезапусков

systemctl show \
gta-server.service \
--property=NRestarts

Сохраняйте данные перед плановым рестартом

Игровой мод должен корректно завершить запись аккаунтов, транспорта, имущества и состояния организаций.

Нагрузочное тестирование GTA-сервера

Создайте тестовый стенд

Не проверяйте опасные изменения сразу на основном сервере.

Тест должен повторять реальную работу

• вход игроков;
• загрузка аккаунтов;
• создание транспорта;
• работу организаций;
• частые команды;
• массовые игровые события;
• сохранение данных;
• перезапуск ресурсов;
• работу панели и API.

Не создавайте вредоносную сетевую нагрузку

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

Продолжительность

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

Записывайте результат

Версия сборки
Количество игроков
Список активных ресурсов
CPU
RAM
Swap
Disk I/O
Время SQL-запросов
Число hitch warnings
Средний ping
Продолжительность теста

Сравнение результата оптимизации

Пример

Показатель До После
Игроки 120 120
CPU процесса 92% 61%
RAM процесса 3.1 GB 2.4 GB
Swap 850 MB 0 MB
Вход игрока 4.8 c 1.6 c
Сохранение аккаунта 1.2 c 0.2 c
Hitch warnings за час 17 2

Улучшение должно быть стабильным

Один удачный запуск не подтверждает результат. Повторите тест несколько раз и проверьте работу в период реального пика.

Следите за побочными эффектами

• ухудшение синхронизации;
• увеличение трафика;
• потеря данных;
• рост времени записи;
• дополнительная нагрузка клиента;
• задержка появления объектов;
• ошибки после перезапуска.

Распространённые ошибки оптимизации

Покупка большего VPS без диагностики

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

Изменение всех параметров одновременно

Невозможно определить источник улучшения или ухудшения.

Слепое копирование конфигурации MySQL

Настройки для отдельного сервера базы с 64 GB RAM не подходят небольшому VPS, на котором одновременно работает GTA-сервер.

Добавление индексов на каждый столбец

Избыточные индексы увеличивают размер базы и замедляют запись.

Снижение sleep без профилирования

Это повышает потребление CPU и не исправляет тяжёлый скрипт.

Слишком частое сохранение

Запись каждого небольшого изменения отдельным запросом перегружает базу.

Слишком редкое сохранение

При аварии игроки потеряют значительный объём прогресса.

Вывод отладки в каждом цикле

Журналирование может само стать источником дисковой нагрузки.

Плановый рестарт вместо исправления утечки

Перезапуск очищает симптомы, но проблема продолжает существовать.

Отсутствие тестового сервера

Неудачная оптимизация может повредить базу, конфигурацию или сохранения игроков.

Контрольный список оптимизации GTA-сервера

Диагностика

• зафиксирован текущий онлайн;
• проверена нагрузка каждого ядра;
• проверена память процесса;
• проверен swap;
• проверена дисковая задержка;
• проверена сеть;
• найдены самые тяжёлые процессы;
• сохранены исходные показатели.

Игровые скрипты

• проверены частые циклы;
• проверены таймеры;
• удалены повторные обработчики;
• сокращены массовые переборы;
• тяжёлые операции вынесены из частых событий;
• уменьшены лишние сетевые сообщения;
• проверено удаление временных сущностей;
• отключены неиспользуемые ресурсы.

База данных

• включён slow query log;
• проверены медленные запросы;
• использован EXPLAIN;
• добавлены только нужные индексы;
• проверено число соединений;
• настроен разумный buffer pool;
• проверены крупные таблицы;
• архивируются старые журналы.

Система

• достаточно свободного диска;
• настроена ротация журналов;
• резервные копии выполняются вне пика;
• нет постоянного swap;
• нет ошибок OOM;
• проверен steal time VPS;
• настроен внешний мониторинг;
• уведомления о сбоях работают.

Проверка результата

• повторён одинаковый тест;
• онлайн во время сравнения совпадает;
• CPU стал ниже;
• время SQL-запросов уменьшилось;
• нет потери данных;
• не ухудшилась синхронизация;
• результат проверен во время пика;
• изменения задокументированы.

Частые вопросы об оптимизации GTA-сервера

С чего начинать оптимизацию?

С измерения CPU, RAM, диска, сети и времени SQL-запросов. Сначала необходимо определить узкое место.

Поможет ли увеличение количества ядер?

Не всегда. Если основной игровой поток упирается в одно ядро, важнее производительность этого ядра и оптимизация скриптов.

Почему сервер начинает лагать только вечером?

При большом онлайне увеличивается количество игровых событий, сущностей, SQL-запросов и сетевого трафика.

Почему после перезапуска лаги исчезают?

Возможны утечка памяти, накопление таймеров, обработчиков, соединений или временных объектов.

Нужно ли уменьшать sleep?

Только после измерения server FPS и CPU. Уменьшение повышает нагрузку и не исправляет медленный код.

Как найти медленный ресурс FiveM?

Используйте серверный profiler, hitch warnings и клиентский resmon для клиентской части.

Как найти медленный SQL-запрос?

Включите slow query log, найдите повторяющиеся тяжёлые запросы и проверьте их с помощью EXPLAIN.

Нужно ли увеличивать max_connections?

Только если реальный пик соединений достигает лимита. Сначала исключите утечки и медленные запросы.

Какой размер innodb_buffer_pool_size установить?

Он зависит от доступной RAM и размещения других сервисов. Нельзя использовать универсальное значение для всех VPS.

Поможет ли перенос базы на другой сервер?

Да, если база конкурирует с игровым процессом за CPU, RAM и диск. При этом сеть между узлами должна иметь минимальную задержку.

Нужен ли swap?

Небольшой swap может защитить от внезапного завершения процессов, но постоянное его использование указывает на нехватку RAM.

Как часто сохранять данные игроков?

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

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

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

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

Сетевая задержка может быть нормальной, но основной поток ждёт скрипт, базу данных или внешний API.

Почему CPU невысокий, но сервер лагает?

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

Стоит ли отключать журналы?

Полностью отключать важные журналы не следует. Уберите избыточную отладку и настройте ротацию.

Как понять, что оптимизация помогла?

Сравните одинаковые тесты: CPU, память, время SQL-запросов, задержку игрового цикла, hitch warnings и жалобы игроков.

Итог

Производительность GTA-сервера повышается последовательным устранением измеренного узкого места. Сначала проверьте процессор, память, диск и сеть, затем переходите к профилированию игровых скриптов и базы данных.

Оптимизируйте частые циклы, таймеры, сетевые события и стриминг сущностей. Не выполняйте тяжёлые SQL-запросы внутри игрового цикла и не отправляйте клиентам неизменившиеся данные повторно.

Для базы данных используйте slow query log, EXPLAIN и необходимые индексы. Настраивайте InnoDB с учётом реального объёма RAM, размера базы и других приложений на VPS.

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