Перейти к основному содержимому

1.14. Троттлинг, тормоза и зависания

ДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ
Всем

Троттлинг, тормоза и зависания​

Цифровые системы — от смартфона до облачного кластера — функционируют в условиях постоянного баланса между вычислительной нагрузкой, энергопотреблением, тепловыделением и ресурсной доступностью. Когда одна из этих величин выходит за пределы допустимых границ, система вступает в состояние замедления. Замедление проявляется в трёх основных формах:

  1. Троттлинг — контролируемое, автоматическое снижение производительности аппаратных компонентов с целью сохранения их работоспособности;
  2. Тормоза — субъективно ощущаемые задержки отклика интерфейса, вызванные ресурсными узкими местами на уровне программного или системного взаимодействия;
  3. Зависания — частичная или полная потеря прогресса в выполнении задачи, приводящая к отсутствию реакции на входные воздействия.

Эти явления не являются сбоями в классическом смысле. Они — следствие естественных ограничений физических законов (например, теплопередачи), архитектурных компромиссов (например, плотная компоновка в мобильных устройствах) и алгоритмических решений (например, приоритизация критических процессов в ядре ОС). Понимание их природы требует рассмотрения как аппаратного, так и программного стека — от кристалла микросхемы до драйверов и планировщиков задач.

Троттлинг​

Троттлинг — механизм адаптивного управления производительностью, встроенный в современные процессоры (CPU), графические ускорители (GPU), чипсеты (SoC) и даже некоторые контроллеры памяти и накопителей. Его главная цель — поддержание теплового режима в пределах, установленных производителем, без отключения питания.

Тепловыделение — неизбежное следствие электрической активности транзисторов. При каждом переключении состояния (от 0 к 1 или обратно) часть энергии рассеивается в виде тепла. Чем выше тактовая частота и напряжение питания, тем больше коммутационных событий в единицу времени и тем выше выделяемая мощность. В условиях ограниченного теплоотвода (например, в корпусе ноутбука толщиной 14 мм) температура кристалла может достичь критических значений — 95–105°C — за несколько секунд интенсивной работы.

Для предотвращения термического повреждения (деградации полупроводниковой структуры, отслоения кристалла от подложки, плавления припоя) в кремниевые чипы интегрируются цифровые термодатчики (Digital Thermal Sensors, DTS). Они измеряют температуру в ключевых зонах — ядрах, кэше, контроллере памяти — с точностью до долей градуса и частотой до нескольких тысяч измерений в секунду. Эти данные поступают в термальный менеджер — аппаратно-программный блок, реализованный как часть микрокода (microcode) процессора или встроенной управляющей микросхемы (например, PMIC в SoC).

Когда температура превышает пороговое значение (обычно 85–95°C для потребительских устройств), термальный менеджер инициирует динамическое снижение частоты (dynamic frequency scaling) и снижение напряжения (dynamic voltage scaling). Это совместное действие известно как DVFS (Dynamic Voltage and Frequency Scaling). Частота тактового генератора уменьшается ступенчато — от максимальной (например, 4,5 ГГц) к промежуточным (3,2 ГГц, 2,0 ГГц) и, при необходимости, к минимальной (800 МГц). Напряжение питания ядер также снижается, так как требуемое напряжение возрастает нелинейно с ростом частоты. Эффект оказывается двойным:

  • тепловыделение уменьшается пропорционально квадрату напряжения и линейно — частоте (P ∝ V²·f), что даёт резкое падение нагрева;
  • производительность падает, но не катастрофически — система остаётся работоспособной.

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

Профили троттлинга в зависимости от платформы​

На персональных компьютерах с дискретной графикой и активным охлаждением троттлинг CPU встречается редко — при условии исправной системы охлаждения. Однако GPU высокопроизводительных видеокарт (например, серии NVIDIA GeForce RTX) могут входить в троттлинг уже при длительной нагрузке в 4K-играх, особенно если корпус плохо вентилируется. Интеллектуальные кулеры в таких картах работают в двух режимах:

  • Режим тишины — при низкой нагрузке кулер остаётся неподвижным;
  • Активный режим — при достижении заданной температуры кулер раскручивается, а при превышении второго порога (например, 83°C) включается троттлинг.

