3 ms·

Really surprised this article doesn't mention tcp_tw_reuse or tcp_tw_recycle. These have a more substantial impact that simply adjusting TW, as those ports will

by meritt 14y ago

Really surprised this article doesn't mention tcp_tw_reuse or tcp_tw_recycle. These have a more substantial impact that simply adjusting TW, as those ports will still be in a FIN_WAIT status for a long time before reuse as well. Excellent article on the subject.: http://www.speedguide.net/articles/linux-tweaking-121 http://www.speedguide.net/articles/linux-tweaking-121

semenko 14y ago
Agreed. There are a lot of other possible optimizations, from the often-mentioned buffer size settings: net.core.rmem_max / net.core.wmem_max net.ipv4.tcp_rmem / net.ipv4.tcp_wmem to metric tunings like: net.ipv4.tcp_no_metrics_save / net.ipv4.tcp_moderate_rcvbuf I've been playing around with these settings on very loaded machines: # Retry SYN/ACK only three times, instead of five net.ipv4.tcp_synack_retries = 3 # Try to close things only twice net.ipv4.tcp_orphan_retries = 2 # FIN-WAIT-2 for only 5 seconds net.ipv4.tcp_fin_timeout = 5 # Increase syn socket queue size (default: 512) net.ipv4.tcp_max_syn_backlog = 2048 # One hour keepalive with fewer probes (default: 7200 & 9) net.ipv4.tcp_keepalive_time = 3600 net.ipv4.tcp_keepalive_probes = 5 # Max packets the input can queue net.core.netdev_max_backlog = 2500 # Keep fragments for 15 sec (default: 30) net.ipv4.ipfrag_time = 15 # Use H-TCP congestion control net.ipv4.tcp_congestion_control = htcp
- stock_toaster 14y ago
  have you noticed much of a change with htcp as the congestion control algo?
lazyjones 14y ago
tcp_tw_reuse and tcp_tw_recycle are dangerous. We have seen a significant number of connections from clients behind a NAT gateway being dropped with tcp_tw_recycle = 1.
- meritt 14y ago
  Absolutely use with caution and test extensively. Everyone one of these tweaks are tuning things at a very granular level and may cause more problems than help. Btw, the dropped clients has to do with recycle -- reuse is far 'safer', protocol speaking.
flojo 14y ago
I stand to correction but playing with tcp_tw_recycle, may cause dropped frames with load-balancing and NATs. Scroll down to 'Networking' and read the notice.
- flojo 14y ago
  Oops forgot the URL https://wiki.archlinux.org/index.php/Sysctl https://wiki.archlinux.org/index.php/Sysctl
harshreality 14y ago
On 2.6.3x, someone posted a year or two ago to one of the linux mailing lists demoing an ipv6 stack hang under high traffic when tcp_tw_recycle is set to true. Be very careful and test it yourself. edit: http://www.spinics.net/lists/netdev/msg154040.html http://www.spinics.net/lists/netdev/msg154040.html
bluesmoon 14y ago
thanks for the link. the article doesn't talk about those settings because I'd never tried them.

by meritt 14y ago

semenko 14y ago

Agreed. There are a lot of other possible optimizations, from the often-mentioned buffer size settings: net.core.rmem_max / net.core.wmem_max net.ipv4.tcp_rmem / net.ipv4.tcp_wmem to metric tunings like: net.ipv4.tcp_no_metrics_save / net.ipv4.tcp_moderate_rcvbuf I've been playing around with these settings on very loaded machines: # Retry SYN/ACK only three times, instead of five net.ipv4.tcp_synack_retries = 3 # Try to close things only twice net.ipv4.tcp_orphan_retries = 2 # FIN-WAIT-2 for only 5 seconds net.ipv4.tcp_fin_timeout = 5 # Increase syn socket queue size (default: 512) net.ipv4.tcp_max_syn_backlog = 2048 # One hour keepalive with fewer probes (default: 7200 & 9) net.ipv4.tcp_keepalive_time = 3600 net.ipv4.tcp_keepalive_probes = 5 # Max packets the input can queue net.core.netdev_max_backlog = 2500 # Keep fragments for 15 sec (default: 30) net.ipv4.ipfrag_time = 15 # Use H-TCP congestion control net.ipv4.tcp_congestion_control = htcp

stock_toaster 14y ago
have you noticed much of a change with htcp as the congestion control algo?

lazyjones 14y ago

tcp_tw_reuse and tcp_tw_recycle are dangerous. We have seen a significant number of connections from clients behind a NAT gateway being dropped with tcp_tw_recycle = 1.

meritt 14y ago
Absolutely use with caution and test extensively. Everyone one of these tweaks are tuning things at a very granular level and may cause more problems than help. Btw, the dropped clients has to do with recycle -- reuse is far 'safer', protocol speaking.

flojo 14y ago

I stand to correction but playing with tcp_tw_recycle, may cause dropped frames with load-balancing and NATs. Scroll down to 'Networking' and read the notice.

flojo 14y ago
Oops forgot the URL https://wiki.archlinux.org/index.php/Sysctl https://wiki.archlinux.org/index.php/Sysctl

harshreality 14y ago

On 2.6.3x, someone posted a year or two ago to one of the linux mailing lists demoing an ipv6 stack hang under high traffic when tcp_tw_recycle is set to true. Be very careful and test it yourself. edit: http://www.spinics.net/lists/netdev/msg154040.html http://www.spinics.net/lists/netdev/msg154040.html

bluesmoon 14y ago

thanks for the link. the article doesn't talk about those settings because I'd never tried them.