iptables out of memory?

Kevin D. Clark kevin_d_clark at comcast.net
Fri Jan 30 18:23:56 EST 2009


Alan Johnson writes:

> 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 UTSL'd through the source code and I will concur with your
interpretation of %si.

> 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.

I find this to be puzzling, because I do not believe that iptables
operates in interrupt context.  The interrupts should be serviced as
quickly as they always are.  The only way that I could envision %si
going up like this would be if there was some strange bug that
prevented the interrupt handler from putting the skb on the queue (or
dropping them on the floor...) while iptables was processing your
gigantic ruleset.

Regards,

--kevin
-- 
GnuPG ID: B280F24E                Meet me by the knuckles
alumni.unh.edu!kdc                of the skinny-bone tree.
http://kdc-blog.blogspot.com/     -- Tom Waits



More information about the gnhlug-discuss mailing list