Aeza

p99 fsync против пиковых IOPS сравнивать бессмысленно, поскольку показатели снимают в разных режимах работы накопителя. Для WAL важна хвостовая задержка fsync при подтверждённой записи, тогда как пиковые IOPS обычно получают с глубокой очередью. Вывод действует только для указанной конфигурации: устройства, файловой системы, кэша, sync-метода и нагрузки.

Почему p99 fsync полезнее пиковых IOPS?

p99 fsync показывает границу, ниже которой уложились 99% синхронизаций в прогоне. Пиковые IOPS показывают пропускную способность при заданной очереди и ничего не говорят об одном flush WAL. Но и p99 оценивают только вместе с числом операций, длительностью теста и конфигурацией конкретного хранилища.

Показать, где WAL ждёт подтверждения записи

При COMMIT процесс добавляет запись о завершении транзакции в WAL и вызывает XLogFlush до нужного LSN. PostgreSQL сбрасывает WAL-буферы в файл, затем просит ОС синхронизировать его. При synchronous_commit=on клиент получает подтверждение после локального flush. Если настроена синхронная репликация, время ответа также зависит от ожидания standby и выбранного режима.

Способ синхронизации WAL задаёт wal_sync_method. На Linux по умолчанию используется fdatasync: PostgreSQL пишет WAL через файловый кэш, затем вызывает fdatasync(). Варианты open_datasync и open_sync открывают файл с другими флагами. Семантика каждого варианта разобрана в документации PostgreSQL, а скорость проверяют на файловой системе будущего pg_wal.

Завершённый write() ещё не говорит о сохранности после потери питания, поскольку данные могли остаться в памяти ядра или энергозависимом кэше контроллера. Поэтому хвостовая задержка fsync включает работу ядра, файловой системы и контроллера, а не только запись блока. Перед тестом фиксируют устройство, LVM или RAID, mount options, политику кэша и наличие power-loss protection.

Почему пик операций не предсказывает транзакционную задержку

IOPS измеряют числом завершённых операций за секунду. Высокий результат часто получают с десятками запросов в очереди, чтобы контроллер использовал параллелизм NAND. При одиночном COMMIT это преимущество исчезает, так как транзакция ждёт конкретный flush.

Средняя latency тоже скрывает паузы. Если 9900 синхронизаций заняли 0,2 мс, а 100 заняли 20 мс, среднее составит около 0,4 мс, хотя у 1% транзакций задержка будет около 20 мс. Заявленная p99 задержка хранилища требует единиц, числа выборок и периода. Без них доля медленных операций неизвестна.

Глубину очереди меняют отдельной серией. QD=1 показывает задержку без очереди, а QD=8 или 32 проверяет параллелизм. При синхронном psync значение iodepth выше единицы не создаёт настоящую очередь, поэтому нужен асинхронный engine с direct=1. Полученную пропускную способность нельзя выдавать за задержку WAL и тем более сравнивать с рекламным read IOPS.

Читать p50, p95 и p99 как форму риска

Перцентили относятся к одному распределению. p50 делит выборку пополам, выше p95 остаются 5% операций, выше p99 остаётся 1%. Для 100 000 операций этот хвост даёт около тысячи наблюдений, а для 1000 – только десять, поэтому маленькая выборка сильнее реагирует на шум.

Как измерять fsync при реалистичной нагрузке?

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

Показатели p50/p95/p99 дополняют гистограммой: по ней видно, образует ли хвост один пик или несколько режимов. На графике, где IOPS отложены против задержки, подпишите block size, queue depth, jobs и длительность. Максимум сохраняют отдельно, так как выброс мог совпасть с checkpoint, discard или работой гипервизора.

По временному ряду видно, распределены ли редкие паузы по всему тесту или хвост создал один провал. Всплески сопоставляют с выводом iostat -x 1, телеметрией NVMe и checkpoint.

Повторить размер записи, очередь и конкурентность WAL

Как правило, сначала фиксируют версию PostgreSQL, wal_sync_method, synchronous_commit, объём WAL за секунду и число одновременно завершающихся транзакций. Скорость генерации WAL считают по разнице показаний pg_stat_wal, а конкурентность берут из журналов и метрик за тот же период. Размер синхронной записи берут из реального профиля, а при его отсутствии помечают как допущение. При конкуренции PostgreSQL может подтвердить несколько транзакций одним flush, поэтому число синхронизаций окажется меньше числа COMMIT.

Сначала моделируют одиночную синхронизацию с выбранным размером блока, например 8 KiB: один job, QD=1, тот же каталог и sync-метод. Затем повышают число jobs. Асинхронный QD-тест идёт отдельно, иначе невозможно понять, что дало прирост: конкурентность приложения или внутренняя очередь устройства.

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

Согласовать pg_test_fsync, fio и транзакционный прогон

pg_test_fsync сравнивает способы синхронизации и выводит среднее время операции. По документации PostgreSQL файл размещают на той же файловой системе, где будет pg_wal. Утилита помогает выбрать wal_sync_method, но не показывает хвост распределения и не предсказывает пропускную способность базы.

В прогоне, опубликованном 27 мая 2025 года, использовались PostgreSQL 16, Samsung 990 Pro, XFS и write-back-кэш. Фрагмент сырого вывода:

На том же сервере, но на Micron 7400 с PLP среднее время fdatasync составило 24 мкс. Полный вывод и топология стенда есть в исходном отчёте, но из-за разной конфигурации это сравнение классов накопителей, а не моделей.

Чтобы получить распределение, используют fio job, в котором заданы engine, block size, QD и длительность. Укажите отдельный тестовый файл: fio перезапишет его и потребует не менее 32 GiB свободного места.

Команда fio wal-fsync.fio --output=wal-fsync.txt --output-format=normal сохраняет отчёт, а percentile_list задаёт перцентили. Для WAL смотрите раздел fsync/fdatasync/sync_file_range. Отдельная асинхронная серия покажет, как меняется задержка NVMe при разной глубине очереди. Затем подтвердите результат в pgbench с -l или прикладном сценарии при тех же гарантиях сохранности данных.

Поймать cache exhaustion, flush и фоновые паузы

Короткий запуск может закончиться до исчерпания быстрого кэша SSD. Поэтому файл предварительно заполняют, устройство прогревают, а тест ведут до устойчивого режима. По временному ряду видно, как после исчерпания SLC-кэша падает пропускная способность или растёт задержка. Там же видны фоновые паузы. Один итоговый p99 смешивает быстрый старт с установившимся режимом.

Перед серией фиксируют write cache, PLP, температуру, прошивку, заполнение, discard и фоновые операции. Что из этого списка недоступно на виртуальном диске, также отмечают в отчёте. Кэш не отключают, поскольку тест повторяет рабочую конфигурацию, а потерю питания проверяют отдельно.

Какой p99 допустим для транзакционной нагрузки?

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

2. Определите, какую часть остатка можно отдать ожиданию WAL с учётом group commit.

3. Задайте запас и долю нарушений, затем подтвердите порог транзакционным тестом.

p99 fsync 5 мс уже больше, чем весь SLO в 4 мс. При SLO 100 мс такая задержка может поместиться в бюджет только после учёта остальных ожиданий. Результат проверяют после прогрева и при рабочем заполнении диска, а критерий пересматривают при смене прошивки, миграции VM или росте нагрузки.

Связать хвост fsync с SLO транзакций

p99 fsync нельзя напрямую приравнивать к p99 транзакции. В критический путь транзакции входят блокировки, вычисления, сеть, репликация и иногда несколько flush. Group commit объединяет синхронизации, а synchronous_commit=off убирает ожидание локального диска. Поэтому перед сравнением выясняют, какие этапы идут последовательно, а какие перекрываются.

Затем сопоставляются временные ряды. Если пики commit latency совпадают с ростом времени WAL fsync, await и длины очереди, накопитель становится основной гипотезой. Если метрики хранения остаются ровными, задержку ищут в блокировках, CPU или ожидании реплики. Причину подтверждают изменением одного фактора: устройства, sync-метода или профиля нагрузки.

