Jako senior sysadmin, widziałem to setki razy. Masz świetny hardware, szybkie dyski NVMe i 100Gbps sieci, ale Twoja aplikacja dławi się przy 10k jednoczesnych połączeń. Dlaczego? Bo domyślne parametry kernela Linuxa są zaprojektowane dla desktopów i uniwersalnych serwerów z 2010 roku, a nie dla potworów obsługujących ruch produkcyjny na wielką skalę.
Optymalizacja Stosu Sieciowego
Najważniejszym elementem przy dużym ruchu (HTTP/S, gRPC, WebSocket) jest to, jak kernel radzi sobie z kolejkami przychodzącymi i deskryptorami plików. Zapomnij o domyślnym somaxconn wynoszącym 128. To zabójstwo dla wydajności.
# Zwiększenie maksymalnej liczby oczekujących połączeń
net.core.somaxconn = 65535
# Maksymalna liczba oczekujących pakietów w kolejce wejściowej
net.core.netdev_max_backlog = 16384
# Optymalizacja buforów TCP (Read/Write)
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# Szybkie zwalnianie nieaktywnych połączeń (TIME_WAIT reuse)
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 8192
Ustawienie tcp_tw_reuse pozwala na ponowne wykorzystanie gniazd w stanie TIME_WAIT, co jest krytyczne, gdy Twoja usługa szybko nawiązuje i zamyka tysiące połączeń na sekundę. Bez tego ryzykujesz wyczerpanie puli portów efemerycznych.
Zarządzanie Pamięcią i VFS
Kolejny punkt zapalny to I/O i cache. Kernel uwielbia agresywnie swapować, jeśli mu na to pozwolisz. Na serwerze bazy danych lub cache'u (Redis/Memcached) chcesz tego uniknąć za wszelką cenę.
# Minimalizacja wykorzystania swapu (0-10 dla serwerów)
vm.swappiness = 5
# Procent brudnej pamięci, przy której procesy zaczną zapis na dysk
vm.dirty_ratio = 15
# Procent brudnej pamięci, przy której kernel zacznie zapis w tle
vm.dirty_background_ratio = 5
# Agresywność zwalniania cache i-node'ów (standardowo 100)
vm.vfs_cache_pressure = 50Aplikowanie zmian
Po edycji plików konfiguracyjnych, załaduj nową konfigurację bez restartu serwera:
# sysctl -p /etc/sysctl.d/99-network-tuning.conf
# sysctl -p /etc/sysctl.d/99-memory-tuning.conf