Оптимизация производительности ОС: Анализ узких мест
Проблемы
Методология поиска узких мест
Инструменты диагностики
процессор — первые замечания
Load Average — коварная метрика
контекстные переключения процессора
рекомендации
Память
Swap убивает производительность
Кэш страниц и "грязные" страницы
HugePages и Transparent HugePages
— когда памяти много
Диск
I/O Wait
Планировщики ввода/вывода
Практика разделения нагрузки на диски
Оптимизация для рабочих станций
Сеть
Сетевые буферы и очереди
Алгоритмы контроля перегрузки TCP
Аппаратная разгрузка (Offloading)
Чек-лист диагностики за 30 секунд
Спасибо за вниманиę
250.60K

Presentation 1 (1)

1. Оптимизация производительности ОС: Анализ узких мест

ОПТИМИЗАЦИЯ
ПРОИЗВОДИТЕЛЬНО СТИ О С:
АНАЛИЗ УЗКИХ МЕСТ
Выполнил студент группы СА-1/25:
Зозуля Илья

2. Проблемы

ПРОБЛЕМЫ
Как найти, что именно тормозит
Как это исправить без замены системника
1 2 . 0 4 . 2 0 2 6

3.

Представим, что наш системник - это завод, состоящий из цехов
К цеху относятся
Процессор(CPU)
Память(RAM)
Диск
Сеть(Network)
1 2 . 0 4 . 2 0 2 6
Задача сис-админов: найти место, где перегружен цех

4. Методология поиска узких мест

МЕТОДОЛОГИЯ ПОИСКА УЗКИХ МЕСТ
1. Наблюдение — смотрим метрики (top, iostat, vmstat)
2. Локализация — находим конкретную подсистему
3. Верификация — меняем параметр и проверяем результат
1 2 . 0 4 . 2 0 2 6

5. Инструменты диагностики

ИНСТРУМЕНТЫ ДИАГНОСТИКИ
Центральный процессор: top, htop, mpstat, pidstat
Память: free, vmstat, smem
Диск: iostat, iotop, ioping
Сеть: ss, netstat, iperf3, nload
Комплексные: glances, nmon, Prometheus и Grafana
1 2 . 0 4 . 2 0 2 6

6. процессор — первые замечания

ПРОЦЕССОР — ПЕРВЫЕ ЗАМЕЧАНИЯ
Что смотрим в top или htop:
%us (user) — работа приложений
%sy (system) — работа ядра
%wa (iowait) — ожидание диска
%id (idle) — простой
Если %wa стабильно выше пяти процентов — проблема в диске
1 2 . 0 4 . 2 0 2 6

7. Load Average — коварная метрика

L O A D AV E R A G E — К О ВА Р Н А Я
МЕТРИКА
Load average - среднее количество процессов в очереди за одну, пять и пятнадцать
минут.
LA меньше числа ядер процессора — всё отлично
LA больше числа ядер, но %id высокий — виноват диск
LA больше числа ядер и %id низкий — процессор действительно перегружен
1 2 . 0 4 . 2 0 2 6

8. контекстные переключения процессора

К О Н Т Е К С Т Н Ы Е П Е Р Е К Л Ю Ч Е Н И Я П Р О Ц Е С С О РА
Норма: до 50-100 тысяч в секунду.
За что нужно беспокоиться: более двухсот тысяч переключений в секунду —
слишком много потоков или проблемы с блокировками.
1 2 . 0 4 . 2 0 2 6

9. рекомендации

РЕКОМЕНДАЦИИ
Для серверов:
IRQ Affinity — распределить прерывания сетевой карты по разным ядрам
CPU Pinning (taskset) — привязать базу данных к конкретным ядрам
Отключить Hyper-Threading для задач, чувствительных к задержкам
Для рабочих станций:
Профиль TuneD performance или latency-performance
Проверить регулятор частоты (cpupower frequency-info)
1 2 . 0 4 . 2 0 2 6

10. Память

ПАМЯТЬ
Что смотреть: free -h, столбец available.
Если available меньше 10% от общего объёма — это проблема.
1 2 . 0 4 . 2 0 2 6

11. Swap убивает производительность

S WA P У Б И ВА Е Т
ПРОИЗВОДИТЕЛЬНОСТЬ
SWAP - диск, который в сотни и тысячи раз медленнее оперативной памяти.
Как найти проблему: vmstat 1, колонки si (swap in) и so (swap out). Если не нули —
Как можно решить: vm.swappiness = 1
1 2 . 0 4 . 2 0 2 6
всё плохо.

12. Кэш страниц и "грязные" страницы

К Э Ш С Т РА Н И Ц И " Г Р Я З Н Ы Е " С Т РА Н И Ц Ы
"грязные" страницы - это данные, которые ещё не записаны на диск.
Параметры ядра:
vm.dirty_ratio - процент оперативной памяти, после которого запись происходит
vm.dirty_background_ratio - процент для фоновой записи
для SSD значения можно увеличить, чтобы реже обращаться к диску.
1 2 . 0 4 . 2 0 2 6
принудительно

13. HugePages и Transparent HugePages

H U G E PA G E S И T R A N S PA R E N T
H U G E PA G E S
HUGEPAGES - ЭТО СТРАНИЦЫ ПАМЯТИ ПО
1 ГБ ВМЕСТО 4 КБ.
2 МБ ИЛИ
Плюс: меньше записей в TLB (буфер
Минус для THP: может вызвать
трансляции адресов) - быстрее
задержки при дефрагментации.
ДЛЯ БАЗ ДАННЫХ (ORACLE, POSTGRESQL)
УСТАНАВЛИВАТЬ MADVISE ИЛИ NEVER.
1 2 . 0 4 . 2 0 2 6
доступ.

14. — когда памяти много

— К О ГД А П А М Я Т И М Н О ГО
NUMA - архитектура памяти в многопроцессорных
системах, где скорость доступа процессора к
оперативной памяти зависит от её физического
расположения
Решение: numactl — привязка процесса к узлу NUMA.
numactl --cpunodebind=0 --membind=0 ./myapp
1 2 . 0 4 . 2 0 2 6
на серверах с двумя процессорами доступ к своей
памяти быстрее, чем к чужой.

15. Диск

ДИСК
Главное: await — среднее время ответа в миллисекундах. %util - утилизация
устройства avgqu-sz - средняя длина очереди
Нормы await-а: Жёсткий диск - до десяти миллисекунд. SATA SSD - до двух
миллисекунд. NVMe - до половины миллисекунды.
1 2 . 0 4 . 2 0 2 6

16. I/O Wait

I/O WAIT
Если %wa высокий, iostat покажет, что является причиной:
await высокий и очередь есть - диск не справляется
await нормальный, но %util равен ста процентам - диск упирается в свой предел
1 2 . 0 4 . 2 0 2 6
жёсткий диск с утилизацией сто процентов и await пятьдесят миллисекунд нужно менять на SSD.

17. Планировщики ввода/вывода

ПЛАНИРОВЩИКИ ВВОДА/ВЫВОДА
Планировщики ввода-вывода - алгоритм, который решает, в каком порядке
отправлять запросы к диску.
NVMe: none (noop) — очередь в самом устройстве, ядру не мешаем
SATA SSD: mq-deadline
Жёсткий диск: mq-deadline или bfq (для настольных систем)
Посмотреть текущий: cat /sys/block/sda/queue/scheduler
Изменить: echo mq-deadline > /sys/block/sda/queue/scheduler
1 2 . 0 4 . 2 0 2 6

18. Практика разделения нагрузки на диски

П РА К Т И К А РА З Д Е Л Е Н И Я Н А Г Р У З К И
НА ДИСКИ
Для серверов баз данных:
Данные - на одном диске или RAIDмассиве
WAL и журналы транзакций - на
отдельном быстром NVMe-накопителе
Логи операционной системы подальше от данных
журналы пишутся последовательно и
синхронно, они не должны мешать
случайному чтению данных.
WAL - технология ведения журнала
предзаписи в базах данных
(особенно PostgreSQL и SQLite),
обеспечивающая надежность
RAID - технология виртуализации данных,
объединяющая несколько физических
жестких дисков (HDD или SSD) в один
логический массив для повышения
надежности, скорости работы или
увеличения емкости хранения
1 2 . 0 4 . 2 0 2 6

19. Оптимизация для рабочих станций

О П Т И М И З А Ц И Я Д Л Я РА Б О Ч И Х
СТАНЦИЙ
noatime в fstab: не обновлять время
доступа к файлу при чтении. Экономия
операций ввода-вывода.
оперативную память.
Пример строки в /etc/fstab: tmpfs /tmp tmpfs
defaults,noatime,nosuid,size=4G 0 0
1 2 . 0 4 . 2 0 2 6
tmpfs для /tmp: вынос временных файлов в

20. Сеть

СЕТЬ
Признаки: повторные передачи, высокий пинг, обрывы соединений.
Инструменты:
ss -s — статистика сокетов
netstat -i — ошибки на интерфейсе
iperf3 — тест полосы пропускания
1 2 . 0 4 . 2 0 2 6

21. Сетевые буферы и очереди

СЕТЕВЫЕ БУФЕРЫ И ОЧЕРЕДИ
Параметры ядра для высоконагруженных серверов:
net.core.somaxconn - очередь входящих соединений (установить 4096 или выше)
net.ipv4.tcp_max_syn_backlog - очередь SYN-пакетов
net.core.rmem_max и wmem_max - буферы приёма и передачи
1 2 . 0 4 . 2 0 2 6
для веб-сервера под нагрузкой увеличить somaxconn до 65535.
somaxconn - параметр ядра Linux, определяющий максимальный размер очереди входящих TCPсоединений, полностью установленных (TCP 3-way handshake завершен), но еще не принятых
приложением через вызов

22. Алгоритмы контроля перегрузки TCP

А Л ГО Р И Т М Ы КО Н Т РОЛ Я П Е Р Е Г РУЗ К И
TCP
Cubic (по умолчанию): агрессивный, хорош для локальных сетей.
BBR (от Google): лучше работает при потерях пакетов и на каналах с
буферизацией.
sysctl net.ipv4.tcp_congestion_control=bbr
Проверить: sysctl net.ipv4.tcp_congestion_control
1 2 . 0 4 . 2 0 2 6
Как сменить:

23. Аппаратная разгрузка (Offloading)

А П П А РАТ Н А Я РА З Г Р У З К А
(OFFLOADING)
Суть: перенос вычислений на сетевую карту.
Плюс: разгружаем центральный процессор.
Посмотреть: ethtool -k eth0
Отключить при проблемах: ethtool -K eth0 gro off lro off
1 2 . 0 4 . 2 0 2 6
Минус: может добавить задержку для мелких пакетов.

24. Чек-лист диагностики за 30 секунд

ЧЕК-ЛИСТ ДИАГНОСТИКИ ЗА 30 СЕКУНД
top — %wa >5 процентов? Идём в iostat.
1. free -h — available меньше 500 мб? Ищем утечку памяти.
2. iostat -x 1 — await больше 20 мс? Меняем диск или планировщик.
4. dmesg | tail — есть сообщения OOM Killer? Настраиваем лимиты через cgroups.
1 2 . 0 4 . 2 0 2 6
3. vmstat 1 — si и so не ~= 0? Устанавливаем swappiness == 1.

25. Спасибо за вниманиę

С П АС И Б О З А В Н И М А Н И Ę
25
1 2 . 0 4 . 2 0 2 6
English     Русский Правила