Для пользователей это проявляется как нелинейное снижение FPS: игра стартует с 90 кадров в секунду, через 2 минуты плавно опускается до 50–55, затем стабилизируется — система нашла равновесие между нагревом и охлаждением.

В ноутбуках троттлинг — повседневная реальность. Тонкие корпуса, ограниченные радиаторы, совмещённые CPU-GPU с общим теплотрубным модулем — всё это сужает окно «термального запаса». Даже средняя нагрузка (например, компиляция проекта в Visual Studio или одновременная работа браузера с 20 вкладками и видеоконференции) может вызвать кратковременный троттлинг. Особенно выражено это в моделях с пассивным охлаждением (без вентиляторов) или с одним вентилятором, обслуживающим оба чипа. Здесь троттлинг может происходить циклически: частота растёт до пика — температура поднимается — частота падает — система охлаждается — частота снова растёт. Человек ощущает это как пульсирующие тормоза.

В смартфонах и планшетах троттлинг носит более агрессивный характер. Мощные SoC (Snapdragon 8 Gen, Apple A-серия, MediaTek Dimensity) размещены в алюминиевом или стеклянном корпусе без активного охлаждения. Тепло распространяется по корпусу, нагревая и саму платформу, и руку пользователя. Производители устанавливают строгие лимиты:

  • Apple ограничивает длительную производительность чипов A15–A17 Pro примерно до 60–65% от пикового значения для сохранения температуры корпуса ниже 45°C;
  • Qualcomm и Samsung применяют многоступенчатые профили — например, в течение первых 10 секунд разрешается работа на 100% мощности, затем — 75%, через 30 секунд — 50%, и далее — до 30%.

Результат — падение производительности в бенчмарках при повторных запусках. Первый прогон AnTuTu показывает 1,2 млн баллов, второй — 850 тыс., третий — 720 тыс. Это не «недоработка», а расчётная стратегия: система гарантирует, что пользователь не получит ожог от корпуса и что аккумулятор не подвергнется ускоренному старению из-за высокой температуры.

На серверном уровне термин throttling приобретает иное значение — ограничение скорости запросов. Серверные процессоры (Intel Xeon, AMD EPYC) тоже поддерживают термальный троттлинг, но он редко активируется благодаря мощным системам воздушного или жидкостного охлаждения в дата-центрах. Гораздо чаще троттлинг применяется на уровне программного стека: API-шлюзы (например, Kong, Apigee), облачные платформы (AWS API Gateway, Azure API Management) и веб-серверы (Nginx с модулем limit_req) реализуют rate limiting — контроль числа входящих запросов в единицу времени от одного клиента или группы.

Такое ограничение защищает сервис от перегрузки при всплеске трафика, будь то легитимный рост аудитории или попытка атаки типа отказ в обслуживании (DoS). Механизмы включают:

  • Токен-бакет (token bucket) — клиенту выдаётся квота «токенов» на определённый период; каждый запрос тратит один токен;
  • Скользящее окно (sliding window) — подсчёт запросов за последние N секунд с плавным обновлением;
  • Фиксированное окно (fixed window) — счётчик сбрасывается каждую минуту/секунду.

При превышении лимита сервер возвращает код 429 Too Many Requests, а не отказывает в обслуживании полностью. Это даёт клиенту шанс адаптироваться — замедлить запросы, включить обратное давление (backpressure), применить повторные попытки с экспоненциальной задержкой. Такой троттлинг — неотъемлемая часть устойчивой архитектуры распределённых систем.

Причины и проявления троттлинга​

Троттлинг — следствие цепочки событий, начинающейся с нарушения теплового баланса. Тепловой баланс описывает равенство между теплом, выделяемым компонентом, и теплом, отводимым в окружающую среду. Если первое превышает второе, температура растёт.