В SLO записывайте порог, долю нарушений, окно и минимальное число операций. Вместе с результатами транзакционного теста нужно сохранить latency histogram, указав границы бакетов и число наблюдений. Размер запаса задаётся до серии. При росте конкурентности тест лучше повторить: очередь и group commit меняют связь между одним flush и числом завершённых транзакций.

Сделать результат проверяемым на другом стенде

К job-файлу и сырому выводу обычно добавляют дату, версии fio, PostgreSQL и ядра, файловую систему и mount options, модель и прошивку диска, RAID/LVM, кэш и PLP, размер файла, block size, QD, jobs, длительность и прогрев. Для VM также указывают контроллер и неизвестные свойства хранилища.

В папку результата положите fio.job, fio.txt, вывод pg_test_fsync, журналы pgbench, iostat, NVMe log и CSV временного ряда. Рядом с графиком приведите перцентили и число операций. Без исходных файлов нельзя проверить единицы, фильтрацию и границы интервала.

У steady-state workload должен быть критерий: например, 10 минут после 5-минутного прогрева или остановка fio по условию steady state. Выбор зафиксируйте в job-файле. В краткой версии публикации оставьте график p99 и ссылку на полную методику.

Хранилище для WAL выбирают по повторяемой задержке подтверждённой записи и по тому, укладывается ли транзакция в свой SLO. Сначала проверьте sync-метод на файловой системе pg_wal, затем снимите распределение задержек в fio и подтвердите вывод транзакционным тестом. Сырой вывод нужен, чтобы не спутать смену накопителя с изменением нагрузки. После такой проверки p99 fsync против пиковых IOPS перестаёт быть выбором между двумя цифрами: для планирования берут p99, измеренный при нужных гарантиях записи и сопоставленный с SLO.

Настройка VPS начинается со сверки: тот ли сервер выдали и кто, кроме вас, может на него войти. После первого входа нужно сверить параметры заказа, подтвердить SSH-отпечаток, создать отдельного администратора, ограничить входящие соединения и сохранить базовые метрики. Установка VPS по этой схеме рассчитана на образ Ubuntu 24.04 LTS с одним администратором. Панель или cloud-init могут менять эти шаги, поэтому некоторые пункты стоит проверять.

Что сделать сразу после получения доступа к VPS?

Для начала сверьте IP, регион, образ и ресурсы с заказом, затем найдите аварийную консоль и проверьте SSH-отпечаток. После входа создайте отдельного пользователя с sudo, подтвердите доступ по ключу во втором сеансе и только потом включайте firewall и запрещайте парольный вход. Для панели или готового образа сначала посмотрите уже открытые порты.

Что приходит после заказа VPS и что проверить до входа

В личном кабинете или письме указаны IPv4, логин, начальный пароль либо открытый ключ, а также IPv6, если он выдан. Сверьте с заказом регион, образ ОС, vCPU, RAM и диск. После загрузки проверьте их командами nproc, free -h, lsblk и cat /etc/os-release. С ошибкой в регионе или тарифе обратитесь в поддержку до размещения своих данных на сервер.

До первого SSH-входа найдите VNC или другую аварийную консоль, а также порядок запуска rescue mode. Это может понадобится, если ошибка в sshd_config или firewall закроет сетевой доступ. Инструкция Aéza по аварийному режиму показывает, где включается среда восстановления. Конечно, сама она не заменит резервную копию.

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

Как подключиться к VPS и проверить отпечаток ключа

В Linux, macOS и Windows Terminal SSH-клиент вызывается одинаково. В примере данные замените на те, что в карточке сервера:

При первом соединении OpenSSH показывает тип ключа хоста и SHA256-отпечаток.

The authenticity of host '203.0.113.42' can't be established.
ED25519 key fingerprint is SHA256:Wq6...K3A.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Не подтверждайте yes, пока не получите отпечаток другим путём. Откройте аварийную консоль и выполните ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub, затем сравните строку целиком.

После переустановки ключ хоста меняется. Если сервер не переустанавливали, предупреждение REMOTE HOST IDENTIFICATION HAS CHANGED требует остановки и проверки через консоль или поддержку. Команду ssh-keygen -R IP запускают только после подтверждения причины. На Windows запись хранится в %USERPROFILE%\.ssh\known_hosts, в Linux и macOS – в ~/.ssh/known_hosts.

Отдельный пользователь, sudo и вход по ключу

Сначала создайте учётную запись и каталог для ключа. Текущий сеанс пока не закрывайте:

На рабочем компьютере создайте ключ ssh-keygen -t ed25519 -a 100, если его ещё нет. В Linux перенесите открытую часть командой ssh-copy-id operator@IP. В macOS и Windows Terminal при отсутствии ssh-copy-id добавьте содержимое .pub в /home/operator/.ssh/authorized_keys через открытый сеанс, затем задайте владельца operator и права 600. Приватный ключ на сервер копировать не нужно. Войдите как operator во втором терминале и выполните sudo -v. После проверки можно продолжать настройку VPS сервера.

Как безопасно перейти с пароля на SSH-ключи?

Добавьте открытый ключ отдельному пользователю, войдите им во втором сеансе и проверьте sudo. Затем создайте конфигурационный фрагмент, который читается раньше остальных, выполните sshd -t и загрузите новую конфигурацию службы. Исходный сеанс держите открытым до повторного входа, а при ошибке исправьте настройки через аварийную консоль.

В Ubuntu файлы из sshd_config.d читаются раньше основного sshd_config, а для большинства директив действует первое найденное значение. Имя 00-local-hardening.conf помещает локальный фрагмент в начало порядка чтения.

После sshd -t выполните reload и, не закрывая текущую сессию, откройте вторую новым пользователем. Проверка вторым сеансом важнее самой команды: на Ubuntu 24.04 с сокет-активацией reload может вернуть ошибку, если ssh.service не запущен. Если вход не работает, исправьте фрагмент через VNC и повторите sshd -t.

Запретить входящие и открыть только нужные порты

UFW в стандартном Ubuntu изначально выключен, а в облачном образе пакет и вовсе может отсутствовать. Проверьте его, задайте политики и откройте SSH-порт. Если sshd слушает не 22-й порт, возьмите значение из sudo ss -utlnp.

Перед ufw enable оставьте SSH-сеанс открытым. Второй терминал понадобится, чтобы проверить, как подключиться к VPS при действующих правилах. ufw status показывает эти правила, а ss -utlnp – слушающие сокеты и связанные процессы. Сетевой экран не останавливает сами службы.

Порты 80 и 443 добавляют после запуска веб-сервера. Базу данных, Redis и административную панель не нужно открывать всему интернету только потому, что приложение к ним подключается. Смена SSH-порта уменьшает шум от сканеров в журнале, но не заменяет ключи и запрет входа по паролю. В руководстве Ubuntu по UFW описаны простые правила, однако сетевой экран в панели провайдера остаётся отдельным уровнем.

Docker направляет трафик к опубликованным портам в обход обычных правил UFW. Сервис за обратным прокси привязывайте к 127.0.0.1. Для iptables правила пишите в цепочку DOCKER-USER: она документирована и не перезаписывается при перезапуске Docker. При другом бэкенде фильтруйте трафик в панели провайдера.

Обновления, время, локаль и swap без лишнего тюнинга

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

В стандартной установке Ubuntu 24.04 пакет unattended-upgrades ежедневно применяет обновления безопасности. Сторонние репозитории без отдельного правила он не охватывает, а автоматическая перезагрузка по умолчанию выключена. Ответственного за окно обновлений и перезагрузку лучше всё равно назначить, а результат контролировать по /var/log/unattended-upgrades/.

Для серверных журналов удобно оставить UTC: sudo timedatectl set-timezone UTC. Локаль C.UTF-8 уменьшает расхождения в выводе скриптов, если приложение не требует другой: sudo localectl set-locale LANG=C.UTF-8. Менять локаль ради отдельной команды не нужно, достаточно запускать её с LC_ALL=C.

Swap даёт ядру запас при резком пике памяти. При нехватке RAM этот механизм может вызвать длительные задержки при обращении к диску. Сначала проверьте текущий swap и профиль приложения. Для базы данных или сервиса, чувствительного к задержке, размер и vm.swappiness выбирают после замеров. Если в vmstat постоянно растут столбцы si/so, пересмотрите лимиты или тариф до увеличения swap.

Как доказать, что VPS работает после настройки

Сразу после настройки сервер пустой, и это лучший момент снять базовую линию. Через месяц, когда появится жалоба на медленную работу, сравнивать будет не с чем. Зафиксируйте дату, исполнителя, ОС, ядро, vCPU, RAM, диск и версии утилит. Для CPU сохраните минутный лог mpstat, для диска используйте временный файл, а iperf3 запускайте до своего узла в целевом регионе.

Как проверить безопасность и базовую производительность VPS?

1. Сохраните эффективные параметры sshd -T, правила ufw status numbered и список слушающих сокетов ss -utlnp.

2. Сохраните минутный лог mpstat, запустите fio на две минуты и запишите p50/p95/p99, затем выполните прямой и обратный прогоны iperf3.

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

date -Is; uname -r; lscpu | sed -n '1,16p'; free -h; lsblk
fio --version; iperf3 --version; mpstat -V
LC_ALL=C mpstat -P ALL 1 60 | tee mpstat.log
fio --name=baseline --filename=/var/tmp/fio.bin --size=1G --direct=1 \
--rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --iodepth=1 \
--runtime=120 --time_based --group_reporting --percentile_list=50:95:99 \
--output-format=json --output=fio.json
rm -f /var/tmp/fio.bin
: "${IPERF_HOST:?Укажите адрес сервера iperf3}"
iperf3 -c "$IPERF_HOST" -P 4 -t 30 -O 5 --json > iperf3-send.json
iperf3 -c "$IPERF_HOST" -P 4 -t 30 -O 5 -R --json > iperf3-recv.json

fio нагружает диск, поэтому запускайте его в согласованное окно: на основном сервере и на соседних VM нагрузка будет заметна. iodepth=1 показывает задержку одиночной очереди, а не максимальные IOPS при глубине 32. Файл должен помещаться на диске с запасом. В документации fio JSON содержит IOPS и completion latency percentiles, включая заданные p50, p95 и p99.

На собственном контрольном узле запустите iperf3 -s, задайте его адрес в IPERF_HOST и выполните прямой и обратный прогоны с одинаковыми параметрами. Публичный узел не служит эталоном. По официальной документации iperf3 для теста нужны клиент и сервер. Между прогонами не меняйте конечные узлы и их конфигурацию. Сохраните JSON и повторите замер трижды. Оценивайте %steal вместе с загрузкой vCPU: одиночный всплеск не доказывает проблему хоста.

Привязать домен и не ждать TTL вслепую

A-запись содержит IPv4 сервера, AAAA-запись содержит IPv6. Перед добавлением AAAA проверьте маршрут, сетевой экран и прослушивание сервиса по IPv6. Первоначальная настройка VPS также требует проверить, проксирует ли DNS-провайдер веб-трафик и какой IP увидит пользователь.

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

Если ответы расходятся, сравните их TTL с ответом авторитетного сервера. Очистка локального кеша не изменит запись у внешнего резолвера. Для HTTPS дополнительно проверьте сертификат и имя виртуального хоста, поскольку правильный A/AAAA ещё не подтверждает готовность приложения.

Для исходящей почты нужен PTR, который настраивает владелец IP-диапазона. Имя из PTR должно прямым запросом возвращаться к тому же адресу. Требования Gmail для всех отправителей включают согласованные прямую и обратную DNS-записи, а также SPF или DKIM. При отправке более 5000 писем в сутки на адреса Gmail нужны оба механизма и DMARC. Если сервер не отправляет почту напрямую, веб-сайту PTR не нужен.

Что добавить после первого часа: бэкап, мониторинг и сервис

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

Бэкапы храните вне VPS и регулярно восстанавливайте тестовую копию. Не стоит путать со снапшотами: они фиксируют состояние на момент создания, но не заменяют независимую копию и журнал восстановления. Частоту выбирают по RPO, а время восстановления по RTO. Для базы данных нужна согласованная копия средствами СУБД или остановка записи на время снимка.

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

Docker, панели и бэкапы требуют отдельных инструкций: у них разные сетевые правила, каталоги данных и процедуры обновления. Одного администратора и UFW недостаточно для командной работы, персональных данных, публичной БД или требований регулятора. В этих случаях нужны журналирование действий, раздельные роли, MFA, проверенное восстановление и контролируемый процесс выпуска изменений.

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

Через сутки после первого запуска повторите контрольные проверки. Убедитесь, что обновления завершились, место на диске не заканчивается, сервис отвечает, а задание бэкапа выполнилось успешно. Считайте, что настройка VPS закончена, когда текущее состояние можно проверить, а порядок восстановления понятен тому, кто будет сопровождать сервер.

MSPT и TPS сервера Minecraft показывают темп тиков и длительность каждого тика. Среднее значение может скрыть длинные тики, поэтому разберём, как читать тайминги Minecraft на Paper. Результат зависит от версии ядра, мира, плагинов, онлайна и метода измерения.

Чем TPS отличается от MSPT?

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

Понять бюджет главного потока Minecraft

Чтобы понять, как читать тайминги Minecraft, начните с цикла сервера. При стандартном tick rate сервер должен выполнять 20 тиков в секунду, поэтому на один тик приходится 50 мс. За это время главный поток обновляет миры, сущности и блоковые сущности, выполняет запланированные задачи плагинов, обрабатывает часть сетевых пакетов и применяет изменения мира. Большая часть этой работы идёт последовательно: следующий тик не начнётся, пока не завершится текущий.

Порог 50 мс не стоит считать универсальным. Если тик закончен раньше, сервер ждёт до следующего тика. Если позже, начинает отставать и пытается наверстать время. При изменённом tick rate меняется и бюджет. Поэтому рядом с метрикой фиксируют версию ядра и целевую скорость тиков.

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

Читать темп тиков с учётом сглаживания и потолка

TPS показывает средний темп за окно измерения. В выводе spark встречаются значения за несколько периодов, поэтому число нужно подписывать: «TPS за последнюю минуту», а не просто «TPS». На сервере со стандартным tick rate верхняя граница равна 20. Из-за этого ровные 20 TPS не говорят, что все тики были короткими: после одного длинного тика следующие могли завершиться быстро.

Связка 20 TPS и 50 MSPT даёт границу только для стандартного темпа. Когда средний тик стабильно занимает больше 50 мс, сервер уже не успевает поддерживать 20 TPS. Но обратный вывод другой: близкий к 20 средний TPS не исключает редкий тик на 200 или 500 мс. На длинном интервале он мало изменит среднее, хотя игрок заметит паузу.

Для устойчивой перегрузки TPS полезен: падение на минутном и пятиминутном интервале показывает, что проблема не ограничилась одним эпизодом. Для короткого лага берут временную линию MSPT и профиль того же периода. Не сравнивайте TPS из разных ядер или команд без оговорки: реализации могут использовать разные окна, округление и целевой tick rate.

Смотреть медиану и хвост времени тика

По MSPT видно распределение tick time, то есть длительности отдельных тиков. Медиана отражает обычный тик, p95 показывает границу для 95% наблюдений за выбранное окно, а максимум отмечает самый длинный эпизод. Среднее чувствительно к выбросам и не отвечает на вопрос, насколько часто они возникают. Поэтому для жалобы «раз в минуту всё зависает» важнее хвост распределения и временная линия, чем одно среднее значение.

Почему при нормальном TPS игроки всё равно видят лаги?

TPS может оставаться около целевого значения, потому что он усредняет темп за выбранное окно и имеет верхнюю границу. Игроки при этом замечают отдельные длинные тики. Похожий симптом дают паузы GC или задержки в сети. Сначала сопоставьте жалобу с MSPT, ping и профилем того же периода.

Длинный тик откладывает обработку действий всех игроков на главном потоке, поэтому дверь открывается или удар регистрируется позже. Если пики MSPT совпадают с такими паузами, дальше нужен профиль CPU. При этом старые тайминги Paper брать за основу не стоит: Paper помечает Timings устаревшими, а с 1.21 отключает их по умолчанию в пользу spark.

Снять профиль именно во время воспроизводимого лага

Диагностика лагов тика Minecraft начинается не с длинной записи «на всякий случай», а с воспроизводимого эпизода. Запишите версию Paper, Java и spark, число игроков, список миров и плагинов, view-distance и simulation-distance. Рядом опишите действие: например, перелёт в ещё не сгенерированную область, запуск фермы или массовое перемещение сущностей. Без этого профиль трудно повторить после правки.

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

/spark tickmonitor --threshold-tick 80
/spark profiler start --only-ticks-over 80 --timeout 300

Порог 80 мс здесь служит примером, а не универсальным значением. Его выбирают по разрыву между длительностью обычных и проблемных тиков. После завершения второй команды spark вернёт ссылку на профиль. Перед публикацией проверьте вкладки с конфигурацией, именами миров, адресами и комментариями: ссылка публична для каждого, кто её получил.

Найти работу, которая удерживает главный поток

Профайлер spark MSPT показывает отдельно от TPS, но причину лага не называет. В viewer откройте Server thread и идите по ветке с наибольшим временем до конкретного метода, сущности или плагина. Верхние узлы вроде MinecraftServer.tickChildren() лишь объединяют работу ниже. Их доли включают дочерние вызовы, поэтому соседние уровни нельзя складывать как независимые расходы.

Публичный профиль Paper 1.21.11 от 4 августа 2026 года показывает, как читать дерево. За 30-секундное окно при одном игроке средний темп составил 0,91 TPS; медиана равнялась 1110 мс, p95 1227 мс, максимум 1282 мс. В мире было 32 695 сущностей. В ветке Server thread профилировщик отнёс 28,6 из 30 секунд к Slime.tick() и 24,9 секунды к вложенному pushEntities(). Профиль указывает не на абстрактную нехватку CPU, а на обработку столкновений огромной группы слаймов.

Вывод относится только к профилю: Paper 1.21.11, один игрок, 30 секунд, запись запущена из консоли. В другом отчёте узел с именем плагина может лишь вызывать код ядра. Гипотезу подтверждают только после спуска к дочернему узлу и проверки тем же сценарием.

Сопоставить длинные тики с событиями мира и JVM

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

1. В spark сначала откройте Server thread: именно он выполняет последовательную работу игрового тика.

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

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

Снимок дерева показывает, на каких вызовах профилировщик собрал образцы CPU, но не всегда объясняет редкий всплеск. Поэтому spark profiler читают вместе с временной линией. Отметьте момент генерации чанков, autosave, массового спавна, телепортации и сборки мусора. Если тот же пик появляется после одинакового действия, гипотеза становится проверяемой.

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

Изменить один фактор и повторить тот же сценарий

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

До и после правки сохраняют версию ядра, seed и состояние мира, маршрут игрока, онлайн, длительность профиля и настройки JVM. На живом сервере трудно повторить нагрузку полностью, но условия должны быть близкими, чтобы изменение не потерялось в шуме. Одного удачного прогона не хватит: повторите серию и сравните медиану, p95, максимум, TPS за одинаковое окно и симптом, который наблюдали игроки.

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

Превратить профиль в приоритет исправлений

Исправления сортируют по подтверждённому времени главного потока, а не по популярности совета. Если в viewer доминируют entities and chunks, проверяют источник массового спавна, размер активной области, генерацию мира и тяжёлые операции. Настройку выбирают по найденной ветке: снижение view-distance не исправит плагин, который синхронно обходит всех игроков каждый тик.

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

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

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

Цель диагностики не удержать TPS на отметке 20, а убрать подтверждённую работу, которая растягивает тик. Для каждого вывода сохраняют версию, условия, временное окно и профиль. В таком отчёте MSPT и TPS сервера Minecraft помогают проверить причину лага и результат исправления, не ограничиваясь двумя цифрами.

Как проверить VPS-сервер, если API по какой-то причине отвечает дольше, а список процессов не объясняет задержку? Нужно поймать сам симптом и одновременно записать top, vmstat, iostat -x и ss. Эти данные покажут вам, где образовалась очередь: у CPU, памяти, диска или сокета. Такой сбор подходит для первичной диагностики Linux-сервера под прикладной нагрузкой, но без истории метрик и данных приложения не даёт точную причину сбоя. Поэтому проверку VPS-сервера нельзя сводить к одной команде.

Какие четыре команды сначала запустить на медленном сервере?

Для начала запустите top, интервальные vmstat и iostat -x, а ss повторяйте циклом. Начните запись до воспроизведения замедления и сохраните время каждого среза. Команды помогут выбрать между CPU, памятью, диском и сетью, но вывод нужно сопоставить с метриками приложения и проверить повторным запуском.

Сначала зафиксировать, когда и как сервер замедляется

Фраза «сервер тормозит» не скажет, в чем именно проблема. Запишите время, границы эпизода, затронутую операцию, обычную и наблюдаемую задержку, throughput и долю ошибок. Для фоновой задачи подойдут длительность шага, размер очереди и скорость обработки. Также сохраните рядом с системными логами идентификатор запроса или трассировки.

На образе без systemd стоит отдельно проверить службу синхронизации времени.

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

Проверить процессы, CPU и память в одном срезе

Данные интерактивного top пропадут после закрытия терминала, а набор полей зависит от настроек пользователя. Пакетный режим -b печатает срезы обычным текстом, без перерисовки экрана, поэтому вывод можно перенаправить в файл. Ключи описаны в руководстве procps-ng. Два запуска ниже сортируют процессы по CPU и памяти, а системная сводка остаётся в обоих логах.

На вопрос, как проверить скорость VPS, один список процессов не ответит. us показывает время пользовательского кода, sy – работу ядра, wa – простой CPU при незавершённом I/O, st – время, которое гипервизор не предоставил vCPU. Высокий load average не доказывает нехватку CPU, так как Linux учитывает готовые к выполнению задачи и состояние непрерываемого ожидания. Поэтому сопоставляйте загрузку ядер с работающими процессами и состоянием D. Тот же срез закрывает и память: судить о ней по free нельзя, кеш освобождается по мере необходимости.

Увидеть очередь CPU, swap и системную динамику

vmstat сводит в одну строку процессы, память, swap, I/O и CPU. Команда пишет 13 строк с шагом 5 секунд. Первая содержит средние значения с момента загрузки, а текущий эпизод отражают следующие строки.

r показывает готовые к выполнению задачи, b – задачи в непрерываемом ожидании. Очередь r выше числа vCPU вместе с высоким us или sy поддерживает мысль о нехватке CPU. si и so показывают обмен со swap, а не его занятый объём. При включённом swap стабильно ненулевые si/so, дисковая активность и задержка указывают на подкачку. Без swap нулевые значения ни о чём не говорят, здесь нужны MemAvailable, OOM-события и /proc/pressure/memory.

Как отличить проблему CPU, памяти, диска или сети?

Снимайте показатели в одном окне: очередь r и загрузку CPU, обмен со swap, r_await, w_await и очередь диска, повторные передачи и очереди сокетов. Один всплеск не определяет узкое место. Нужны замедление приложения и второй сигнал того же ресурса в соседнем логе.

Проверка скорости VPS-сервера как раз и сводится к поиску этой связи, а не самого большого процента в отчёте.

Проверить очередь и задержку конкретного диска

Расширенный режим iostat снимает статистику по блочным устройствам. Ключ -y пропускает отчёт со средними с момента загрузки, -z скрывает неактивные устройства, -t добавляет время. В Debian и Ubuntu утилита входит в sysstat. Установить пакет лучше до диагностики, а не во время короткого сбоя.

Когда диагностика медленного сервера приводит к дисковой ветке, сначала найдите устройство проблемного пути. r/s и w/s показывают операции, rkB/s и wkB/s – поток данных, aqu-sz – среднюю очередь. По описанию sysstat, r_await и w_await включают очередь и обслуживание запроса. Сравнивайте r_await и w_await с задержкой приложения и профилем нагрузки.

%util, близкий к 100%, показывает насыщение устройства с последовательным обслуживанием. Для NVMe, RAID и других параллельных устройств показатель не показывает предел производительности. На VPS видимый диск может скрывать хранилище хоста. Не суммируйте строки диска, раздела и device mapper: одна операция учитывается на нескольких уровнях.

Найти переполненные очереди, retransmits и состояние сокетов

ss не имеет интервального режима, поэтому скрипт ниже запускает его циклом. -n отключает разрешение имён, -a включает все сокеты, -p показывает процесс, -i – TCP-данные. Без root сведения о чужих процессах могут отсутствовать.

Чтобы понять, как проверить скорость VPS-сервера со стороны сети, различайте слушающие и установленные сокеты. У установленного соединения Recv-Q показывает непрочитанные байты, Send-Q – неподтверждённые данные. У слушающего сокета поля показывают текущую и предельную очередь подключений. Её рост у одного процесса указывает, что он может не успевать принимать соединения.

В TCP-информации ищите retransmits, RTT и RTO. Повторная передача означает, что отправитель не получил пригодное подтверждение вовремя. Причинами могут быть потеря, задержка, переупорядочивание пакетов или ложный тайм-аут. Точную сторону проблемы счётчик не определяет. Много TIME-WAIT не считается ошибкой без исчерпания локальных портов. Ключи описаны в руководстве iproute2.

Пороги для RTT, retransmits и очередей у каждого сервиса свои: эталоном служит ваш же базовый интервал без замедления. Скрипт ниже собирает такой пакет за одно окно, после того как вы опишете нагрузку в LOAD_DESC.

Свести четыре вывода в дерево решений

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

1. CPU: r устойчиво выше числа vCPU, а top показывает занятые ядра. При высоком wa сначала проверьте диск.

2. Память: при включённом swap растут si/so и задержка. Без swap нужны MemAvailable, OOM-события и PSI.

3. Диск: растут r_await, w_await или aqu-sz, а vmstat показывает задачи b либо top – состояние D.

4. Сеть или сокет: одновременно растут RTT, retransmits либо очереди сокетов и ухудшаются latency или error rate.

Смешанная картина не означает несколько разных причин. Медленная запись увеличивает число задач в состоянии D; рабочие процессы перестают принимать запросы, и растёт очередь соединений. В такой последовательности дисковая задержка выглядит первичным сигналом, а очередь сокета – следствием. До проверки это лишь предположение.

Какие данные собрать до проверки приложения?

5. Версию ОС и утилит, часовой пояс, начало симптома и длительность выборки.

6. Полные команды и сырые интервальные логи top, vmstat, iostat -x и ss.

7. Описание нагрузки, endpoint или задачу, latency, throughput, error rate и базовый интервал.

Эти интервалы должны перекрывать один эпизод: разновременные логи в причинную цепочку не сводятся.

Проверить, отвечает ли ресурсная гипотеза на симптом

Системный сигнал нужно связать с сервисом. Сопоставьте по времени p50, p95 и p99 latency, throughput и error rate. Для очереди заданий подойдут время жизни старейшей задачи и скорость обработки. Рост r_await или w_await без прикладной задержки может относиться к другому диску. Если сервис замедлился без ресурсных сигналов, проверяйте блокировки, внешние зависимости и DNS.

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

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

Оформить короткий пакет для следующего шага

Передавайте каталог с логами и коротким README, а не один скриншот top. Укажите автора, дату, конфигурацию VPS, ОС, ядро, команды, нагрузку и границы симптома.

Разделите диагноз на факты, гипотезу и недостающие данные. Факт содержит время и источник, например одновременный рост w_await и p95 одного адреса API. Гипотеза описывает механизм и ожидаемый результат проверки. Термин network latency без маршрута, RTT и стороны измерения остаётся предположением.

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

Хорошая первичная диагностика заканчивается не определением «виновного» ресурса, а предположением с проверяемым прогнозом. Сохранённые команды, временные метки и описание нагрузки дают другому инженеру возможность повторить ход проверки и оспорить вывод. Если нужно решить, как проверить VPS-сервер, сначала определите границы симптома, затем ищите два согласованных сигнала и меняйте только один фактор. Не совпавший прогноз тоже полезен: он исключает ветку и не даёт принять следствие за причину или случайное совпадение за закономерность.

Сколько токенов в секунду выдаёт 7B-модель на CPU?

В опубликованном в 2024 году тесте Llama 2 7B на 12-ядерном Snapdragon X Elite без GPU генерация достигла 20,72 токена/с в Q4_0 и 12,65 в Q8_0 при сборке llama.cpp cddae48. Конечно, это лишь ориентир: другая модель, память, контекст или сборка изменят результат.

Зафиксировать модель, формат и железо до первого замера

Одинаковое число параметров не означает одинаковую скорость. У Llama 2 7B, Mistral 7B и Qwen2.5 7B различаются число слоёв и KV-голов, размер скрытого состояния и токенизатор. Перед тестом запишите точное имя GGUF-файла, его SHA-256, тип квантования и коммит llama.cpp. Для запуска 7B-модели на CPU добавьте к отчёту параметры доступного железа.

Зафиксируйте модель CPU, число доступных процессоров, инструкции и объём RAM. На собственном сервере добавьте физические ядра, SMT, каналы памяти и NUMA-топологию. В VPS lscpu, numactl и dmidecode показывают только топологию, открытую гипервизором, а физические ядра и каналы RAM хоста по ней определить нельзя. Также запишите ОС и версию ядра.

В публикуемом результате укажите дату. Коммит будет важнее номера релиза: оптимизации CPU и схемы квантования меняются между сборками. Для готового комплекта бинарных файлов сохраните вывод llama-cli --version. На собственном сервере запишите режим масштабирования частоты, в VPS он обычно недоступен для управления.

Развести обработку промпта и генерацию токенов

llama-bench измеряет две разные фазы. pp512 показывает обработку входа из 512 токенов. Здесь вычисления идут пакетами, поэтому сильнее влияют векторные инструкции, число ядер и размер batch. tg128 измеряет последовательную генерацию 128 токенов. На каждом шаге рантайм снова читает веса, и ограничением часто становится пропускная способность памяти.

Поэтому скорость инференса 7B на процессоре нельзя сводить к одному числу. Короткий вопрос может быстро пройти prefill, а затем медленно выводить ответ. В RAG-сервисе с большим найденным контекстом, наоборот, время до первого токена определяет обработка промпта.

Результаты нужно записывать раздельно: длина входа и pp в tokens/s; длина ответа и tg в tokens/s. Среднее двух фаз ничего не говорит ни о задержке первого токена, ни о темпе выдачи. Для заполненного KV-кэша укажите его глубину. В официальной документации к llama-bench уточняется, что тест не учитывает токенизацию и сэмплирование, поэтому его вывод не равен задержке HTTP-запроса.

Проверить, помещаются ли веса и KV-кэш без swap

Оценка памяти начинается с фактического размера GGUF. В публичном наборе Llama 2 7B файл Q4_0 занимает 3,56 ГиБ, Q8_0 – 6,67 ГиБ, F16 – 12,55 ГиБ. К весам добавляются KV-кэш, вычислительные буферы, отображённые страницы и память процесса сервера.

KV-кэш растёт вместе с контекстом и числом слотов, также объём зависит и от числа KV-голов. Поэтому единого требования к RAM для всех 7B-моделей нет. 8 ГиБ хватит не каждой Q4-сборке. Для одной Q4- или Q8-модели с умеренным контекстом обычно выбирают 16 ГиБ, для длинного контекста или нескольких слотов – 32 ГиБ.

Как квантование и пропускная способность RAM влияют на скорость?

Квантование уменьшает вес файла и объём чтения из памяти, поэтому генерация часто ускоряется. При декодировании предел задаёт не заявленная частота CPU, а доступная пропускная способность RAM и эффективность ядра квантования. Меньший файл не гарантирует прирост, если для его формата нет подходящей оптимизации.

В llama.cpp токены в секунду сопоставимы только между прогонами без swap. Во время теста проверяйте RSS и si/so в vmstat. Часть RAM оставьте ОС и процессу, который обслуживает запросы.

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

Закройте фоновые задачи и прогрейте модель. На сервере не нужно менять режим управления частотой и лимит мощности. В VPS записывайте частоту и %steal. Используйте один список CPU. Задайте -ngl 0, чтобы исключить GPU.

Команда строит матрицу для трёх значений -t: каждый вариант повторяется десять раз. JSON хранит среднее, разброс и samples_ts. В отчёте приведите медиану и диапазон, а исходный файл сохраните. Для p95 требуется больше повторов. На сервере с известной топологией сначала оставьте по одному CPU на ядро, затем добавьте SMT-потоки. В VPS сравнивайте наборы vCPU: сколько за ними физических ядер, изнутри не видно.

Не начинайте следующую серию сразу после троттлинга. Записывайте температуру, частоту, загрузку соседних процессов и время теста, а в VPS добавьте %steal. Производительность 7B Q4 на перегретом устройстве и на сервере с тем же числом ядер может заметно различаться.

Сравнить компромисс размера, скорости и качества

Сравнивайте квантования одной модели, собранные из одного исходного чекпойнта. В опубликованном CPU-тесте Llama 2 7B использовался Surface Laptop 7 с 12-ядерным Snapdragon X Elite. Платформа поддерживает восемь каналов LPDDR5x-8448 с заявленной пропускной способностью 135 ГБ/с.

Фрагмент исходного вывода:

Результат опубликовал Andreas Kunar в 2024 году. Стенд: 15-дюймовый Surface Laptop 7, Snapdragon X Elite, 12 ядер без SMT, llama.cpp cddae48 (3646). Дата прогона, объём RAM и отдельные повторы не указаны. На этом стенде Q4 почти вдвое уменьшил файл и ускорил генерацию, но мало изменил обработку промпта.

Бенчмарк LLM на CPU не измеряет качество ответов. Q4 нельзя считать лучше Q8 только по скорости: допустимые потери определяет прикладная проверка.

Найти насыщение физических ядер и памяти

На сервере с известной топологией увеличивайте -t от половины физических ядер до их полного числа, а SMT проверяйте отдельной серией. В VPS используйте ступени до числа доступных vCPU. На x86 с P- и E-ядрами или несколькими NUMA-узлами перечислите выбранные CPU и не смешивайте разные наборы в одной серии.

Какие настройки нужны для сопоставимого бенчмарка?

1. Зафиксируйте GGUF-файл, коммит рантайма, CPU, RAM, ОС и режим питания.

2. Не меняйте число слоёв на GPU, длину промпта и генерации, размер контекста, batch, число повторов и привязку CPU.

3. Проведите прогрев, сохраните JSON каждого прогона и сопоставляйте медиану с разбросом.

После добавления потоков pp может расти, когда tg уже упёрся в память. Логические процессоры не удваивают пропускную способность и могут усилить конкуренцию за кэш. По RSS определите, сколько RAM нужно модели 7B при выбранном контексте и числе слотов. Здесь нужно ориентироваться на фазу, важную для сервиса.

Проверить контекст, шаблон чата и режим выдачи

Синтетические pp512 и tg128 удобны для сравнения железа, но далеки от реального диалога. Возьмите типичный системный промпт и запрос, задайте характерную длину ответа. Зафиксируйте шаблон чата из GGUF, число слотов, batch, размер контекста и параметры сэмплирования. Записывайте фактическое число входных и выходных токенов.

Влияние заполненного контекста проверяйте через -d: параметр предварительно заполняет KV-кэш перед pp/tg. Серия -d 0,2048,8192 покажет, как глубина истории влияет на генерацию. Для сервера отдельно измерьте TTFT, межтокенную задержку и полное время запроса.

Использовать нужно тот же бинарный файл. На x86 сборка может задействовать AVX2, AVX-512 или AMX, на ARM – NEON и I8MM. Флаг в lscpu не подтверждает, что инструкция задействована. Не меняйте temperature, top_p и seed. Фиксируйте состояние кэша общего префикса: он сокращает повторный prefill.

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

Скорость генерации оценивайте вместе с TTFT. Для интерактивного помощника одному пользователю обычно хватает 15–25 токенов/с, но длинный prefill задержит первый токен. В пакетной задаче важнее общая пропускная способность. В офлайн-обработке допустимы и единицы токенов/с, если соблюдены бюджет и срок.

До теста задайте критерии. Например, медиана tg не ниже 15 токенов/с, p95 TTFT не выше 3 секунд при промпте на 1000 токенов. Свопинга нет, одновременно обрабатывается один запрос. Результаты другого стенда даже с той же версией llama.cpp подойдут только для предварительного выбора CPU и RAM.

Если pp растёт с потоками, а tg почти остановился, ограничением, скорее всего, стала память. Если обе фазы проседают с частотой, проверьте питание и температуру. В VPS записывайте %steal: его колебания объясняют часть разброса.

Решение о развёртывании принимайте по замерам на своей модели и типичном запросе: отдельно для prefill, генерации и времени до первого токена. Для сервиса проверьте параллельные запросы: однопользовательский тест не покажет суммарную пропускную способность. Сохраните команду, параметры стенда и JSON, чтобы повторить сравнение после обновления рантайма. У формулировки 7B-модель на CPU: токены в секунду нет универсального ответа: значение имеет смысл только вместе с диапазоном, условиями теста и ограничениями.

Вы арендовали VPS, получили IP и пароль от root. Между этим моментом и рабочим сервисом в продакшене лежит десяток шагов, которые важно пройти в правильном порядке. Пропустить один из них означает оставить сервер уязвимым или потратить часы на отладку в самый неподходящий момент. И здесь встаёт вопрос: как подготовить свой VPS к реальной работе?

Этот материал проведёт вас от первого SSH-подключения до полноценного окружения с безопасным доступом, настроенным firewall и рабочим стеком приложений. Руководство написано для Ubuntu 22.04 LTS: проверенного LTS-релиза, который часто используют для серверов и небольших проектов. В конце вас ждёт чек-лист, который удобно держать под рукой при каждой новой установке.

Что понадобится до начала установки VPS

Перед тем как приступить к установке VPS и первичной настройке, убедитесь, что у вас есть всё необходимое.

Во-первых, данные для подключения: IP-адрес сервера, имя пользователя (обычно root) и пароль или SSH-ключ. Всё это провайдер высылает на email сразу после создания машины. Если провайдер вместо пароля сразу добавил публичный ключ, убедитесь, что соответствующий приватный ключ есть у вас локально.

Во-вторых, терминал на локальной машине. На macOS и Linux SSH встроен по умолчанию. На Windows удобно использовать PowerShell со встроенным OpenSSH-клиентом.

Заранее найдите в панели провайдера KVM/VNC-консоль, она понадобится в случае потери SSH-доступа после изменений в конфигурации сети или firewall.

Первое подключение к серверу по SSH

Подключитесь к серверу из терминала. Замените YOUR_IP на IP-адрес сервера:

При первом подключении терминал покажет предупреждение с отпечатком (fingerprint) сервера (уникальным идентификатором хоста) и предложит добавить его в список доверенных. Перед подтверждением сверьте fingerprint с данными в панели провайдера или документации к инстансу. Если он совпадает, введите yes. SSH сохранит ключ хоста в ~/.ssh/known_hosts. Если отпечаток изменится при повторном подключении, это может указывать на атаку посредника или на переустановку сервера.

Если провайдер настроил аутентификацию по SSH-ключу, а не по паролю, укажите путь к приватному ключу:

Возможные ошибки при первом подключении:

• Connection refused: SSH-сервис не запущен или порт закрыт. Проверьте состояние сервера через панель провайдера, иногда образ ещё инициализируется.

• Permission denied (publickey): ключ не добавлен на сервер или указан неверный путь к файлу ключа.

• Connection timed out: IP указан неверно или сервер ещё загружается. Подождите минуту и повторите.

Для удобства при частых подключениях настройте алиас в файле ~/.ssh/config на локальной машине:

После этого достаточно набрать ssh myserver. При необходимости подключаться под другим пользователем добавьте второй блок Host с другим значением User.

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

Сразу после входа обновите список пакетов и сами пакеты.

После обновления установите базовый набор инструментов:

Назначение каждого пакета:

•  curl и wget: загрузка файлов и скриптов из сети;

•  htop: интерактивный мониторинг процессов и потребления ресурсов;

• ufw: управление правилами firewall поверх iptables;

• fail2ban: автоматическая блокировка IP при многократных неудачных попытках входа.

Если после обновления терминал выводит System restart required, было обновлено ядро. Выполните reboot, дождитесь восстановления SSH-соединения (обычно 30–60 секунд) и продолжайте.

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

Безопасная работа на своём VPS начинается с отказа от постоянной работы под root. Любая ошибка в команде или скомпрометированный пакет, запущенный с правами root, получает неограниченный доступ к системе. Создайте отдельного пользователя с правами sudo.

Если у вас ещё нет SSH-ключа, сгенерируйте его на локальной машине. Алгоритм ed25519 предпочтительнее RSA:

Публичный ключ находится в ~/.ssh/id_ed25519.pub. Его нужно добавить на сервере в файл ~/.ssh/authorized_keys того пользователя, под которым вы будете подключаться по SSH.

Создание пользователя и добавление в группу sudo:

В выводе должна присутствовать группа sudo. Зайдите под новым пользователем и проверьте работу sudo: выполните sudo whoami, вывод root подтверждает корректную конфигурацию. Скопируйте SSH-ключи из root-окружения:

Важно: откройте вторую сессию и убедитесь, что вход под admin работает, прежде чем вносить следующие изменения. Потеря доступа на этом этапе потребует входа через KVM/VNC-консоль провайдера.

Откройте конфигурацию SSH:

Найдите и задайте параметры:

Перезагрузите конфигурацию через reload, а не restart: активные сессии при этом не прервутся.

Опционально: смена стандартного порта SSH с 22 на нестандартный снижает объём шума от автоматических сканеров в логах. Если решите изменить порт, сначала разрешите новый порт в UFW, затем внесите изменения в sshd_config и только после этого перезагрузите SSH.

Настройка брандмауэра и базовой защиты

Свежий сервер без firewall попадает под сканирование портов в первые минуты после выдачи публичного IP. UFW (Uncomplicated Firewall) снижает этот риск без необходимости работать с iptables напрямую. По умолчанию UFW блокирует весь входящий трафик и разрешает исходящий трафик.

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

Разрешите нужные порты:

Если используете нестандартный порт SSH, добавьте его вместо или дополнительно к 22 на период перехода. Включите firewall и проверьте статус:

Вывод Status: active и список разрешённых портов подтверждают корректную работу. Все остальные входящие соединения будут отклоняться.

Настройка fail2ban. На Ubuntu 22.04 SSH-события пишутся в systemd journal, поэтому создайте файл /etc/fail2ban/jail.local с указанием backend:

Перезапустите сервис и проверьте статус:

В выводе строки Currently banned и Currently failed покажут число заблокированных адресов и количество неудачных попыток за текущий период. Снять блокировку вручную можно командой fail2ban-client set sshd unbanip IP. Если fail2ban не видит попыток входа при реальных ошибках, проверьте значение backend = systemd в конфиге.

Установка рабочей среды: веб-сервер, БД, язык

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

Nginx в роли веб-сервера и reverse proxy – стандартный выбор для большинства проектов:

Node.js. Версия в стандартном репозитории Ubuntu 22.04 может быть старее актуальной LTS-версии. Для установки свежей LTS-версии можно использовать NodeSource, предварительно сверив номер версии на nodejs.org:

Python 3 уже предустановлен в Ubuntu 22.04. Для работы с виртуальными окружениями добавьте:

Docker как универсальный вариант

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

Добавьте пользователя в группу docker, чтобы команды выполнялись без sudo:

Изменения применятся при следующем входе в сессию. Docker Compose v2 устанавливается как плагин и вызывается без дефиса:

Пример минимального docker-compose.yml для сервиса с автоперезапуском:

Проверьте, что Docker установлен корректно и может запустить тестовый контейнер:

Домен, SSL и автозапуск сервисов

Привязка домена. В DNS-настройках у регистратора добавьте A-запись, указав IP сервера:

Обновление DNS-записей занимает от нескольких минут до 24 часов. Проверить это можно командой dig yourdomain.com или через онлайн-сервисы вроде dnschecker.org. Не запускайте certbot до того, как запись распространится: это приведёт к ошибке валидации.

HTTPS через Let's Encrypt. Установите Certbot с плагином для Nginx:

Получите сертификат:

Certbot изменит конфигурацию Nginx, добавит HTTPS-блок с путями к сертификату и предложит настроить редирект с HTTP на HTTPS. Обновление сертификата происходит через cron или systemd timer без вашего участия. Сертификат Let's Encrypt действует 90 дней. Проверьте, что продление пройдёт без ошибок:

Автозапуск сервисов. Пакеты, установленные через apt, как правило, включаются в автозапуск автоматически. Для собственного приложения создайте unit-файл:

Чек-лист: что проверить перед запуском в прод

Каждая установка VPS проходит по схожему маршруту. Сохраните этот список и проходитесь по пунктам при каждой новой настройке.

1. Система обновлена: apt update && apt upgrade выполнены

2. Создан непривилегированный пользователь с правами sudo

3. Root-вход отключён: PermitRootLogin no в /etc/ssh/sshd_config

4. Аутентификация только по SSH-ключу: PasswordAuthentication no

5. UFW активен: ufw status показывает Status: active с нужными правилами

6. fail2ban работает: fail2ban-client status sshd показывает активный jail

7. HTTPS настроен: certbot renew --dry-run выполняется без ошибок

8. Сервисы добавлены в автозапуск: проверьте systemctl is-enabled nginx и другие

9. Настроены бэкапы или снапшоты через панель провайдера

10. Запланированы регулярные обновления безопасности: настройте unattended-upgrades для security-обновлений или другой контролируемый процесс обновления.

От первого ssh root до продакшен-среды вполне можно дойти за один рабочий день. Настройка VPS-сервера с нуля требует внимания прежде всего на этапе безопасности: шаги, пропущенные здесь, могут позже дать о себе знать. Не жалейте времени на проверку каждого пункта чек-листа до открытия сервиса пользователям.

VPS с открытым SSH-портом быстро замечается ботами. На сервере счётчик неудачных входов набирает сотни попыток в сутки, а на давно засвеченных адресах – тысячи. Боты работают автоматически и не делают перерывов. Настройка VPS без базовой защиты от перебора – прямое приглашение для таких сканеров.

Оценить масштаб можно без внешних сервисов: откройте журналы за сутки и посмотрите, сколько раз повторяются одни и те же адреса или подсети. У нового сервера первые попытки нередко появляются через несколько минут после выдачи публичного IP. Поэтому Fail2Ban лучше ставить сразу после настройки доступа, а не когда перебор уже попал в мониторинг.

Fail2Ban не заменяет SSH-ключи, отключение входа по паролю и аккуратный firewall, но хорошо снимает самый частый шум от bruteforce: видит повторяющиеся ошибки входа и отправляет подозрительные IP в бан. Ниже – рабочая настройка для Ubuntu 22.04/24.04, Debian 11/12, AlmaLinux 9 и CentOS Stream 9: установка, jail.local, защита SSH и проверка результата.

Что такое Fail2Ban и как он работает?

