sigh. remove this bullshit and start over.
* Steve Johnson <maill...@sjohnson.info> [2011-02-01 22:38]: > Ok, thanks for the tips. I did not have any ifq drops, but have still just > increased the net.inet.icmp.errppslimit to 10000 (from the 1000 that was > before and shown below) and will see if that helps anything. Thanks also for > the clarification on the match counter. > > I had forgotten to also include the sysctl changes that I had made as well, > mostly based from calomel.org, which were the following: > > kern.maxclusters=128000 > net.inet.icmp.errppslimit=1000 > net.inet.ip.ifq.maxlen=1536 > net.inet.ip.mtudisc=0 > net.inet.ip.ttl=254 > net.inet.ipcomp.enable=1 > net.inet.tcp.ackonpush=1 > net.inet.tcp.ecn=1 > net.inet.tcp.mssdflt=1472 > net.inet.tcp.recvspace=262144 > net.inet.tcp.rfc1323=1 > net.inet.tcp.rfc3390=1 > net.inet.tcp.sack=1 > net.inet.tcp.sendspace=262144 > net.inet.udp.recvspace=262144 > net.inet.udp.sendspace=262144 > vm.swapencrypt.enable=1 > > On Tue, Feb 1, 2011 at 3:15 PM, Henning Brauer <lists-open...@bsws.de>wrote: > > > * Steve Johnson <maill...@sjohnson.info> [2011-02-01 20:35]: > > > I currently have a system that has no match rule in the ruleset, but that > > > uses tables for a big chunk of the traffic, including our monitoring > > station > > > that has a pretty high SNMP request rate. That system has a state table > > that > > > usually stabilizes between 15-20K sessions, with a session search rate of > > > around 10K. The states limit has been raised to 100000 and the frags to > > > 10000, but all other limits are set to default values. > > > > you can increase that much more. the times where kmem was a very > > scarce ressource are long over. > > > > > However, the "match" > > > counter always states a rate between 199/200 per second. > > > > the counter has nothing to do with match rules. it is increased any > > time a rule matches, regardless of the type. > > > > > During some heavy > > > traffic period, we are getting some failures from the monitoring system > > and > > > the only thing that seems possibly out of health for the system is the > > match > > > counter rate. System processor and memory are fine and there is no other > > > noticeable impact, but clearly the monitoring tool is seeing an impact, > > as > > > it didn't reflect something this behavior before we implemented the PF > > > systems. > > > > you might hit some other limit, not necessarily pf. start with > > checking sysctl net.inet.ifq - in particular drops, and increase > > maxlen if you see it increasing. > > depending on how you monitor you might also run into the icmp err rate > > limit, play with the net.inet.icmp.errppslimit sysctl. > > > > -- > > Henning Brauer, h...@bsws.de, henn...@openbsd.org > > BS Web Services, http://bsws.de > > Full-Service ISP - Secure Hosting, Mail and DNS Services > > Dedicated Servers, Rootservers, Application Hosting > -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
