Настройка ядра (sysctl.conf) для сервера и десктопа в 2023 году : Linux
Я периодически проверяю актуальность своих настроек ядра и могу сказать, что автоматы сильно продвинулись с того времени, когда приходилось писать целый ворох параметров для того, чтобы отличить сервер от десктопа. Понятно, что универсальность подхода для нетбука с 4Гб памяти и для сервера с 1Тб памяти требует достаточно кропотливого труда. Есть и масса других нюансов. Ниже приведу свои конфиги для ядра 6.2.8 и, соответственно, как я его понимаю в 2023 году.
Параметры sysctl.conf для сервера:
kernel.panic = 3 fs.file-max = 1048576 net.ipv4.tcp_fastopen = 3 net.ipv4.tcp_syn_retries = 3 net.ipv4.tcp_synack_retries = 3 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_keepalive_time = 120 net.ipv4.tcp_keepalive_intvl = 15 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_tw_reuse = 1 net.core.wmem_max = 33554432 net.core.rmem_max = 16777216 net.ipv4.tcp_congestion_control=bbr net.core.default_qdisc=fq vm.oom_dump_tasks = 0 vm.swappiness = 1 kernel.sched_autogroup_enabled = 0 kernel.domainname = olegon.ru
Обращаю внимание, что совсем недавно у меня стал нормально считаться vm.min_free_kbytes, так что лучше обратить внимание на этот параметр, если у вас сервер с большим количеством памяти. Раньше резервировалось слишком много памяти, видимо, в процентах.
kernel.panic я выставляю в 3 секунды всегда, либо ты сидишь и смотришь в экран, оценивая случившееся, либо чем быстрее ребутнется машина при панике, и, скорее всего, вернется в строй, тем лучше. Справедливости ради, за всю мою историю общения с линуксами я такую панику видел всего лишь один раз и корнями она была в неисправности железа.
fs.file-max — количество открытых файлов. Поскольку в линуксе файлами является практически все, то серверу лучше не ограничивать их количество.
net.ipv4.tcp_fastopen позволяет использовать fast open для сокетов сервера и nginx это умеет при соответствующей опции в конфиге статья по настройке у меня тут уже была.
net.ipv4.tcp_syn_retries, net.ipv4.tcp_synack_retries, net.ipv4.tcp_fin_timeout, net.ipv4.tcp_keepalive_time, net.ipv4.tcp_keepalive_intvl, net.ipv4.tcp_keepalive_probes — эти параметры выставлены для того, чтобы не скапливалась информация о подвисающих и неустойчивых соединениях. Их на сервере сотни тысяч, и универсальность, помогающая выживать на какой-нибудь модемной связи, мне тут совершенно не нужна. Три попытки соединения или проверки его живости — нет, до свидания.
net.ipv4.tcp_tw_reuse возможность переиспользования соединения потенциально может в себе нести какую-то дырку, однако, у меня нет никаких банковских операций, зато процессор эта штука экономит, как в теории, так и на практике. Да и пошустрее все, соответственно.
net.core.wmem_max, net.core.rmem_max — общее количество памяти, выделяемой под сетевые буферы. И тут могу сказать точно, что «по умолчанию» не подходит для сервера. Нет, оно работать будет, но со значениями по умолчанию разница очень хорошо видна даже на глазок, если дать памяти побольше.
net.ipv4.tcp_congestion_control, net.core.default_qdisc — включение congestion control от Google. Включать, соответственно, можно только там, откуда качают, то есть на сервере. Настоятельно рекомендую для всех видов траффика.
vm.oom_dump_tasks — без дампа, который никто никогда не смотрит, куда лучше и быстрее. Если потребуется — включите.
vm.swappiness — немного затравки для спора. С одной стороны, например, sshd вам не нужен все время и пусть он уходит в своп, высвобождая память для того, что должно работать шустро. С другой стороны, в своп может что-то завалиться при текущем распределении памяти и просто так, а с учетом SSD егозить постоянно по нему — плохая идея. В общем, я сторонник того, чтобы своп на сервере был минимальный, как и количество мусора в памяти на нем. И, да, я противник полного отключения свопа.
kernel.sched_autogroup_enabled — у меня на сервере мусора никакого нет, группировка, на мой взгляд, не нужна. А тратить на нее ресурсы, добавлять глюки. Ни к чему.
Обращаю внимание, что выставляемые раньше сетевые буферы я ставить перестал. Автомат справляется очень неплохо, а прибитые значения не очень, учитывая разницу траффика, например, того же DNS и выкачивания видео. Так же обращу внимание, что это все для моего полугигабита и нагрузке, с которой сервер справляется в пределах своего канала. При гигабите и более, при десятках тысяч подключений в секунду необходимо крутить длину очереди и т.п., то есть уже не только производительность учитывать, но и помогать серверу справляться, если он не справляется. Но, в большинстве случаев это все ведет просто к апгрейду железа. Еще есть достаточно обширный спектр настроек сетевых карт, которые можно покрутить из ОС. Однако, это все уже для оборудования уровня провайдеров.
Параметры sysctl.conf для десктопа:
kernel.panic = 3 fs.file-max = 1048576 net.ipv4.tcp_syn_retries = 2 net.ipv4.tcp_synack_retries = 2 net.ipv4.tcp_fin_timeout = 60 net.ipv4.tcp_keepalive_time = 120 net.ipv4.tcp_keepalive_intvl = 15 net.ipv4.tcp_keepalive_probes = 2 net.ipv4.tcp_tw_reuse = 1 net.core.wmem_max = 4194304 net.core.rmem_max = 4194304 vm.oom_dump_tasks = 0 kernel.domainname = olegon.ru
В принципе, я все выше уже описал почему и как. На десктопе соединений меньше, но все равно, современный десктоп — это сотни соединений по быстрой связи. Однако, на своем походном нетбуке, который бывает в очень разных условиях, у меня sysctl.conf пустой. Универсальность — есть универсальность. Если что-то надо будет исправить для конкретного случая — буду рассматривать в этом самом конкретном случае.
системные настройки высоконагруженного сервера
Настройки Linux по-умолчанию не годятся для высоких нагрузок. Под высокими нагрузками я понимаю от 10000 запросов в секунду. В данной статье рассмотрим два «переключателя», покрутив которые мы добьемся от сервера устойчивости и отзывчивости при высоких нагрузках. Эти переключатели: limits.conf и sysctl.conf
limits.conf
Это конфигурационный файл для pam_limits.so модуля. Он определяет ulimit лимиты для пользователей и групп. В Linux есть системные вызовы: getrlimit() и setrlimit() для получения и установления лимитов на системные ресурсы. Конфигурация по-умолчанию лежит в /etc/security/limits.conf. Также присутствует возможность добавлять отдельные конфиги для приложений в /etc/security/limits.d. Для того, чтобы сервер держал большую нагрузку, нужно увеличить некоторые лимиты. Посмотрим, какие лимиты у нас стоят по-умолчанию. Запустим под рутом.
ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 256957 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 256957 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Обратим внимание на open files, max user processes и max locked memory. Это стандартные ограничения, которые нужно убрать, если хотим держаться под нагрузкой. Перед изменениями хочу предупредить, что если железо недостаточно мощное, то ваш сервер может подвергнуться атаке типа fork bomb, так что аккуратно раздавайте права на сервере.
Приведем /etc/security/limits.conf к такому виду.
* soft nproc 65000 * hard nproc 1000000 * - nofile 1048576 root - memlock unlimited В файле мы устанавливаем мягкий и жесткий лимиты на количество запущенных процессов, открытых файлов (читай портов) для всех пользователей и неограниченный лок памяти для рута.
Хочу поподробнее рассказать, почему для открытых файлов было выбрано ограничение в 1048576. Это волшебное число захардкожено в ядре, чтоб поставить больше, нужно пересобирать ядро. Более развернуто на эту тему отвечают на stackoverflow и вот здесь.
Изменения вступят в силу или после перезагрузки или после нового логина или создания сессии ssh. Проверить, включается ли модуль pam_limits можно в файлах /etc/pam.d Для Debian есть статья в wiki на эту тему: https://wiki.debian.org/Limits
sysctl.conf
В /etc/sysctl.conf настраиваются параметры ядра, модулей и других подсистем. По сути, можно вручную менять значения псевдо-фс /proc, но такие изменения не сохранятся после перезагрузки, поэтому будем сразу вносить изменения в этот конфиг файл.
Для пользователей systemd этот файл уже не играет роли. Если вы вдруг используете systemd, вам нужно править файлы в /etc/sysctl.d/. Подробнее читайте на http://www.freedesktop.org/software/systemd/man/sysctl.d.html
Вот пример моего sysctl.conf для высоконагруженной системы.
net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 kernel.sysrq = 0 net.ipv4.tcp_syncookies = 0 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 68719476736 kernel.shmall = 4294967296 vm.swappiness = 0 net.ipv4.tcp_fack = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_mem = 8388608 12582912 16777216 net.ipv4.udp_mem = 8388608 12582912 16777216 net.ipv4.udp_rmem_min = 16384 net.ipv4.udp_wmem_min = 16384 net.core.wmem_max = 8388608 net.core.rmem_max = 8388608 net.ipv4.tcp_rmem = 8192 87380 8388608 net.ipv4.tcp_wmem = 8192 87380 8388608 net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_window_scaling = 1 net.core.somaxconn = 300000 net.core.netdev_max_backlog = 8192 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_keepalive_time = 180 net.ipv4.tcp_keepalive_probes = 5 net.ipv4.tcp_keepalive_intvl = 30 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 0 net.ipv4.tcp_max_tw_buckets = 1000000 net.ipv4.ip_local_port_range = 1024 65535 net.nf_conntrack_max = 1000000 Подробно про все опции, можно прочитать в
Или, например, здесь. А тут написано как люди выдерживают миллион pps в секунду и приведены примеры используемых sysctl.conf
После изменения sysctl.conf применим наши правки.
После перезагрузки все изменения будут применяться автоматически.
Заключение
Все вышеописанное применялось мной на работе для высоконагруженного сервера, который перед выкаткой в прод тестировался замечательным Yandex танком и держал нагрузку порядка 20000 rps. Стоит учесть, что сам по себе Linux не обеспечит вам стойкости под нагрузкой, если ваш софт ломается при 100 rps. Тут уже вас может спасти балансировка нагрузки. Смотрите в сторону HAProxy, LVS, Keepalived. Удачного прохождения высоких нагрузок!