«Тормозит система»: как найти и устранить узкие места в ИТ‑инфраструктуре

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

Что такое bottleneck и почему это не всегда CPU

Bottleneck («бутылочное горлышко») — явление, при котором производительность или пропускная способность системы ограничена одним или несколькими компонентами. И это далеко не всегда процессор. Высокая загрузка CPU может быть признаком правильно работающей системы, а «торможение» — следствием проблемы на стороне клиента (медленный браузер) или в коде приложения. Например, 100% утилизация CPU может возникать из‑за бесконечных неоптимальных обращений к базе данных — тогда апгрейд процессора не поможет, нужна оптимизация запросов. В 70% случаев потеря производительности лежит на стыке ПО и «железа».

Диагностика: с чего начинать поиск узкого места

Когда заказчик жалуется на «тормоза», алгоритм действий такой:

1. Понять контекст: что именно тормозит (интерфейс, формирование отчета, загрузка файла), когда началось и как проявляется.
2. Локализовать бизнес-процесс: нарисовать путь запроса: клиент → сеть → балансировщик → веб-сервер → сервер приложений → СУБД/СХД.
3. Проверить метрики ресурсов: последовательно оценить загрузку CPU, памяти, дисков и сети. Только так можно выявить реальное «бутылочное горлышко».

Bottleneck‑и в эпоху импортозамещения

Переход на отечественные платформы добавляет новые, неочевидные ограничения. На процессорах «Эльбрус» и «Байкал» некоторые инструкции x86 не выполняются нативно, а эмулируются. Это резко повышает нагрузку на CPU и вызывает непредсказуемые задержки. Кроме того, в российских решениях могут использоваться компоненты китайской разработки, что иногда приводит к ошибкам в драйверах или несовместимости протоколов. Итог — частичная или полная потеря производительности, которую невозможно предсказать по документации.

Программные и конфигурационные ограничители

Бывает, что мощное «железо» не раскрывает свой потенциал из‑за настроек. Классический пример: заказчик перенес СУБД на новые серверы с NVMe, но отклик дисковой системы упал. Причина оказалась в планировщике ввода‑вывода: в образе Linux по умолчанию стоял cfq (Completely Fair Queue), который создавал огромные накладные расходы для NVMe. Смена на none вернула производительность.

Другой частый случай — неэффективные SQL‑запросы. В одной из систем 1С оптимизация запросов (добавление индексов) снизила загрузку CPU с 95% до 30%.

Типовые сценарии: где чаще всего «застревают» данные

Неоптимальные запросы к СУБД — самое частое узкое место (особенно в 1С, ERP-системах). Дисковая подсистема — на втором месте. Но тут важно различать: проблема в самих дисках (высокое время отклика >20‑30 мс для SSD при 100% загрузке) или в сети/контроллерах. Если диски не нагружены, а отклик большой — смотрите потери пакетов на коммутаторах и логи multipathing. Сеть — становится критической в больших распределённых системах. Например, в кластерах ClickHouse или для задач ML данные могут «застревать» из‑за недостаточной пропускной способности сети между узлами. Память внутри сервера — её скорость иногда ниже, чем требуется CPU для непрерывной обработки. Особенно заметно при работе с in‑memory базами.

Эффект «шумного соседа» в современных ЦОД

Раньше соседи по серверу конкурировали за дисковый I/O. С приходом скоростных SSD акцент сместился на кэш процессора, оперативную память и сеть. Как бороться:

1. Cgroups и привязка потоков к конкретным ядрам CPU, изоляция кэша (Intel CAT).
2. NVMe over Fabrics + QoS для управления очередями к хранилищу.
3. SR-IOV — выдача виртуальной машине прямого доступа к сетевой карте, минуя гипервизор.

Экономика оптимизации: когда апгрейд не нужен

В 65% случаев заказчики планируют закупку новых серверов, хотя проблема решается точечной настройкой. Яркий пример: банк жаловался на медленную выгрузку данных из OLAP‑куба (45 минут, превышение таймаута). Готовились менять серверы БД. Оказалось, что Python‑скрипт выбирал данные построчно (row‑by‑row), забивая сеть тысячами мелких пакетов. Переход на массивную выборку (array fetch) сократил время до 4 минут. Экономия — полная стоимость новых серверов.

Чек‑лист быстрой самодиагностики

1. CPU: Load Average > количества ядер — есть очередь. Параметр wa (iowait) — высокий? Ждём диск.
2. Память: смотрим реальное доступное значение (available). Менее 10‑20% — тревожный сигнал. Если пошёл swap‑обмен — совсем плохо.
3. Диски: await > 20 мс — плохо. %util > 80% — диск перегружен. Анализируем, какие процессы создают нагрузку (r/s, w/s).
4. Сеть: проверяем ошибки и потери пакетов, утилизацию канала.
5. ОС: очередь выполнения (run queue) больше числа ядер — плохо. Процессы, ждущие I/O (в состоянии D), постоянно >0 — дисковая проблема.

Если после этого чек‑листа причина не ясна — проблема в приложении или сложной распределённой архитектуре. Нужно профилирование кода.

Как проектировать системы без узких мест (особенно под российское ПО)

Главное правило: не экстраполируйте старые зарубежные шаблоны на новое «железо» без тестов.

1. Изучайте специфику платформы. Для «Эльбруса» (VLIW‑архитектура) софт, оптимизированный под x86, может работать медленно. Возможно, потребуется адаптация кода.
2. Делайте тестовые стенды. Соберите связку «железо + ОС из реестра + СУБД из реестра» и погоняйте реальные запросы. Российские СХД могут иметь специфичные задержки на мелких блоках, что критично для OLTP.
3. Закладывайте запас ресурсов. Для отечественного стека ПО часто требуется на 20‑30% больше CPU и RAM, чем для аналогичного решения на Intel + VMware + Oracle.

Роль нагрузочного тестирования на реальных данных

Синтетические тесты могут показывать отличные результаты, но под реальной нагрузкой (с конкурентными транзакциями, блокировками, специфическими паттернами доступа) производительность способна упасть в разы. Нагрузочное тестирование на реальных сценариях предупреждает 70–80% проблем и выявляет узкие места до ввода системы в эксплуатацию. Только так можно проверить совместимость всех компонентов стека.

Экспертное резюме

Самое дорогое узкое место в российских ИТ‑проектах — это не диски и не процессоры. Это несовместимость стеков и нехватка компетенций. Ситуация, когда уже купленное оборудование не работает с выбранной ОС или СУБД из‑за ошибок в драйверах или отсутствия аппаратного ускорения, обходится в миллионы рублей и месяцы задержек.

Главный совет: не стройте систему из «совместимых по документации» компонентов. Создайте «эталонный стенд» из конкретных моделей серверов, конкретных версий ОС и прикладного ПО. Проведите нагрузочное тестирование на ваших реальных сценариях. Именно этот стенд должен стать спецификацией для закупки. Требуйте от вендоров не просто сертификаты, а протоколы тестирования под вашу нагрузку. В текущих реалиях совместимость на бумаге и в реальной жизни — две большие разницы.