Основные факторы, нарушающие баланс:

  • Механическая изоляция теплоотвода — скопление пыли в радиаторах и вентиляционных отверстиях создаёт термоизоляционный слой. Пыль имеет низкую теплопроводность (0,03–0,06 Вт/(м·К)), сравнимую с пенопластом. Даже 2–3 мм слоя могут увеличить термическое сопротивление на 30–50%.
  • Недостаток воздухообмена — размещение ноутбука на мягкой поверхности (одеяло, подушка, колени) перекрывает заборные отверстия. В ноутбуках воздух обычно втягивается снизу или с боков, а выдувается сзади. Блокировка входа приводит к рециркуляции горячего воздуха внутри корпуса.
  • Высокая фоновая нагрузка — работа фоновых процессов (антивирус, облачные синхронизаторы, майнеры) увеличивает базовую нагрузку на CPU. При запуске игры или рендеринга система достигает порога троттлинга быстрее.
  • Деградация термоинтерфейса — термопаста между кристаллом и радиатором со временем высыхает, трескается, теряет однородность. Её теплопроводность падает с начальных 5–12 Вт/(м·К) до 1–2 Вт/(м·К), что эквивалентно замене меди на дерево в тепловой цепи.
  • Атмосферные условия — высокая температура окружающей среды (выше 30°C) и высокая влажность снижают эффективность конвективного охлаждения. В жарком климате троттлинг может начинаться при меньшей нагрузке.

Пользовательские проявления троттлинга подразделяются на три категории:

  1. Сенсорные сигналы — повышение температуры корпуса (локально — над процессором или GPU), шум вентиляторов (переход на максимальные обороты), вибрация от балансировки крыльчатки.
  2. Поведенческие симптомы — замедление отклика интерфейса, просадка кадровой частоты в играх, увеличение времени выполнения операций (архивация, компиляция, экспорт видео).
  3. Измеряемые параметры — резкое падение тактовой частоты (с 4,2 ГГц до 2,1 ГГц), стабилизация температуры в узком диапазоне (например, 87±1°C), снижение энергопотребления (с 65 Вт до 30 Вт у CPU).

Важно: троттлинг — адаптивный процесс. Он не приводит к полной остановке. Система стремится к динамическому равновесию: частота снижается до уровня, при котором выделяемое тепло = отводимое тепло. Это состояние может сохраняться неограниченно долго — устройство работает медленнее, но безопасно.

Где встречается троттлинг​

УровеньПримерыМеханизмЦель
МикроархитектураIntel Speed Shift, AMD Cool’n’Quiet, ARM big.LITTLE DVFSИзменение частоты и напряжения ядер в реальном времениЗащита кристалла, снижение энергопотребления
ПлатформаНоутбуки, ультрабуки, игровые консоли (PS5, Xbox Series X)Координация CPU, GPU, памяти через встроенный контроллер (PCH, PMU)Баланс производительности и тепловыделения в компактном корпусе
Мобильные устройстваСмартфоны, планшеты, AR/VR-очкиОграничение пиковой мощности SoC, динамическое отключение ядерСохранение комфорта пользователя и долговечности аккумулятора
Сетевые сервисыВеб-API, облачные функции (AWS Lambda, Azure Functions), базы данных (Redis rate limiting)Ограничение RPS (requests per second) на уровне шлюза или приложенияПредотвращение перегрузки, обеспечение справедливого распределения ресурсов
ХранилищаSSD с термальным троттлингом (например, Samsung 980 Pro), NAS-устройстваСнижение скорости записи при нагреве NAND-чиповЗащита от ошибок записи и потери данных при высоких температурах

Особое внимание заслуживает тандемный троттлинг — одновременное ограничение нескольких компонентов. Например, в ноутбуке при игре CPU и GPU подключены к общему радиатору. Если GPU начинает троттлить, его температура падает, но CPU продолжает нагревать общий теплообменник. Через некоторое время CPU тоже достигает порога и снижает частоту. В результате оба компонента работают на 60% мощности вместо того, чтобы один — на 90%, другой — на 30%. Это не ошибка распределения, а следствие физической связанности.

Тормоза​

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

Порог комфорта определяется физиологией человека:

  • задержка до 100 миллисекунд воспринимается как мгновенная;
  • от 100 до 300 миллисекунд — как ощутимая, но терпимая пауза;
  • свыше 300 миллисекунд — как прерывание потока внимания, требующее когнитивной перезагрузки.

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

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

Цепочка событий​

