У меня же ещё и подписка Яндекса есть. И не абы какая, а Плюс с Амедиатекой. Ну ленивый я. Влом мне качать торренты, потом копировать кино на флешку, искать эту флешку, втыкать её в телевизор и уже там смотреть.

В общем, опять отвлёкся.

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

И вот покупаю я себе Synology. NAS на два SATA-диска. Отдаю за него 25 тыщ рублёв и быстренько всё настраиваю.

А чё там настраивать? Всё для дебилов сделано. Как раз мне подходит. Ну, в смысле всё просто.

Самое главное — сервер сам ещё и торренты качать умеет.

Ставлю я его в офисе. А чё? Электричество у меня там безлимитное, входит в аренду. Пусть тратится. За интернет 100 мегабит я плачу аж 3500 рублей в месяц.

Да, плачу и плачу.

И это ещё самое дешёвое предложение. Всякие Мегафоны с Билайнами хотят около 10 000, а мелкий местный провайдер устроил аттракцион невиданной щедрости.

В общем, решил: когда меня нет в офисе, пусть сервер и качает, и раздаёт. Всё равно интернет простаивает, электричество простаивает, помещение простаивает. А так хоть какая-то деятельность происходит.

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

В общем, благодать. И недорого. Всего 25 тысяч.

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

А вот удалённо через этот, как его… QuickConnect, или «Синолоджи Коннект», — фиг тебе.

Хотя работать вроде бы должно.

Почитал отзывы. Народ пишет, что Synology из России ушла, на поддержку забила и вообще спасение утопающих — дело рук самих утопающих. Но если плавающий IP поменять на белый фиксированный, то всё должно заработать.

Звоню провайдеру. Прошу белый IP. И тут неожиданно выясняется, что он бесплатный и уже входит в мои 3500 рублей.

Вот это поворот.

Подключили. Всё заработало. Даже танцы с бубном особо разводить не пришлось.

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

Нафиг надо.

Я SMMщик, а не айтишнег. Вот мемасики с котиками — это да, это моё.

В общем, настроил всё окончательно. Домашний телевизор через интернет тоже подключил к Synology посредством VLC. Сижу теперь радуюсь. С телефона знай подкидываю на сервер торренты с тем, что хочу посмотреть, а он сам всё качает.

Яндекс Диск тоже синхронизировал. У меня там терабайт арендован, если что. Работа требует: файликами меняться, хранить кучу всякой фигни, которую вроде бы уже можно удалить, но вдруг через три года заказчик спросит именно её.

Теперь всё с Яндекс Диска автоматически прилетает на Synology, а уже оттуда по локальной сети почти мгновенно уходит на рабочий компьютер.

В принципе, даже видео прямо с Synology монтировать можно. Если находишься в офисе и работаешь по локалке, конечно. Через интернет монтировать я пока не настолько великий системный администратор.

И всё вроде бы хорошо.

Только 25 000 рублей на сервер немного жалко.

И почти 100 000 рублей на два HDD по 12 терабайт.

Ну да ладно. Отвёл душу. Потратил 125 тыщ, зато теперь у меня, как советовали на Пикабу, и кино своё, и музыка своя, и всё без цензуры, в оригинале и доступно откуда угодно.

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

А жаль.

Стоило ли оно того?

Да хз, если честно.

Платить Яндексу около 5000 рублей в год за Плюс с Амедиатекой, 600 рублей за Rutube с Premier и ещё примерно 2000 за почту с большим диском всё-таки немного менее накладно.

Но зато…

Теперь я качаю все фильмы и музыку без цензуры.

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

Экономия должна быть экономной 😁

У кого ещё есть домашний NAS? Рассказывайте, что мне теперь обязательно надо к нему докупить и настроить, чтобы потратить ещё тысяч пятьдесят. А то стриминги борзеют, корпорации на нас наживаются. Скажем нет беспределу, ударим рублём по моему карману 😁

Национальный университет Сингапура, DayOne и Cortical Labs представили биологическую серверную стойку CL1, внутри которой работают 16 миллионов живых нейронов выращенных из стволовых клеток человека. Электроды передают им электрические сигналы и считывают их реакцию, а специальная операционная система позволяет взаимодействовать с нейронной сетью и использовать ее для вычислительных задач.

Биологический компьютер потребляет всего 800–1000 Вт, включая оборудование для поддержания жизнедеятельности клеток. Для сравнения, аналогичные ИИ-стойки с электронными чипами расходуют более 100 кВт электроэнергии.

Если часть вычислений перенести с кремния на живые нейронные сети, потребность дата-центров в электроэнергии можно сократить более чем в 100 раз!

Серверные стойки CL1 уже доступны для покупки по предзаказу на сайте CorticalLabs.

Много интересного в телеграм-канале ЭнергетикУм

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-сервер, сначала определите границы симптома, затем ищите два согласованных сигнала и меняйте только один фактор. Не совпавший прогноз тоже полезен: он исключает ветку и не даёт принять следствие за причину или случайное совпадение за закономерность.