Я периодически проверяю актуальность своих настроек ядра и могу сказать, что автоматы сильно продвинулись с того времени, когда приходилось писать целый ворох параметров для того, чтобы отличить сервер от десктопа. Понятно, что универсальность подхода для нетбука с 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 пустой. Универсальность - есть универсальность. Если что-то надо будет исправить для конкретного случая - буду рассматривать в этом самом конкретном случае.