Рассмотрим типичный сценарий — прокрутка веб-страницы колёсиком мыши. Кажущаяся простота скрывает многоступенчатую обработку:

  1. Физический ввод — вращение колёсика генерирует импульсы в оптическом или механическом энкодере мыши. Задержка здесь минимальна (1–2 мс), но может возрастать при низкой частоте опроса (polling rate) USB-устройства. Мышь с частотой 125 Гц сообщает о положении 8 раз в секунду — каждые 8 мс; с 1000 Гц — каждые 1 мс. Разница неощутима в офисных задачах, но критична при быстрой прокрутке.

  2. Передача в ОС — сигнал поступает через драйвер ввода, попадает в очередь событий ядра. Если система перегружена фоновыми задачами, очередь может накапливать события — возникает входная задержка (input lag).

  3. Обработка в пользовательском пространстве — событие передаётся браузеру. Ядро браузера (например, Chromium) распределяет его между потоками:

    • UI-поток отвечает за отрисовку интерфейса и реакцию на события;
    • рендер-поток — за построение визуального дерева;
    • рабочие потоки — за выполнение JavaScript, декодирование изображений.
      Если UI-поток занят (например, выполняет тяжёлый JavaScript-цикл без await), он не может обработать событие прокрутки сразу — задержка растёт.

  4. Генерация кадра — браузер формирует новое изображение страницы. Это включает:

    • пересчёт стилей (CSS cascade);
    • перестроение геометрии элементов (layout/reflow);
    • перерисовку пикселей (paint);
    • компоновку слоёв (compositing).
      Любая из этих операций может занять десятки миллисекунд, особенно если на странице много анимаций, теней, фильтров или неоптимизированных скриптов.

  5. Передача на GPU — сформированный кадр передаётся видеодрайверу, который отправляет его в видеопамять и планирует вывод на экран. Если GPU перегружен (например, отрисовывает 3D-сцену в соседней вкладке), он может не успеть обработать кадр к следующему вертикальному развёртыванию (VSync), и кадр пропускается — падает частота кадров.

  6. Отображение — дисплей обновляется с фиксированной частотой (60 Гц = каждые 16,7 мс; 144 Гц = каждые 6,9 мс). Если кадр не готов к моменту развёртывания, экран показывает предыдущий — возникает заикание (stutter).

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

Основные источники временных узких мест​

1. Конкуренция за оперативную память
Оперативная память (RAM) — быстрый, но ограниченный ресурс. Когда приложений запущено много, а объём RAM близок к исчерпанию, система переходит к использованию подкачки (swap/pagefile) — части диска, эмулирующей память. Чтение/запись на SSD занимает 50–150 мкс, на HDD — 5–15 мс. Это в тысячи раз медленнее, чем прямой доступ к RAM (10–100 нс).

Даже один процесс, активно читающий из подкачки, может вызывать ощутимые тормоза во всей системе — ядро ОС вынуждено приостанавливать другие процессы на время ожидания данных с диска. Особенно заметно это при переключении между приложениями: первое открытие окна после долгого бездействия «подвисает» на 1–2 секунды — данные подгружаются с диска.

2. Блокировки ввода-вывода (I/O contention)
Диск — общий ресурс. Все процессы, нуждающиеся в чтении или записи (браузер — кэш, антивирус — сканирование, облачный клиент — синхронизация, игра — загрузка текстур), конкурируют за доступ к нему.

Даже на SSD очередь команд может накапливаться. Контроллер диска обрабатывает запросы по приоритету и алгоритму планирования (например, deadline или CFQ в Linux). Если в очереди много мелких случайных операций (typical for database workloads), пропускная способность падает, а задержка растёт. Пользователь замечает это как «тормоза при сохранении файла» или «лаг при открытии папки с фотографиями».

3. Непрерывная фоновая активность
Современные ОС поддерживают сотни фоновых процессов: обновления, индексация поиска, сбор телеметрии, синхронизация. Большинство из них работают с низким приоритетом и не мешают интерактивным задачам. Однако некоторые:

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

Такие процессы могут временно захватывать CPU, диск или сеть, вызывая кратковременные, но повторяющиеся тормоза.

4. Проблемы с драйверами и прошивками
Драйвер — посредник между ОС и аппаратным компонентом. Некачественный или устаревший драйвер:

  • вводит дополнительные задержки при обработке прерываний;
  • не использует аппаратное ускорение (например, оставляет декодирование видео на CPU вместо GPU);
  • содержит ошибки синхронизации, приводящие к блокировкам.

Особенно критичны драйверы для:

  • графики (влияют на частоту кадров и отрисовку интерфейса);
  • чипсета (контролируют работу шины PCIe, SATA, USB — замедление здесь влияет на все периферийные устройства);
  • Wi-Fi/Bluetooth (могут вызывать задержки ввода при использовании беспровроводной мыши/клавиатуры).

5. Сетевые задержки (в контексте локальных систем)
Даже при работе с локальными приложениями сетевые компоненты могут участвовать:

  • браузер проверяет сертификаты через OCSP-запросы;
  • облачные клиенты синхронизируют состояние;
  • лицензионные системы (например, Adobe, JetBrains) периодически «звонят домой»;
  • корпоративные политики требуют аутентификации через домен.

Если сервер отвечает медленно или недоступен, приложение может ждать таймаута (часто 30 секунд), блокируя интерфейс. Такое поведение — признак плохой архитектуры (отсутствие асинхронности), но пользователь воспринимает его как «тормоз».

6. Визуальная сложность интерфейса
Современные графические интерфейсы строятся на наложении полупрозрачных слоёв, анимаций, теней, размытий. Каждая такая операция требует вычислений:

  • альфа-смешение (blending) — комбинирование цветов с учётом прозрачности;
  • гауссово размытие — свёртка изображения с ядром фильтра;
  • трансформации (поворот, масштабирование) — матричные операции.

Если GPU не справляется с объёмом вычислений, он начинает пропускать кадры. Интерфейс выглядит «дрогнувшим», прокрутка — «рваной». Это не троттлинг, а недостаток вычислительной мощности для текущей визуальной нагрузки.

Тормоза в разных сценариях использования​

СценарийТипичные источники тормозовОжидаемое поведение
Работа с текстом в редактореПодсветка синтаксиса на больших файлах, автодополнение, проверка орфографии, фоновая компиляцияЗадержка при печати, «отскакивание» курсора, подвисание при сохранении
Просмотр веб-страницJavaScript-реклама, автовоспроизведение видео, трекеры аналитики, медленные сторонние скриптыЛаг при прокрутке, задержка отклика на клик, «подёргивание» при анимациях
ВидеоконференцияДекодирование видео высокого разрешения, захват микрофона/камеры, сеть, фоновая заменаЗамедление интерфейса при переключении окон, дрожание изображения, эхо
Игры (не на пределе GPU)Физика, ИИ, загрузка уровней, синхронизация с серверомФризы при входе в новую зону, подвисания при большом числе объектов
Работа с базами данныхБлокировки транзакций, полнотекстовый поиск, отсутствие индексов«Заморозка» интерфейса при выполнении запроса, долгая загрузка отчётов

Заметим: тормоза часто циклические. Например, каждые 5 минут запускается индексация поиска — и система на 3 секунды «подвисает». Это не случайность, а признак регулярного фонового процесса.

Отличие тормозов от троттлинга и зависаний​

Тормоза — частичное, временное снижение отзывчивости. Система продолжает функционировать, но с увеличенной задержкой.

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

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

Зависание​

Зависание — состояние вычислительной системы, при котором одна или несколько задач не совершают прогресса в своём исполнении в течение времени, значительно превышающего ожидаемое.

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

  • повторяет одни и те же операции без изменения внешнего состояния (например, постоянно проверяет условие, которое никогда не станет истинным);
  • ожидает события, которое не произойдёт (например, ответа от недоступного сервера без таймаута);
  • заблокирован в ожидании ресурса, удерживаемого другим зависшим компонентом.

Зависание — не сбой. Сбой (crash) предполагает аварийное завершение с генерацией исключения, дампа памяти или перезагрузки. При зависании процесс формально остаётся работающим: он потребляет ресурсы (CPU, RAM), присутствует в списке задач, но не приближается к завершению.

Ключевой признак зависания — отсутствие реакции на внешние стимулы, предназначенных для изменения состояния:

  • нажатие кнопок в интерфейсе;
  • сигналы от операционной системы (например, SIGTERM);
  • таймерные прерывания.

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

Классификация зависаний по уровню системы​

1. Зависание отдельного процесса​

Наиболее частый случай. Пользователь видит:

  • окно приложения не реагирует на клики, изменение размера, закрытие;
  • в диспетчере задач статус — «Не отвечает»;
  • потребление CPU может быть высоким (бесконечный цикл) или нулевым (ожидание без таймаута).

Типичные причины:

  • Бесконечный цикл — ошибка в условии завершения (while (true) без break, рекурсия без базового случая);
  • Блокировка ввода-вывода — ожидание ответа от устройства (сетевого, дискового), которое не отвечает (например, зависший SSH-сервер, отключённый USB-диск);
  • Взаимная блокировка (deadlock) — два или более потока ожидают освобождения ресурсов, удерживаемых друг другом. Пример:
    • Поток A захватил ресурс X и ждёт освобождения Y;
    • Поток B захватил ресурс Y и ждёт освобождения X;
    • Ни один из потоков не может продолжить работу.
  • Голодание (starvation) — поток постоянно лишается доступа к ресурсу из-за более приоритетных задач. Например, низкоприоритетный поток никогда не получает CPU, потому что системные сервисы всегда активны.

Зависание процесса не влияет на остальную систему. ОС продолжает работать, другие приложения — отвечать. Пользователь может принудительно завершить зависший процесс.

2. Зависание потока в многопоточном приложении​

Более тонкий случай. Всё приложение не «виснет», но отдельная функция не завершается:

  • кнопка «Сохранить» не даёт результата, но интерфейс остаётся активным;
  • фоновая загрузка «застряла» на 99%;
  • анимация воспроизводится, но логика ИИ в игре перестала обновляться.

Это происходит, когда:

  • поток, выполняющий критическую операцию, заблокирован, а UI-поток работает независимо;
  • отсутствует механизм обратной связи (например, progress bar не обновляется, потому что поток завис до отправки первого отчёта).

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

3. Зависание ядра операционной системы​

Критическое состояние. Проявляется как:

  • полная потеря реакции на любые действия: клавиатура, мышь, сетевые запросы;
  • застывшее изображение на экране;
  • вентиляторы продолжают работать (питание подаётся), но индикаторы активности диска/сети не мигают.

Причины:

  • Deadlock в ядре — взаимная блокировка между драйверами или подсистемами ядра (например, файловая система ждёт сетевой драйвер, сетевой — файловую);
  • Повреждение структур ядра — запись в защищённую область памяти (например, из-за ошибки в драйвере), приводящая к неконсистентному состоянию;
  • Аппаратный сбой с потерей управления — отказ контроллера прерываний (APIC), повреждение микрокода CPU.

В современных ОС ядро изолировано от пользовательских процессов. Зависание ядра — редкое событие, требующее глубокого вмешательства в низкоуровневые компоненты. Оно не разрешается автоматически — требуется перезагрузка.

4. Частичное зависание (soft hang)​

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

  • сохранением реакции на некоторые команды;
  • крайне медленным, но ненулевым прогрессом.

Примеры:

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

Причины:

  • Сильная перегрузка CPU — 100% загрузка всеми ядрами, но без блокировок. Планировщик всё ещё переключает задачи, но каждая получает микроскопическую квоту времени;
  • Деградация диска — SSD/HDD с физическими повреждениями, выполняющий повторные попытки чтения/записи (retries), что блокирует I/O-подсистему на сотни миллисекунд за операцию;
  • Повреждение памяти — ошибки ECC-контроля, заставляющие систему повторно читать данные или перезагружать страницы.

Частичное зависание может длиться долго — система «живёт», но непригодна для работы.

5. Аппаратное зависание (hardware hang)​

Полная потеря управления на уровне микроконтроллеров. Проявляется как:

  • отсутствие реакции даже на аппаратные комбинации (Ctrl+Alt+Del, кнопка Reset);
  • необходимость отключения питания (удержание кнопки питания 5+ секунд);
  • в некоторых случаях — автоматическая перезагрузка через watchdog-таймер.

Причины:

  • Перегрев с выходом за пределы троттлинга — температура достигает уровня, при котором транзисторы теряют способность переключаться (thermal shutdown);
  • Просадка напряжения питания — блок питания не выдерживает пиковой нагрузки, напряжение на шине 12 В падает ниже 10,5 В, и цифровые схемы перестают функционировать корректно;
  • Физическое повреждение компонентов — трещина в плате, отслоение BGA-чипа, коррозия контактов.

Аппаратное зависание — финальная стадия отказа. Оно не поддаётся программной диагностике и требует вмешательства на физическом уровне.

Типовые программные причины зависаний​

Бесконечные циклы без условия выхода​

Простейшая ошибка, особенно в рекурсивных алгоритмах или циклах с изменяющимися условиями. Пример:

int i = 0;  
while (i != 10) {  
    // ...  
    i += 2; // i примет значения 0, 2, 4, 6, 8, 10, 12... — никогда не станет 10, если начальное значение нечётное  
}

Если условие никогда не выполнится, цикл не завершится. В однопоточном приложении это приводит к полному зависанию интерфейса.

Взаимная блокировка (deadlock)​

Возникает при строгом соблюдении четырёх условий:

  1. Взаимное исключение — ресурс может быть использован только одним потоком;
  2. Удержание и ожидание — поток удерживает один ресурс и запрашивает другой;
  3. Отсутствие вытеснения — ресурсы нельзя отобрать принудительно;
  4. Круговое ожидание — цепочка потоков, каждый из которых ожидает ресурс у следующего.

Deadlock не разрешается сам по себе. Требуется внешнее вмешательство:

  • таймаут ожидания (попытка захвата с try_lock);
  • иерархия ресурсов (все потоки захватывают ресурсы в одном порядке);
  • детектор deadlock’ов в ОС (например, в Windows используется механизм Wait Chain Traversal).

Livelock​

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

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

Потоки не заблокированы, CPU загружен на 100%, но задача не решается. Livelock сложнее обнаружить, чем deadlock, так как система «выглядит живой».

Повреждение памяти (memory corruption)​

Запись за пределы выделенного буфера (buffer overflow), использование освобождённой памяти (use-after-free), гонки данных (data races) могут привести к:

  • изменению указателей на функции;
  • повреждению структур управления памятью (heap metadata);
  • некорректному поведению планировщика.

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

Ошибки в драйверах и микропрограммах​

Драйвер работает в привилегированном режиме (ring 0). Его ошибка может:

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

Особенно опасны драйверы для:

  • чипсета (управляют шинами PCIe, SATA);
  • графики (имеют прямой доступ к видеопамяти и дисплейному контроллеру);
  • сетевых адаптеров (могут вызывать зависание при обработке malformed-пакетов).

Диагностика зависаний​

ПризнакВозможная причинаУровень локализации
Курсор мыши двигается, окна перетаскиваются, но интерфейс приложений не реагируетЗависание пользовательских процессов; ядро и драйверы ввода работаютПользовательское пространство
Курсор «завис», но звук продолжает играть (музыка, системные события)Зависание графической подсистемы (драйвер GPU, compositor); звуковая подсистема работает независимоДрайвер/подсистема ядра
Все индикаторы (клавиатура CapsLock, NumLock) не реагируют на переключениеЗависание ядра или низкоуровневого контроллера вводаЯдро / аппаратный контроллер
Экран «застыл», но вентиляторы работают на полную мощностьCPU в бесконечном цикле без троттлинга; возможна ошибка в коде, не учитывающая температуруПроцесс / ядро
Экран погас, вентиляторы остановились, но питание есть (индикаторы на корпусе горят)Аппаратный watchdog сработал; возможен thermal shutdownАппаратный уровень
Система реагирует на Magic SysRq (Alt+SysRq+команда), но не на обычные командыЯдро частично работоспособно; пользовательские процессы заблокированыЯдро в состоянии soft hang

Magic SysRq (в Linux) — мощный инструмент диагностики. Комбинации вроде Alt+SysRq+t выводят список задач, Alt+SysRq+w — цепочки ожидания (wait chains), что позволяет выявить deadlock без перезагрузки.

Зависания в распределённых системах​

В облачных и сетевых средах зависание приобретает новые формы:

  • Сетевой partition — потеря связи между узлами кластера. Узел, отрезанный от кворума, может «зависнуть» в ожидании ответа, не зная, что сеть разорвана;
  • Распределённый deadlock — deadlock, охватывающий несколько машин через RPC-вызовы;
  • Таймауты без fallback — сервис ждёт ответа от другого сервиса, но не имеет механизма повтора или перехода в degrade-режим.

