Sorry for the spam. One more link to a tuning guide that I have found useful: https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf
On Sat, Nov 25, 2017 at 10:04 PM, Igor Mitrofanov <igor.n.mitrofa...@gmail.com> wrote: > After reading every paper and post on sysctl.conf and iptables tuning > I could find, and reading some kernel code, I have come to a > conclusion that, while there are a few settings to tune (can share > mine, but your mileage *will* vary), most of the defaults are actually > not broken in the latest kernels, while a lot of tuning > recommendations online are outdated. > > I enjoyed this guide a lot: > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html-single/performance_tuning_guide/index. > It is written for Red Hat, but contains quite a few insights > applicable to all Linux distributions. > > - Igor > > > On Sat, Nov 25, 2017 at 3:14 PM, Dhalgren Tor <dhalgren....@gmail.com> wrote: >>>Well, it's still going on, and is pretty much ruining Libero :( . Running >>>CentOS 6, here. >>> >>>When it's happening it can look like this: >>> >>># netstat -n | grep -c SYN >>>17696 >> >> I run a fast exit and can offer some advice: >> >> 1) mitigate bug #18580 (also #21394); is a DNS denial-of-service and >> could be the problem. either upgrade to 0.3.2.4+ or edit resolve.conf >> per >> https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver#TuningeventdnscomponentofTorDaemon >> >> also check out https://arthuredelstein.net/exits/ >> >> 2) if you continue to experience excessive outbound scanning SYNs, >> I've found that simply enabling connection tracking helps by >> implicitly limiting the rate a which connections can originate. If an >> iptables "-m state --state ESTABLISHED,RELATED -j ACCEPT" rule exists >> it will turn it on or you could modprobe the module if you don't want >> to configure incoming connection rules. >> >> some useful sysctl.conf changes, run sysctl -p after or reboot >> >> # Tor Exit tuning. >> net.ipv4.ip_local_port_range = 1025 65535 >> net.ipv4.tcp_synack_retries = 2 >> net.ipv4.tcp_max_tw_buckets = 4194304 >> net.ipv4.tcp_tw_recycle = 1 >> net.ipv4.tcp_fin_timeout = 30 >> net.ipv4.tcp_keepalive_time = 300 >> net.ipv4.tcp_keepalive_intvl = 10 >> net.ipv4.tcp_keepalive_probes = 3 >> net.netfilter.nf_conntrack_tcp_timeout_established = 1000 >> net.netfilter.nf_conntrack_checksum = 0 >> >> you might see many messages: >> >> kernel: nf_conntrack: table full, dropping packet >> >> which indicates no connection table slots were available for an >> outbound connection and that rate limiting is effected >> >> state of connection tracking appears in /proc/net/nf_conntrack >> _______________________________________________ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays