🐧 Linux · 20 вопросов · ~45 мин · ⏱ Таймер 45:00 · Сложный · 👥 1 прошёл

Производительность Linux

Высокая нагрузка — не диагноз. Процессор может ждать runnable-задачи, память — хранить полезный кэш, диск — иметь длинную очередь, а сеть — повторно передавать пакеты. Тест проверяет метрики, взаимосвязи ресурсов и порядок измерений до оптимизации.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. На 20 вопросов отведено 45 минут. Не меньше половины заданий требуют разобрать команды, сценарий Bash, конфигурацию или диагностический вывод. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и краткий разбор каждого решения.

Вопрос 1 из 20

На 8-ядерной машине load average держится около 7, CPU idle почти 0, runnable queue 7–9. Как это трактовать?

uptime
mpstat -P ALL 1
vmstat 1

Одно ядро занято, а остальные семь простаивают CPU почти насыщен; нужен профиль очереди и процессов Узкое место находится только в сети, потому что runnable queue не связана с CPU Load около 7 означает семь процессов в ожидании диска, а CPU свободен

Вопрос 2 из 20

Что означает высокий steal time в виртуальной машине?

Виртуальная машина готова работать, но гипервизор не даёт ей процессорное время Сетевой интерфейс повторно передаёт потерянные пакеты Другие процессы внутри гостя вытесняют анализируемый процесс Гость ждёт завершения операций хранения, выполняемых гипервизором

Вопрос 3 из 20

Как найти процесс, создающий всплески CPU каждые пять секунд?

pidstat -u -p ALL 1 30

Очистить файловый кэш, чтобы исключить влияние чтения с диска Сравнить только 15-минутную load average до и после всплеска Запустить pidstat -u с коротким интервалом и захватить несколько циклов Снять один снимок top между всплесками и отсортировать по памяти

Вопрос 4 из 20

Высокий %system и много context switches. Какой следующий шаг разумен?

pidstat -w -p ALL 1
perf top

Сравнить только долю user CPU, не исследуя системные вызовы Снизить nice процесса, который уже почти не использует CPU Увеличить swap и повторить измерение переключений контекста Локализовать процессы через pidstat -w, perf и при необходимости strace

Вопрос 5 из 20

Почему nice не гарантирует процессу фиксированную долю CPU?

Это относительный вес обычного планировщика, а не жёсткая квота процессорного времени Nice задаёт только приоритет операций ввода-вывода, но не CPU Nice ограничивает процесс указанным числом процентов одного CPU Значение применяется лишь при отсутствии других готовых процессов

Вопрос 6 из 20

free показывает мало в колонке free, но MemAvailable велик. Есть ли обязательно нехватка памяти?

free -h
grep -E 'MemFree|MemAvailable|Cached|Swap' /proc/meminfo

Нет только потому, что swap отключён Нет: память доступна за счёт возвращаемого кэша MemAvailable оценивает только swap и при его отключении близок к нулю Да, Linux обязан держать 90% RAM полностью пустой

Вопрос 7 из 20

Что опаснее для задержек: единичное использование swap или постоянный поток major page faults и swap-in?

Постоянные fault/swap-in, указывающие на давление и ожидание диска Наличие tmpfs Большой объём давно неактивных страниц, оставшихся в swap Большой page cache

Вопрос 8 из 20

Процесс растёт по RSS на 50 МиБ в час при постоянной нагрузке. Что лучше сделать?

pidstat -r -p "$pid" 60
pmap -x "$pid" | tail -n 1

Повысить приоритет процесса, чтобы сборщик памяти работал быстрее Снять временной ряд RSS и профиль распределения памяти процесса Перезапускать процесс по расписанию без измерения источника роста Очищать кэш страниц каждый час и считать рост устранённым

Вопрос 9 из 20

Почему echo 3 > /proc/sys/vm/drop_caches не является обычной оптимизацией?

Эффект команды сохраняется после перезагрузки системы Команда освобождает анонимную память работающих приложений Команда освобождает кэш без влияния на последующие чтения Удаление кэша может ухудшить ввод-вывод

Вопрос 10 из 20

Служба убита при MemoryCurrent 900M и MemoryMax 1G, хотя в системе свободно 20G. Почему?

systemctl show app.service -p MemoryCurrent -p MemoryMax
cat /sys/fs/cgroup/system.slice/app.service/memory.events

Free показывает неправильные гигабайты OOM выбирает процесс с наибольшим RSS во всей системе, не учитывая cgroup Сработал cgroup-лимит службы, независимый от общего объёма памяти MemoryMax относится к диску

Вопрос 11 из 20

В iostat устройство имеет await 80ms, очередь растёт, приложение ждёт fsync. Что вероятнее?

iostat -xz 1
pidstat -d -p ALL 1

Устройство быстро обрабатывает запросы, а await растёт из-за DNS-ожидания Подсистема хранения не выдерживает требуемую задержку синхронных операций Высокая очередь объясняется только числом процессорных потоков приложения fsync ждёт подтверждения удалённого TCP-узла, а не локального хранилища

Вопрос 12 из 20

Почему %util близкий к 100% на современном многоканальном NVMe нельзя читать так же просто, как на одном HDD?

%util показывает долю занятых аппаратных каналов NVMe NVMe не имеет операций ввода-вывода 100% означает свободный диск Нужны latency, queue и throughput в контексте

Вопрос 13 из 20

Как найти процесс, который пишет больше всего на диск в момент проблемы?

sudo pidstat -d -p ALL 1
sudo iotop -oPa

Посмотреть накопительный счётчик записанных байтов после завершения сбоя Отсортировать процессы по RSS и считать первый процесс источником записи Снять pidstat -d или iotop именно во время проблемы Сравнить df -h до и после всплеска записи

Вопрос 14 из 20

Почему большое свободное место не гарантирует быстрый диск?

Пустой том исключает очередь запросов и задержку fsync Ёмкость диска не определяет задержку операций Большой запас блоков снижает только время поиска свободного inode Свободное место влияет на скорость лишь при последовательном чтении

Вопрос 15 из 20

Что помогает отличить медленное приложение от медленного storage в запросе?

# приложение: request_time, db_time
# БД: wait_event
# ОС: iostat/pidstat с теми же timestamps

Отключить журналирование приложения и сравнить субъективную скорость Увеличить тайм-аут запроса, не измеряя, на каком этапе возникла задержка Сравнить только load average и число процессов за последние сутки Сопоставить время этапов приложения, ожидание хранилища и метрики ввода-вывода

Вопрос 16 из 20

Что означает рост TCP retransmissions при стабильной нагрузке?

nstat -az | grep -E 'TcpRetransSegs|TcpTimeouts'
ss -ti dst 203.0.113.8

Резолвер обновляет DNS-запись при каждом TCP-повторе Процессор чаще переходит в idle и поэтому TCP повторяет сегменты На пути растут потери, задержки или переупорядочивание подтверждений Приложение стало чаще попадать в локальный кэш ответов

Вопрос 17 из 20

Интерфейс показывает rx_dropped. Что проверить?

Сравнить только число установленных TCP-соединений Проверить счётчики очередей, драйвера и уровень, где теряются пакеты Увеличить MTU, не проверяя ошибки и размер кадров Перезапустить сетевую службу, не снимая счётчики до и после

Вопрос 18 из 20

Много соединений в SYN-RECV и accept queue переполнена. Что это может означать?

ss -lnt 'sport = :443'
ss -nt state syn-recv 'sport = :443' | wc -l

Сервер или его очередь не успевают завершать рукопожатия либо идёт SYN-флуд Порт закрыт, поэтому ядро сохраняет входящие SYN до открытия сокета Очередь дискового планировщика переполнена операциями accept Все клиенты завершили рукопожатие, но приложение не успевает читать запросы

Вопрос 19 из 20

Почему высокая пропускная способность speedtest не исключает сетевую проблему приложения?

Для коротких запросов пропускная способность важнее RTT и потерь Speedtest идёт тем же маршрутом, поэтому проблема возможна только на сервере приложения Рабочий маршрут и характер трафика могут отличаться Высокая скорость означает отсутствие потерь и очередей на рабочем маршруте

Вопрос 20 из 20

Как различить медленный upstream и задержку самого Nginx?

# log_format содержит:
$request_time $upstream_connect_time $upstream_response_time

Сравнить время процесса Nginx по ps с временем жизни upstream Сравнить только HTTP-код ответа для быстрых и медленных запросов Сопоставить $request_time и $upstream_response_time для одного запроса Отключить access log и повторить запрос без временных метрик

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу