Настройки операционной системы, влияющие на производительность компьютера

Настройки операционной системы способны заметно изменить производительность компьютера, но эффект появляется только при совпадении параметров с реальной нагрузкой. Для сервера чаще всего полезны корректные лимиты файлов, подходящая схема питания, контроль записи в page cache и сетевые буферы. Для рабочей станции сильнее заметны режим питания, планирование процессов и доступный объем памяти.

Универсального набора твиков не существует. Снижение задержки может увеличить число переключений контекста, большие сетевые буферы способны занять память, а слишком агрессивная запись на диск приводит к резким всплескам latency. Перед изменением параметров зафиксируйте исходные значения и измерьте CPU, RAM, swap, disk await, сетевую задержку и throughput. Для диагностики пригодится практическое руководство по мониторингу производительности сервера.

Ниже разобраны настройки Linux и Windows для серверов, рабочих станций, баз данных и веб-приложений. Команды дают стартовые значения для проверки, а не готовый универсальный профиль. После каждого изменения повторяйте один и тот же тест на одинаковом наборе данных.

Планировщик задач: как ОС распределяет процессорное время

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

Настройка планировщика в Linux: sysctl и приоритеты

В документации часто упоминается CFS, Completely Fair Scheduler. В ядрах Linux 6.6 и новее часть логики планирования процессов работает на базе EEVDF. Набор доступных параметров зависит от версии ядра, конфигурации и включенных отладочных опций. Сначала проверьте, существуют ли нужные ключи:

sysctl -a 2>/dev/null | grep 'kernel.sched_'
sysctl kernel.sched_latency_ns kernel.sched_min_granularity_ns kernel.sched_wakeup_granularity_ns

Параметры имеют следующий смысл:

Параметр	Что меняет	Практический риск
`kernel.sched_latency_ns`	Целевой интервал, за который runnable-процессы получают процессорное время.	Слишком низкое значение увеличивает число переключений.
`kernel.sched_min_granularity_ns`	Минимальный квант выполнения процесса.	Малый квант снижает задержку отклика, но повышает накладные расходы.
`kernel.sched_wakeup_granularity_ns`	Порог, при котором разбуженный процесс получает преимущество перед текущим.	Слишком низкое значение может ухудшить throughput фоновой нагрузки.

Для десктопа с интерактивными приложениями можно проверить профиль с более короткими интервалами:

sudo sysctl -w kernel.sched_latency_ns=12000000
sudo sysctl -w kernel.sched_min_granularity_ns=1500000
sudo sysctl -w kernel.sched_wakeup_granularity_ns=2000000

Для сервера базы данных сначала оставьте значения ядра по умолчанию. Если тест показывает лишние переключения и нагрузка состоит из крупных CPU-задач, можно проверить более длинный квант:

sudo sysctl -w kernel.sched_latency_ns=24000000
sudo sysctl -w kernel.sched_min_granularity_ns=3000000
sudo sysctl -w kernel.sched_wakeup_granularity_ns=4000000

Эти числа подходят только как точки для эксперимента. Если ключ отсутствует, не добавляйте его вручную в конфигурацию: конкретная версия ядра может не использовать такой параметр. Сохранить проверенный профиль можно в файле /etc/sysctl.d/90-local-scheduler.conf, после чего применить его командой sudo sysctl --system.

Чаще пользу дает управление приоритетом отдельных процессов. В Linux меньшее значение nice означает больший приоритет:

renice -n 5 -p PID
ionice -c2 -n7 -p PID

nice влияет на CPU-планирование, а ionice задает класс и приоритет дискового ввода-вывода. Фоновую индексацию, архивирование и резервное копирование можно понизить. Отрицательные значения nice требуют прав администратора. Для постоянного сервиса задайте параметры в unit-файле systemd:

[Service]
Nice=5
IOSchedulingClass=best-effort
IOSchedulingPriority=7

Не повышайте приоритет Nginx, PostgreSQL или Docker без измерений. Процесс с большим приоритетом способен вытеснить системные службы и ухудшить общую стабильность.

Приоритеты процессов в Windows: как не навредить

Windows использует классы приоритета Idle, Below Normal, Normal, Above Normal, High и Real-time. Обычные приложения запускаются с классом Normal. Above Normal подходит для задачи, которой нужно быстрее получить CPU, но которая не должна вытеснять системные службы.

Изменить приоритет можно через Диспетчер задач: откройте вкладку «Подробности», выберите процесс, вызовите контекстное меню и задайте класс в пункте «Задать приоритет». Для разовой проверки через PowerShell:

Get-Process -Name app | ForEach-Object { $_.PriorityClass = 'AboveNormal' }

Для фоновой компиляции, индексации или конвертации безопаснее использовать BelowNormal. High допустим для коротких задач, если измерения подтверждают пользу. Real-time почти никогда не нужен пользовательскому процессу: приложение может занять процессор и оставить систему без времени для драйверов, ввода, сети и оболочки.

Класс приоритета не закрепляет процесс за конкретными ядрами и не заменяет настройку affinity, NUMA или самого приложения. Изменение через Диспетчер задач обычно действует только до перезапуска процесса.

Управление питанием: баланс между энергопотреблением и производительностью

Схема питания управляет частотой CPU, переходами P-state и C-state, реакцией на кратковременную нагрузку и политикой охлаждения. На ноутбуке сбалансированный режим часто дает лучший результат за счет меньшего нагрева и шума. На сервере с постоянной нагрузкой режим performance может уменьшить задержку выхода процессора на рабочую частоту.

Настройка CPU governor в Linux

Проверьте драйвер частоты и доступные governor:

cpupower frequency-info
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

Основные режимы:

performance удерживает CPU ближе к верхней частоте и сокращает реакцию на нагрузку ценой энергопотребления;
schedutil выбирает частоту по данным планировщика и подходит для большинства рабочих станций и ноутбуков;
powersave сильнее ограничивает потребление, но его фактическое поведение зависит от драйвера;
ondemand и conservative встречаются на старых конфигурациях и используются реже.

Временная смена режима:

sudo cpupower frequency-set -g performance
sudo cpupower frequency-set -g schedutil

На системах с intel_pstate список governor может отличаться. Режим powersave при этом не обязательно фиксирует минимальную частоту, он задает политику управления частотой. Проверяйте реальную частоту, температуру и latency под нагрузкой, а не делайте вывод по одному названию режима.

Для сервера с постоянной нагрузкой начните с performance, если охлаждение выдерживает длительную работу. Для ноутбука, разработки, браузера и легких контейнеров оставьте schedutil. TLP и systemd-сервисы помогают закрепить профиль после перезагрузки, но конкретный способ зависит от дистрибутива.

Отключение C-states не дает гарантированного ускорения. Оно может сократить задержку выхода из глубокого сна на специфических системах реального времени, но увеличивает потребление и нагрев. Сначала измерьте wake-up latency и убедитесь, что процессор не уходит в thermal throttling.

Схемы электропитания в Windows

Проверить активную схему и доступные профили можно командой:

powercfg /getactivescheme
powercfg /list

Для длительной серверной или вычислительной нагрузки можно временно включить профиль высокой производительности:

powercfg /setactive SCHEME_MIN

Для обычной работы верните сбалансированный профиль:

powercfg /setactive SCHEME_BALANCED

Параметры CPU доступны для просмотра так:

powercfg /query SCHEME_CURRENT SUB_PROCESSOR

Минимальное состояние процессора влияет на нижнюю границу частоты, максимальное ограничивает верхнюю. Значение 100 процентов в максимальном состоянии не заставляет CPU постоянно работать на пике. Политика охлаждения определяет, будет ли система сначала повышать обороты вентиляторов или снижать частоту.

Избирательное отключение USB может мешать внешним накопителям и периферии. На стационарной машине с постоянной нагрузкой эту функцию проверяют отдельно. На ноутбуке отключение энергосбережения USB и процессора сокращает время работы от батареи.

Файловый кэш и подсистема ввода-вывода

Linux использует page cache для повторного чтения файлов и буферы отложенной записи. Windows хранит часто используемые данные в standby list и кэше файловой системы. Свободная RAM сама по себе не означает проблему: память может работать как кэш и освобождаться приложениям по мере необходимости.

Тюнинг виртуальной памяти в Linux

Посмотрите текущие значения:

sysctl vm.dirty_ratio vm.dirty_background_ratio vm.dirty_expire_centisecs vm.vfs_cache_pressure vm.swappiness

Параметр	Назначение	Что проверять после изменения
`vm.dirty_background_ratio`	Доля RAM, после которой фоновые потоки начинают сбрасывать грязные страницы.	Размер очереди записи и latency диска.
`vm.dirty_ratio`	Порог для процесса, который сам начинает ждать записи на диск.	Пики задержек и длительность flush.
`vm.dirty_expire_centisecs`	Время, после которого грязные страницы считаются устаревшими для записи.	Равномерность записи и скорость сброса.
`vm.vfs_cache_pressure`	Скорость освобождения кэша dentries и inode.	Повторное открытие файлов и давление на RAM.
`vm.swappiness`	Склонность ядра перемещать анонимные страницы в swap.	Swap in/out и latency приложений.

Для системы с небольшим объемом RAM можно начать с умеренных значений:

sudo sysctl -w vm.dirty_background_ratio=5
sudo sysctl -w vm.dirty_ratio=15
sudo sysctl -w vm.dirty_expire_centisecs=3000
sudo sysctl -w vm.vfs_cache_pressure=100
sudo sysctl -w vm.swappiness=10

Процентные пороги плохо масштабируются на сервере с 64 или 128 ГБ RAM: 15 процентов превращаются в гигабайты грязных данных и способны вызвать длинную паузу записи. Для таких машин удобнее задать абсолютные ограничения:

sudo sysctl -w vm.dirty_background_bytes=67108864
sudo sysctl -w vm.dirty_bytes=268435456

Выбирайте либо пару ratio, либо пару bytes. Одновременное задание обоих вариантов усложняет прогноз поведения и может привести к тому, что активными останутся байтовые ограничения.

Значение vm.swappiness=1 не запрещает swap полностью. Оно лишь снижает склонность ядра к перемещению страниц. Слишком низкое значение при дефиците памяти может привести к резкому запуску OOM killer. Для базы данных обычно сохраняют небольшой swap как аварийный буфер, а основную память контролируют настройками самой СУБД.

Планировщик диска выбирают по типу накопителя и характеру I/O. Для NVMe часто подходят none или mq-deadline. Для SATA SSD и виртуальных дисков результат зависит от контроллера и гипервизора. Проверяйте фактический режим:

cat /sys/block/nvme0n1/queue/scheduler

Настройка кэша в Windows

Параметр LargeSystemCache задает, какую долю памяти Windows может отдавать кэшу файловой системы. На рабочей станции обычно сохраняют значение 0. Значение 1 проверяют на выделенном файловом сервере, когда нагрузка состоит из большого числа операций чтения и записи файлов. На компьютере с тяжелыми приложениями этот режим способен уменьшить доступную память процессам.

Ветка реестра для параметра находится в HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management. Перед изменением сохраните исходное значение и проверьте эффект после перезагрузки. Изменение не заменяет настройку RAM, pagefile и кэша приложения.

Утилита fsutil позволяет проверить некоторые параметры поведения NTFS:

fsutil behavior query memoryusage

Команду fsutil behavior set memoryusage 2 применяйте только после теста на конкретном файловом сервере. Глобальное увеличение потребления памяти кэшем не ускоряет каждый сценарий.

Для съемных накопителей Windows предлагает режимы «Быстрое удаление» и «Оптимальная производительность». Второй вариант активнее использует отложенную запись и требует безопасного извлечения устройства. При сбоях питания данные из кэша могут потеряться. На внешних дисках без стабильного питания безопаснее оставить быстрый режим удаления.

Сетевые буферы и параметры TCP/IP

Размер TCP-буфера должен соответствовать bandwidth-delay product, произведению пропускной способности канала на задержку. Для канала 10 Гбит/с с RTT 20 ms окно примерно 25 MB на направление. Буфер 16 MB может ограничить throughput на таком маршруте, но для локальной сети с RTT менее 1 ms он часто избыточен.

Оптимизация сетевого стека Linux

Проверьте текущие лимиты и алгоритмы congestion control:

sysctl net.core.rmem_default net.core.wmem_default net.core.rmem_max net.core.wmem_max
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
ss -s

Параметры rmem_default и wmem_default задают начальные размеры буферов сокетов. Значения rmem_max и wmem_max ограничивают автоматический рост. Они не выделяют максимальную память каждому соединению сразу.

Для сервера в сети 10G с большим количеством соединений можно начать с такого профиля:

net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 16384 16777216
net.ipv4.tcp_congestion_control=cubic

CUBIC остается безопасной отправной точкой. BBR стоит проверять на каналах с высокой задержкой и большим BDP, если алгоритм присутствует в списке доступных. Он может улучшить throughput и latency на одном маршруте и дать худший результат на другом. Сравнивайте p95/p99 задержки, retransmits, загрузку CPU и скорость передачи.

Большие буферы расходуют kernel memory на множество соединений. Для сервиса с 100 000 TCP-сессий увеличение максимума до десятков мегабайт без расчета может создать серьезное давление на RAM. Меняйте параметры после проверки числа сокетов, среднего окна TCP и фактической загрузки канала.

Настройка TCP/IP в Windows

Сначала получите текущий профиль:

netsh int tcp show global

Автонастройку окна приема обычно оставляют включенной:

netsh int tcp set global autotuninglevel=normal
netsh int tcp set global rss=enabled

RSS распределяет обработку сетевых пакетов по ядрам. Отключение RSS оправдано только при подтвержденной проблеме драйвера или совместимости. Параметр TCP Chimney Offload относится к старым механизмам разгрузки и не служит универсальным способом ускорить сеть. На актуальных системах Windows он может игнорироваться или отсутствовать.

Автонастройку окна приема переводят в другой режим только после теста с конкретным сетевым оборудованием, VPN, прокси или WAN-каналом. Ручная фиксация буферов часто мешает масштабированию окна и снижает throughput.

TcpAckFrequency иногда меняют для снижения задержки в отдельных игровых сценариях. Значение 1 уменьшает задержку отложенного ACK, но повышает число пакетов и нагрузку на сеть. Глобально менять его на сервере не следует. На запуск некоторых игр влияют и защитные функции, поэтому отключение security features ради нескольких миллисекунд может нарушить работу античита Vanguard.

Лимиты процессов и ресурсов

Лимит ресурса не ускоряет приложение сам по себе. Он предотвращает отказ при достижении предела, например когда веб-сервер открывает тысячи сокетов. Если лимит поднять без контроля памяти, CPU и количества соединений, ошибка «слишком мало файлов» сменится исчерпанием RAM или дескрипторов ядра.

Настройка ulimit в Linux

Проверьте лимиты текущей shell-сессии:

ulimit -n
ulimit -u
ulimit -s
ulimit -a

ulimit -n показывает число открытых файловых дескрипторов;
ulimit -u ограничивает число процессов и потоков для пользователя;
ulimit -s задает размер стека процесса в KB.

Для сервисного пользователя можно задать постоянные значения в /etc/security/limits.conf:

nginx soft nofile 65535
nginx hard nofile 65535
postgres soft nofile 65535
postgres hard nofile 65535

Эти строки применяются через PAM и могут не влиять на systemd-службу. Для Nginx и PostgreSQL надежнее задать лимит в unit-файле:

[Service]
LimitNOFILE=200000

Значение должно учитывать workers, соединения, файлы журналов, upstream-сокеты и служебные дескрипторы. Для Nginx worker_connections не может использовать больше файлов, чем разрешено процессу. Увеличивайте оба параметра согласованно.

Лимит процессов -u поднимайте при реальной потребности в потоках, воркерах или задачах сборки. Размер стека обычно оставляют по умолчанию. Его уменьшение может вызвать ошибки приложений, а чрезмерное увеличение расходует адресное пространство на каждый поток.

Лимиты в Windows

В Windows нет прямого аналога ulimit для открытых файлов. Дескрипторы процессов распределяются динамически, а ограничения чаще задают через Job Objects, параметры службы, контейнеры, квоты и политики Windows Server.

Windows System Resource Manager встречается в старых редакциях Windows Server и не должен считаться универсальным инструментом для актуальных систем. Перед применением проверьте наличие компонента в конкретной версии. Для новых окружений используйте штатные механизмы управления службами и контейнерами.

Увеличение лимитов памяти через реестр без расчета не решает проблему утечки или неправильного числа worker-процессов. Оставляйте pagefile включенным, контролируйте commit limit, handles, private bytes и рабочий набор процесса. При массовом создании соединений сначала найдите источник роста, затем задайте ограничение на уровне приложения или службы.

Когда лучше оставить настройки по умолчанию

Признаки того, что система не нуждается в тюнинге

Настройки ОС можно не менять, если система выдерживает штатную нагрузку, p95 и p99 задержки стабильны, swap почти не используется, диск не накапливает очередь, а CPU не упирается в частоту или thermal throttling. Отсутствие жалоб пользователей и ошибок в журналах тоже говорит в пользу сохранения текущего профиля.

Перед настройкой соберите baseline минимум в трех повторениях. Для сервера запишите load average, CPU steal, iowait, PSI memory, disk await, queue depth, retransmits и число открытых файлов. Для рабочей станции измерьте время сборки, запуск IDE, задержку приложения и температуру CPU.

Признаки, при которых твик может ухудшить ситуацию:

большой vm.dirty_ratio создает длинный flush и задержки запросов;
низкий vm.swappiness не спасает систему при полном исчерпании RAM;
огромные TCP-буферы расходуют память на каждое соединение;
высокий приоритет процесса вытесняет сетевые, дисковые и системные службы;
режим высокой производительности повышает температуру, после чего частота падает из-за перегрева;
чрезмерный nofile позволяет сервису открыть больше ресурсов, чем выдерживает инфраструктура.

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

Риски необдуманных изменений

Любая системная настройка меняет компромисс между latency, throughput, потреблением памяти, энергией и стабильностью. Поэтому перед изменением сохраните конфигурацию, зафиксируйте версию ядра или Windows, подготовьте план отката и проверьте доступ к консоли, если сетевой сервер может потерять связь.

Снимите исходные значения sysctl, powercfg, сетевых параметров и лимитов.
Измените один логически связанный набор параметров.
Прогоните одинаковый тест с тем же объемом данных и числом клиентов.
Сравните среднее значение, p95, p99, ошибки, температуру и потребление памяти.
Закрепите настройку только после повторного теста и проверки после перезагрузки.

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

Практические примеры настройки для типовых сценариев

Веб-сервер Nginx или Apache на Linux

Для веб-сервера обычно важны число соединений, скорость принятия новых запросов, лимиты дескрипторов и равномерность записи логов. Ниже пример стартового профиля для Linux-сервера с 8-16 ГБ RAM и сетью 1-10G:

# /etc/sysctl.d/90-web.conf
fs.file-max=1000000
net.core.somaxconn=4096
net.ipv4.tcp_max_syn_backlog=8192
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 131072 16777216
net.ipv4.tcp_wmem=4096 16384 16777216
net.ipv4.tcp_congestion_control=cubic
vm.swappiness=10
vm.dirty_background_bytes=67108864
vm.dirty_bytes=268435456

Примените файл и проверьте результат:

sudo sysctl --system
sysctl fs.file-max net.core.somaxconn vm.swappiness
ss -s
cat /proc/sys/fs/file-nr

Для systemd-службы Nginx задайте лимит:

sudo systemctl edit nginx

[Service]
LimitNOFILE=200000

После изменения сравните число активных соединений, очередь accept, p95 ответа, ошибки 502/504 и загрузку CPU. Если веб-сервер нужен для тестового стенда, его можно разместить в облачной инфраструктуре с изменяемыми ресурсами, например на серверах Timeweb Cloud. Тестируйте профиль на той же версии ядра и с тем же типом диска, который будет в рабочей среде.

Сервер баз данных PostgreSQL или MySQL

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

vm.swappiness=10
vm.vfs_cache_pressure=100
vm.dirty_background_bytes=67108864
vm.dirty_bytes=268435456

Не поднимайте dirty_ratio до десятков процентов на сервере с большим объемом RAM. СУБД может получить длинную задержку записи, когда ядро начнет сбрасывать накопившийся кэш. Проверяйте iostat -xz 1, latency диска, checkpoint time, fsync latency и p99 транзакций.

Для SSD проверьте планировщик:

cat /sys/block/nvme0n1/queue/scheduler

none часто подходит для NVMe, если очередь хорошо обрабатывается контроллером. mq-deadline может дать более предсказуемую задержку при смешанной нагрузке. Выбор зависит от устройства, гипервизора и профиля запросов.

Лимит файлов задавайте с учетом числа соединений, временных файлов, WAL, журналов и фоновых процессов. Значение 65535 служит распространенной отправной точкой, но не заменяет расчет. Параметры shared_buffers, work_mem, buffer pool и checkpoint нужно согласовать с настройками самой СУБД, иначе системный кэш не компенсирует ошибочную конфигурацию приложения.

Рабочая станция для разработки на Windows или Linux

Для компиляции, IDE, контейнеров и виртуальных машин важна отзывчивость системы при сохранении запаса RAM. На Linux временно включите performance во время тяжелой сборки:

sudo cpupower frequency-set -g performance

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

На Windows активируйте высокую производительность только на период сборки или работы виртуальных машин:

powercfg /setactive SCHEME_MIN

Для повседневного режима используйте SCHEME_BALANCED. Не отдавайте виртуальным машинам и контейнерам 100 процентов RAM хоста. Оставляйте запас для файлового кэша, IDE, фоновых служб и самого гипервизора. При компиляции сравнивайте время сборки, загрузку всех ядер, частоту CPU, температуру и объем pagefile или swap.

Заключение: осознанный подход к настройке системы

Настройки ОС дают заметный эффект в конкретных условиях: governor влияет на реакцию CPU, планировщик меняет баланс между latency и throughput, page cache определяет характер дисковой записи, TCP-буферы помогают заполнить быстрый канал, а лимиты предотвращают отказ при росте числа соединений.

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

Для Linux-серверов с более глубокими примерами sysctl, памяти, сети и контейнеров используйте практическое руководство по настройке Linux-серверов для DevOps. Оно поможет перенести отдельные изменения в проверенный порядок диагностики и закрепления конфигурации.