Řešení 1:
Konečně jsem našel nastavení, které skutečně omezovalo počet připojení:net.ipv4.netfilter.ip_conntrack_max . Toto bylo nastaveno na 11 776 a cokoliv jsem nastavil, je počet požadavků, které mohu obsloužit ve svém testu, než budu muset čekat tcp_fin_timeout sekund, aby bylo k dispozici více připojení. conntrack tabulka je to, co jádro používá ke sledování stavu připojení, takže jakmile je plná, jádro začne zahazovat pakety a tiskne to do protokolu:
Jun 2 20:39:14 XXXX-XXX kernel: ip_conntrack: table full, dropping packet.
Dalším krokem bylo přimět jádro, aby recyklovalo všechna tato připojení v TIME_WAIT stav spíše než zahazování paketů. Mohl bych to udělat buď zapnutím tcp_tw_recycle nebo zvýšením ip_conntrack_max být větší než počet místních portů zpřístupněných pro připojení pomocí ip_local_port_range . Myslím, že jakmile je jádro mimo místní porty, začne recyklovat připojení. To využívá více připojení pro sledování paměti, ale zdá se to jako lepší řešení než zapínání tcp_tw_recycle protože dokumenty naznačují, že je to nebezpečné.
S touto konfigurací mohu běžet ab celý den a nikdy mi nedojdou připojení:
net.ipv4.netfilter.ip_conntrack_max = 32768
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192
net.ipv4.ip_local_port_range = 32768 61000
tcp_max_orphans nastavení nemělo žádný vliv na mé testy a nevím proč. Myslím, že by to uzavřelo spojení v TIME_WAIT stav, kdy jich bylo 8192, ale to mi nedělá.
Řešení 2:
Opravdu se chcete podívat na to, co vám v tomto ohledu může nabídnout souborový systém /proc.
- Průvodce laděním TCP na ministerstvu energetiky USA
- Parametry ladění TCP pro různé operační systémy
- IBM „Spravujte Linux za běhu“
- Dokumentace na LinuxInsight.com vis-a-vis /proc/sys/net/ipv4
Na této poslední stránce by vás mohly zajímat následující:
- /proc/sys/net/ipv4/tcp_max_orphans, který řídí maximální počet soketů držených systémem ne připoutaný k něčemu. Zvýšení může spotřebovat až 64 kbajtů nevyměnitelné paměti na osiřelý soket .
- /proc/sys/net/ipv4/tcp_orphan_retries, který řídí počet opakování, než bude soket osiřen a uzavřen. Na této stránce je konkrétní poznámka o webových serverech, která vás přímo zajímá...
Řešení 3:
Nemyslím si, že existuje laditelný nástroj, který by to nastavil přímo. To spadá do kategorie ladění TCP/IP. Chcete-li zjistit, co můžete vyladit, vyzkoušejte 'man 7 tcp'. K jejich nastavení se používá sysctl ( 'man 8 sysctl' ). 'sysctl -a | grep tcp' vám ukáže většinu toho, co můžete naladit, ale nejsem si jistý, zda zobrazí všechny. Pokud se to nezměnilo, otevřené sokety TCP/IP vypadají jako deskriptory souborů. Takže tato a další sekce v tomto odkazu může být to, co hledáte.
Řešení 4:
Zkuste také nastavit následující nastavení tcp_fin_timeout. Toto by mělo být ukončeno o TIME_WAIT rychleji.
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
Řešení 5:
Zásobní apache(1) se dříve dodával předdefinovaný tak, aby podporoval pouze 250 souběžných připojení – pokud jste chtěli více, existoval jeden hlavičkový soubor, který bylo třeba upravit, aby umožňoval více souběžných relací. Nevím, jestli to platí i pro Apache 2.
Také musíte přidat možnost, která umožní spoustu více otevřených deskriptorů souborů pro účet, na kterém běží Apache – něco, na co předchozí komentáře nedokázaly poukázat.
Věnujte pozornost nastavení svého pracovníka a tomu, jaké časové limity pro udržení aktivity máte uvnitř samotného Apache, kolik rezervních serverů máte spuštěných najednou a jak rychle se tyto extra procesy zabíjejí.