В таких системах зависание одного компонента может каскадно распространиться на другие через цепочки зависимостей — явление, известное как cascading failure.

Диагностика: от наблюдения к интерпретации​

Диагностика — процесс установления причинного механизма по внешним признакам. Он строится по принципу иерархического исключения: сначала проверяются наиболее вероятные и легко выявляемые причины, затем — более глубокие.

Этап 1. Классификация явления​

Первый вопрос: что именно происходит?

  • Если устройство равномерно медленное, а температура стабильно высокая (85–95°C) — это троттлинг.
  • Если задержки непостоянны, возникают эпизодически и сопровождаются всплесками загрузки CPU/диска — это тормоза.
  • Если отсутствует реакция на действия в течение >10 секунд, при этом не помогают стандартные комбинации (Alt+Tab, Ctrl+Shift+Esc) — это зависание.

Эта классификация определяет направление дальнейшего анализа.

Этап 2. Определение уровня локализации​

Вопрос: на каком уровне системы нарушена работа?

Наблюдаемое поведениеУровеньИнструменты диагностики
Только одно приложение «не отвечает», остальные работаютПользовательский процессДиспетчер задач (Windows), htop/top (Linux), Activity Monitor (macOS); lsof, strace для деталей
Несколько приложений тормозят, но мышь и звук работаютПодсистема (диск, сеть, графика)Мониторинг I/O (iostat, iotop), сетевой трафик (nethogs, Wireshark), GPU-нагрузка (GPU-Z, nvtop)
Интерфейс «застыл», но реакция на Magic SysRq или SysRq-команды естьЯдро ОС (soft hang)Ядерные логи (dmesg, /var/log/kern.log), дампы стека (/proc/kcore, crash utility)
Полное отсутствие реакции, включая индикаторы клавиатурыАппаратный уровеньВнешние признаки (температура корпуса, шум вентиляторов), POST-коды при перезагрузке, аппаратные диагностические утилиты (MemTest86, UEFI Diagnostics)

Важно: отсутствие данных — тоже данные. Если мониторинг показывает 0% загрузки CPU, 0 МБ/с диска, 0 пакетов/с сети — система не перегружена. Зависание вызвано блокировкой, а не нехваткой ресурсов.

Этап 3. Сбор измеримых параметров​

Качественные описания («тормозит», «гудит») дополняются количественными:

  • Температура — CPU, GPU, SSD, SoC. Пороги:

    • < 70°C — нормальная работа;
    • 70–85°C — повышение, но безопасно;
    • > 85°C — активация троттлинга вероятна.
      Инструменты: Core Temp, HWiNFO, sensors (Linux), AIDA64, встроенные утилиты в BIOS/UEFI.

  • Частота — текущая тактовая частота ядер, GPU. Сравнение с базовой и турбо-частотой показывает, насколько сильно снижена производительность.

  • Загрузка по компонентам — CPU (в %), RAM (в ГБ), диск (чтение/запись в МБ/с и IOPS), сеть (передача/приём в Мбит/с).

  • Время отклика — latency диска (iostat -x 1 → await), сетевой пинг, задержка кадра (frametime в играх).

  • Состояние очередей — длина очереди дисковых операций (avgqu-sz), сетевых пакетов (netstat -s), задач в планировщике (vmstat 1 → r column).

Эти параметры позволяют перейти от субъективных ощущений к объективной картине.

Этап 4. Корреляция событий​

Современные системы генерируют события:

  • запись в журнал ядра при входе в троттлинг (CPU clock throttled);
  • сообщение о deadlock в логах приложения (Deadlock detected between thread A and B);
  • ошибка таймаута диска (I/O timeout on /dev/sda).

Связывание временных меток из разных источников (systemd journal, application logs, hardware sensors) даёт полную цепочку:
[12:05:03] Запуск игры → [12:05:07] Температура GPU 88°C → [12:05:08] Частота GPU снижена с 1800 МГц до 1200 МГц → [12:05:09] FPS упал с 92 до 54

Это не «случайность» — это причинно-следственная связь.