А какие сейчас mesh-системы wifi в РФ самые модные?
Был Keenetic, Netcraze, а сейчас смотрю - пропал из продажи, остатки кто-то распродаёт. Или его просто переименовали?
0 просмотренных постов скрыто
Как проверить VPS-сервер: четыре команды для диагностики медленного сервера
Как проверить VPS-сервер, если API по какой-то причине отвечает дольше, а список процессов не объясняет задержку? Нужно поймать сам симптом и одновременно записать top, vmstat, iostat -x и ss. Эти данные покажут вам, где образовалась очередь: у CPU, памяти, диска или сокета. Такой сбор подходит для первичной диагностики Linux-сервера под прикладной нагрузкой, но без истории метрик и данных приложения не даёт точную причину сбоя. Поэтому проверку VPS-сервера нельзя сводить к одной команде.
Какие четыре команды сначала запустить на медленном сервере?
Для начала запустите top, интервальные vmstat и iostat -x, а ss повторяйте циклом. Начните запись до воспроизведения замедления и сохраните время каждого среза. Команды помогут выбрать между CPU, памятью, диском и сетью, но вывод нужно сопоставить с метриками приложения и проверить повторным запуском.
Сначала зафиксировать, когда и как сервер замедляется
Фраза «сервер тормозит» не скажет, в чем именно проблема. Запишите время, границы эпизода, затронутую операцию, обычную и наблюдаемую задержку, throughput и долю ошибок. Для фоновой задачи подойдут длительность шага, размер очереди и скорость обработки. Также сохраните рядом с системными логами идентификатор запроса или трассировки.
Перед тем как проверить VPS-сервер, убедитесь, что часы синхронизированы. Все логи и метрики приложения должны охватывать один эпизод. Для воспроизводимого короткого сбоя подойдёт минутная запись с шагом 5 секунд. Если событие редкое, то запустите ограниченный по времени сбор заранее.
date --iso-8601=seconds
timedatectl show -p NTPSynchronized -p Timezone
uptime -s
На образе без systemd стоит отдельно проверить службу синхронизации времени.
После окончания нагрузки в логах останется только нормальное состояние. Для сравнения запишите такой же интервал без замедления: высокий load average, очередь диска или занятая память могут быть обычным профилем сервиса.
Проверить процессы, CPU и память в одном срезе
Данные интерактивного top пропадут после закрытия терминала, а набор полей зависит от настроек пользователя. Пакетный режим -b печатает срезы обычным текстом, без перерисовки экрана, поэтому вывод можно перенаправить в файл. Ключи описаны в руководстве procps-ng. Два запуска ниже сортируют процессы по CPU и памяти, а системная сводка остаётся в обоих логах.
LC_ALL=C COLUMNS=180 \
top -b -d 5 -n 13 -w 180 -o %CPU > top-cpu.log &
LC_ALL=C COLUMNS=180 \
top -b -d 5 -n 13 -w 180 -o %MEM > top-mem.log &
На вопрос, как проверить скорость VPS, один список процессов не ответит. us показывает время пользовательского кода, sy – работу ядра, wa – простой CPU при незавершённом I/O, st – время, которое гипервизор не предоставил vCPU. Высокий load average не доказывает нехватку CPU, так как Linux учитывает готовые к выполнению задачи и состояние непрерываемого ожидания. Поэтому сопоставляйте загрузку ядер с работающими процессами и состоянием D. Тот же срез закрывает и память: судить о ней по free нельзя, кеш освобождается по мере необходимости.
Увидеть очередь CPU, swap и системную динамику
vmstat сводит в одну строку процессы, память, swap, I/O и CPU. Команда пишет 13 строк с шагом 5 секунд. Первая содержит средние значения с момента загрузки, а текущий эпизод отражают следующие строки.
LC_ALL=C vmstat -w -t 5 13 > vmstat.log
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. Установить пакет лучше до диагностики, а не во время короткого сбоя.
LC_ALL=C S_TIME_FORMAT=ISO iostat -x -z -t -y 5 12 > iostat.log
Когда диагностика медленного сервера приводит к дисковой ветке, сначала найдите устройство проблемного пути. 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.
set -eu; : "${LOAD_DESC:?Задайте описание нагрузки}"
diag="diag-$(date +%Y%m%dT%H%M%S%z)"; mkdir -p "$diag"
{
date --iso-8601=seconds; uname -a; uptime
sed -n '1,12p' /etc/os-release
top -V; vmstat -V; iostat -V; ss -V
printf 'Нагрузка: %s\n60 с, шаг 5 с\n' \
"$LOAD_DESC"
} > "$diag/meta.log" 2>&1
LC_ALL=C COLUMNS=180 \
top -b -d 5 -n 13 -w 180 > "$diag/top.log" &
LC_ALL=C vmstat -w -t 5 13 > "$diag/vmstat.log" &
LC_ALL=C S_TIME_FORMAT=ISO \
iostat -x -z -t -y 5 12 > "$diag/iostat.log" &
(
for n in $(seq 1 12); do
date --iso-8601=seconds; ss -s; ss -tanpi; sleep 5
done
) > "$diag/ss.log" &
wait
Свести четыре вывода в дерево решений
Отметьте секунды, в которые выросла прикладная задержка. Команды для проверки сервера дают исходные данные, но ветку дерева выбирают два независимых сигнала, совпавших с этим моментом.
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-сервер, сначала определите границы симптома, затем ищите два согласованных сигнала и меняйте только один фактор. Не совпавший прогноз тоже полезен: он исключает ветку и не даёт принять следствие за причину или случайное совпадение за закономерность.
Реклама. ООО «Аеза Групп», ИНН: 7813654490. erid: 2RanynrnMLo
Показать полностью
1
Проблемы с задержкой сети, прошу помощи
Что имеется:
Провайдер - МГТС, в квартиру заведена оптика, подключена к их роутеру - InnboxG93.
Проблема: В различных игрушках(Фортнайт, дота 2, Дедлок, Лига Легенд, Танки от Лесты) с самого подключения провайдера(2 месяца) периодически возникают сильные лаги на несколько секунд, от одной до десятка, вплоть до полного таймаута от сервера и вылета.
Проведенная диагностика на нескольких устройствах разным способом подключения, а именно: 1) ноут с чистой виндой со встроенным wi-fi приемником
2) десктоп с TP-Link archer tx20u plus с включенным впн
3) десктоп с TP-Link archer tx20u plus без впна
4) десктоп, подключенным по витой паре
5) десктоп, подключенный к роутеру в режиме точки доступа, который подключен витой парой к роутеру мгтс.
Результаты:
Во всех случаях ping и psping до мгтс роутера показывал задержку в 1-5мс с периодическими поднятиями до 500-600мс, иногда лесенкой 1-5-30-70-150-300-500, а иногда сразу 1-5-600-18-1. За один час таких пиков могло быть 10-20, иногда терялись пакеты. Во время этого тестирования я так же играл и записывал точное время лагов в игре, они всегда совпадали с этими скачками. Такой же ping и psping до моего роутера в режиме точки доступа не превышал 30мс, и это был один скачок за час тестирования.
Погуглил, поизучал тему и ничего не смог найти. В поддержке мгтс сказали, что помочь не могут, могут только предложить установить gpon-розетку и поставить bridge, чтобы не было посредника, а я уже воткну туда свой роутер. Обоснованно это было тем, что скорее всего dns-сервер тормозит пакеты. Но как это возможно, если я пингую роутер, считай, в локальной сети, и причем тут вообще днс-сервак, я так и не понял. У меня есть сомнение, что это поможет, а скорее даже вызовет новые проблемы.
Возможно кто-то сталкивался и знает, что с этим можно сделать?
UPD: название роутера(оптического терминала) - InnboxG93
Показать полностью
В этот день семь лет назад, или "О разуме и ИИ - попытка абриса"
Знакомство с https://deep-econom.livejournal.com/ и его постами побудило описать свою позицию по теме разума и ИИ, и выразить ее текстом.
По-мне - трудно отделить искусственный интеллект от естественного (определение термина оставим на интуитивном уровне).
Ребенка заставляют учиться, он обучается думать используя искусственно созданные схемы.
И часто мы встречаем развитые человеческие интеллекты начисто лишенные "естественности".
С машинами (если их брать за основу ИИ) - то же самое.
Еще одна мнимая разница - границы. Единичный носитель интеллекта (человек) не умеет "думать" не находясь в сети современной ему культуры. С машинами то же самое, они по определению вне устройств ввода вывода - куски бесцельные.
С определениями разума - много чего написано. На мой вкус - шырше лучше чем глубже)
Например - разум есть способность предвидеть. Не обязательно должно быть одно определение, но для сейчасной мысли - одно, а там можно разделять и разнообразить, т. е. не от многого к одному, но напротив. Но не суть.
В любом случае - не выходит разума без взаимодействия сигналов (как носителей информации, представления данных, команд, символов). При прочих равных, тот разум "круче", который а) обрабатывает больший массив сигналов, б) делает это быстрей и в) дольше.
В пределах - модель реальности (тут другие противоречия наступают, например, где эта модель помещается и что может быть сигналом). Как вариант - все пригодные для этого элементы вписываются в систему, т. е. модель становится реальностью. Как представить - сеть встраивает в себя элементы реальности как только они становятся ей доступны. Аналогия с сегодняшней сетью - все больше элементов реальности встроены в сеть как "физически", материально, телесно, так и "социально", в сфере взаимодействий элементов сети с окружающей реальностью, так и информационно (тут у сети явный эксклюзив).
Что на мой взгляд сегодня на "выхлопе"? ИИ - есть. Экспансия сети во все аспекты "пространства" (по мне проще делить пространство на мат, соц, инф, поля) налицо. Проблема человека - поиски и эксплуатация "шлюзов" и попытки постановки задач и понимания решений (причем постфактум), ясно что повседневное управление делами человеческого социума без сети уже никак и никому.
Важный вопрос - а зачем сети органика вообще и человек в частности?
Один из ответов - если вообще ответ из области оптимистичных для человека в смысле вида существует - человек для цифры - источник рандомных сигналов. Если для сети (она же ИИ) сигналы есть ее "тело" (в инф. (цифровом) поле, то такой источник есть и причина развития и причина опасности и объект исследования). Если так, то будем жить в том числе и в виде органики (кому это по душе).
Еще вопрос - а что делаю лично я в создающихся условиях? Что и всегда. Тут каждый сам за себя и про себя.
Вот примерно то что я думаю сейчас о войне во Вьетнаме, в смысле о теме разума и ИИ.
Что делают девеломперы, программеры, инженеры, моделисты и прочие развиватели? Взгляд из под кустов - скорей то, что нужно сети а не то что нужно им.
Показать полностью
Метамарфоза
Показать полностью
1
Aeza топовое железо по честной цене
Mы даём максимум. Серверы, которые не проседают под нагрузкой для сайтов, ботов, игровых серверов, 1С и highload-проектов.
⚡️ AMD Ryzen 9 9950X — до 5.7 ГГц, топовый процессор
🌐 Канал до 25 Гбит/с
💾 NVMe-диски — в разы быстрее обычного SSD
🛡 DDoS-защита включена без доплат
♾ Безлимитный трафик — никаких лимитов и переплат
🌍 11 локаций (RU · EU · US) + /48 IPv6
💰 От 593 ₽/мес · активация за 2 минуты
👉 aeza.net
ООО «АЕЗА ГРУПП»
Показать полностью
Производительность Cloud VPS: первые метрики, которые должен проверить инженер
Сервис замедлился, в мониторинге всплывают ошибки – нужно быстро понять, в чём причина. На VPS причин больше, чем на физическом сервере: к собственной нагрузке добавляются гипервизор и соседи по ноде. Вот метрики производительности, с которых начинают диагностику.
CPU: load average и steal time
В top видны сразу оба числа: load average и %st. Load average выше числа vCPU – повод проверить нагрузку, но это только ориентир: в это значение входят не только задачи, ожидающие CPU, но и процессы в ожидании ввода-вывода. На серверах с быстрым I/O или большим количеством потоков высокий load не всегда означает проблему с процессором. Если %st высокий, mpstat -P ALL 1 покажет, какие именно ядра страдают. На Cloud VPS %st важен: стабильно высокий показатель может говорить о задержке выделения CPU со стороны гипервизора, но сам по себе не доказывает оверселлинг.
Память и swap
free -m: смотрите столбец available, но помните, что Linux использует свободную RAM под файловый кэш. Если available низкий, а vmstat 1 показывает ненулевые si/so – система уходит в swap и задержки растут. Проверьте dmesg | grep -i oom, OOM-killer мог убить процесс.
Диск: iowait и latency
iostat -x 1: %iowait в CPU-блоке выше 10–15% может быть сигналом для проверки диска и очереди I/O. Нормальные значения зависят от типа нагрузки: для баз данных, очередей и файловых сервисов они могут отличаться. По устройствам – await (мс) и %util. На NVMe %util ненадёжен: 100% не означает полной загрузки диска. Смотрите await: для NVMe тревожно выше 1–2 мс, для сетевого хранилища – выше 20 мс.
Сеть: пропускная способность и потери
ss -s показывает TCP-соединения по состояниям. Ретрансмиты проверяйте отдельно: nstat -az | grep -i retrans. Команда показывает статистику TCP-стека ядра, поэтому она не отражает все возможные потери пакетов на уровне сети провайдера. Тревожен не сам ненулевой счётчик, а его рост при штатной нагрузке. На VPS виртуальный сетевой стек может добавлять задержки, а ifstat показывает текущую скорость передачи данных через интерфейс.
Первые 5 минут: чек-лист
• uptime – load average за 1, 5 и 15 минут
• top – steal time (%st) и топ потребителей CPU
• free -m – нагрузка на память и своп
• iostat -x 1 3 – await и %util по дискам
• nstat -az | grep -i retrans – ретрансмиты и потери пакетов
Зафиксируйте базовые значения при штатной работе – без них разобраться в отклонениях сложнее. Запустите этот мониторинг на своём VPS и сохраните вывод для будущих сравнений.
Показать полностью
2
