iptables out of memory?
Ben Scott
dragonhawk at gmail.com
Sun Jun 21 14:01:14 EDT 2009
On Sat, Jun 20, 2009 at 3:33 AM, Alan Johnson<alan at datdec.com> wrote:
> I have since learned that reiserfs ... is a total sloth on write
> performance.
It has been a number of years, but I dimly recall a few tips that
could much-improve ReiserFS write performance:
(1) Turn off tail packing. In ReiserFS, a "tail" is the last part of
a file, that usually doesn't need an entire allocation block on disk.
By default, ReiserFS will "pack" tails, meaning assemble tails from
multiple files into a single block. This eliminates slack space (AKA
internal fragmentation), but also kills performance when you write a
large number of small files -- like with Maildir.
I can't remember for sure if you have to remake the filesystem to turn
off tail packing or if this can be changed after the fact. I think it
could be changed after the fact. New tails won't be packed. Already
packed tails will still be packed, but that doesn't hurt write
performance.
(2) Mount the filesystem with the "noatime" option, so it doesn't
maintain last-accessed times. This is a generic mount option; it's
not really part of the filesystem. So you can change it at will.
(3) Examine your choice of hash algorithm. I forget exactly what this
does or means, but apparently one is faster than the other for some
things. Google for a FAQ. I'm pretty sure changing this means
remaking the filesystem, though.
(4) Reverse the polarity of the neutron flow. Oh, wait, no, that's
something else.
> ... iptables ... rules ... the number rarely exceeds 5 digits
That's still a heaping huge pile of rules. :) You really should
look into netblock aggregation if you're going to do this at the
firewall level. Or have your MTA drop TCP connects on open, based on
RBL DNS lookups. While any given instance of the MTA doing that will
be more expensive than a firewall rule, the fact that your kernel
isn't wasting time processing 10,000+ firewall rules with every packet
should be an overall win.
-- Ben
More information about the gnhlug-discuss
mailing list