Fail2Ban работает довольно просто. Этот инструмент на Python читает лог-файлы или systemd journal и ищет строки, похожие на неудачную аутентификацию. Совпало регулярное выражение – счётчик для IP увеличился. Набралось maxretry ошибок за findtime – адрес уходит в firewall на время bantime. Когда срок заканчивается, блокировка снимается автоматически.

Отдельный сервис поднимать не нужно, Fail2Ban использует системный firewall: iptables, nftables или firewalld. Вся защита от bruteforce держится на понятной связке: лог, фильтр, порог срабатывания и действие блокировки.

В конфигурации чаще всего встречаются два термина:

Jail – правило для конкретного сервиса: какие события читать, какие строки считать нарушением и что делать после превышения лимита.

Filter – набор failregex, то есть регулярных выражений для поиска нужных строк в логе. Для SSH, nginx, postfix и других популярных сервисов такие фильтры уже лежат в пакете.

Подготовка VPS перед установкой

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

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

Проверьте, что на сервере есть пользователь с sudo. Работать от root не рекомендуется: ошибка в конфиге или случайная команда могут повлиять на весь сервер.

Чек-лист перед установкой

•  SSH-доступ работает; запасная сессия открыта или есть KVM/VNC-консоль в панели провайдера

•  Внешний IP известен: curl -4 https://api.ipify.org

•  На сервере есть пользователь с sudo

•  Если используется UFW на Ubuntu/Debian, проверен его статус: sudo ufw status

• На AlmaLinux 9 / CentOS Stream 9 проверен firewalld: sudo systemctl status firewalld

Установка Fail2Ban на Ubuntu/Debian и AlmaLinux/CentOS

На Ubuntu и Debian пакет есть в стандартном репозитории:

/var/log/auth.log может отсутствовать при использовании systemd-journald вместо rsyslog. Если auth.log отсутствует или jail [sshd] не считает попытки входа, задайте backend = systemd. При использовании backend = systemd может потребоваться пакет python3-systemd. На минимальных образах он не всегда установлен:

Проблема с backend может выглядеть так: сервис запущен, jail [sshd] активен, но Currently failed остаётся 0 даже после заведомо ошибочных SSH-входов. В таком случае явно укажите backend = systemd и перезапустите инструмент.

В AlmaLinux 9 и CentOS Stream 9 Fail2Ban обычно ставят через EPEL. Для связки с firewalld понадобится дополнительный пакет fail2ban-firewalld:

На современных системах Fail2Ban также может работать через nftables без fail2ban-firewalld, в зависимости от выбранного banaction.

Запуск и добавление в автозагрузку:

Проверка статуса:

В статусе нужен Active: active (running). Если сервис упал, первым делом посмотрите последние сообщения unit:

Базовая конфигурация: jail.local без магии

/etc/fail2ban/jail.conf приходит вместе с пакетом и может измениться после обновления. Свои правила лучше держать в /etc/fail2ban/jail.local: он читается поверх jail.conf и обычно не перезаписывается при обновлениях.

Создаём файл:

Секция [DEFAULT] задаёт глобальные параметры для всех jail:

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

bantime определяет срок бана. Десять минут часто слишком мало: бот успевает вернуться с тем же или соседним адресом. Для рабочей SSH-защиты обычно начинают с 1h, а затем повышают до 24h, если ложных срабатываний нет.

findtime и maxretry всегда смотрят вместе. При findtime = 10m и maxretry = 5 адрес блокируется после пяти ошибок за десять минут. Для SSH это нормальный старт: пользователь с опечаткой не страдает, а простой перебор быстро отсекается.

backend = auto автоматически выбирает способ чтения логов в зависимости от окружения. В большинстве случаев этого достаточно, но если SSH-события не обнаруживаются, необходимо указать backend = systemd в нужном jail.

Защита SSH: минимально рабочая конфигурация

Добавьте в jail.local секцию [sshd] для защиты входа по SSH. Обычная настройка fail2ban ssh выглядит так:

Если SSH-события в Ubuntu 24.04 читаются через journal, добавьте в [sshd]:

Для AlmaLinux 9 и CentOS Stream 9 задайте действие блокировки через firewalld в [DEFAULT] или [sshd]:

После правок перезапустите сервис:

Дополнительные jail: nginx, postfix, панели управления

Фильтры для nginx, postfix, dovecot и других сервисов лежат в /etc/fail2ban/filter.d/. Например, для basic auth в nginx можно завести отдельный jail:

Для ISPmanager, cPanel, Plesk и других панелей универсального фильтра обычно нет. Правила лучше брать из документации панели или репозитория Fail2Ban, а затем прогонять у себя.

Проверка работы и мониторинг

Общий статус всех активных jail:

Статус jail [sshd] показывает, сколько раз правило сработало и какие IP сейчас в бане:

Если sshd не появился в списке jail, чаще всего проблема в jail.local. Проверить конфиг можно без перезапуска:

Разбанить конкретный IP:

Основной лог – /var/log/fail2ban.log. По строкам Ban и Unban видно, кого заблокировали и когда блокировка закончилась:

Если при реальных атаках строк Ban нет, а Currently failed держится на 0, Fail2Ban смотрит не туда. На системах, где SSH пишет в /var/log/auth.log, фильтр можно проверить так:

Типичные ошибки и как их избежать

Самоблокировка при настройке. Две-три ошибки в пароле – и ваш IP уже в бане. Перед тестами держите открытой запасную сессию. Если доступ пропал, зайдите через KVM/VNC в панели провайдера и снимите блокировку:

Неверный backend при использовании systemd journal. Если auth.log отсутствует, а backend оставлен auto, jail может не видеть SSH-события. Итог: Currently failed остаётся 0 при реальных неудачных входах. Обычно помогает backend = systemd в [sshd]; на минимальных образах проверьте python3-systemd.

Конфликт с firewalld на AlmaLinux и CentOS. Без fail2ban-firewalld и banaction блокировки через firewalld баны могут появляться в fail2ban.log, но не попадать в реальные правила firewall. Проверьте rich rules:

Конфликт с UFW на Ubuntu. Если Fail2Ban использует способ блокировки, который не совпадает с активным firewall, правила могут применяться некорректно. Проверьте выбранный banaction и используйте вариант, соответствующий вашему окружению: UFW, iptables, nftables или firewalld.

Слишком низкий maxretry. Значение 1–2 ловит не только ботов, но и людей с одной опечаткой при вводе пароля. Для SSH начинайте с 3–5 попыток; для веб-сервисов с живыми пользователями ставьте порог выше.

Ложные срабатывания. Если под бан попал легитимный пользователь или сервис, чаще всего виноваты слишком строгий maxretry или неподходящий failregex. На системах с /var/log/auth.log проверьте совпадения фильтра:

Если auth.log нет, смотрите SSH-события через journalctl и используйте backend = systemd. Адреса с постоянным административным доступом добавляйте в ignoreip.

Нет ignoreip для офисных адресов. При смене сети или работе из нескольких локаций риск заблокировать себя выше. Если у офиса статический IP, внесите в ignoreip всю офисную подсеть.

Итоговый чек-лист внедрения

1. Сервис стартует вместе с системой, а systemctl status fail2ban показывает active (running)

2. Пользовательские правила лежат в /etc/fail2ban/jail.local, минимум с секциями [DEFAULT] и [sshd]

3. В ignoreip внесены личный IP и административные подсети

4. bantime задан минимум на 1 час

5. Для систем с SSH-логами в systemd journal в [sshd] указан backend = systemd, а python3-systemd установлен или уже пришёл зависимостью

6. Для AlmaLinux 9 / CentOS Stream 9 установлен fail2ban-firewalld, а banaction работает через firewallcmd-rich-rules

7. fail2ban-client status sshd показывает активный jail и реальные счётчики при неудачных входах

Базовая настройка Fail2Ban обычно занимает 15–20 минут. После этого достаточно изредка проверять логи и whitelist, особенно при смене firewall, офиса или сети. Правильная настройка VPS сервера начинается с таких базовых вещей – ещё до деплоя приложения. Боты не ждут, пока вы закончите.