iptables out of memory?

Alan Johnson alan at datdec.com
Thu Jan 29 17:29:17 EST 2009


On Thu, Jan 22, 2009 at 5:43 PM, Ben Scott <dragonhawk at gmail.com> wrote:

> On Thu, Jan 22, 2009 at 5:19 PM, Alan Johnson <alan at datdec.com> wrote:
>  I doubt it's simple RAM.  For one, CPU time will start to matter
> with that many rules, and no matter how fast your CPU, doing 123,000
> distinct compares for each and every packet received is going to drag
> things down.  There may also be limits (arbitrary, practical, or
> algorithmical) on internal kernel memory structures.


Yeah, I found that the cpu was getting worked pretty hard when the list gets
long.  The box in question has a P3.2Ghz with hyper-threading, that looks
like 2 CPUs, even though hyper-threading is not quite the same.  I saw %si
in top go to 50% (max out 1 cpu) so I looked up %si.  I found it defined as
the % of time spent handling system interrupts.

I also saw high load average at times of high %si, so I had chaulked it up
to a work-station grade processor not being able to handle a lot of context
switching.  Now, I've just cleared out iptables back to the default handful
of rules, and I see the %si back down to the usual <3%.  So, I'm guessing
that each packet comes in causes a system interrrupt and the more rules in
iptables, the more time it takes to process each interrupt.  I can't be sure
form these observations though, because the disk wait (%wa) also goes
through the roof when I clear out iptables.

%wa was the original battle, and I'm much happier with a CPU bottle neck
than a disk bottle neck.  CPU performace drops relativly linearly with load
compared to disk's exponential performance decay.

In any case, I think the way to go is to just flush iptables every few hours
rather than let stuff build-up in there even for 1 day.  That should give me
a happy medium and still stick it to the spammers pretty good.

I'll let you all know how it turns out.  Thanks for all the help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20090129/5e50f01c/attachment.html 


More information about the gnhlug-discuss mailing list