Mysterious reboot

[Giorgos Keramidas]

On 2006-02-16 15:18, Mike Loiterman <mike at ascendency.net> wrote:
>Giorgos Keramidas <mailto:keramida at ceid.upatras.gr> wrote:
>> On 2006-02-16 14:32, Mike Loiterman <mike at ascendency.net> wrote:
>>> Wouter Spierenburg <mailto:wouter at spierenburg.net> wrote:
>>>> Try adding the following to /etc/sysctl.conf:
>>>>
>>>> kern.maxfiles=65535
>>>> kern.maxfilesperproc=20000
>>>> net.inet.tcp.delayed_ack=0
>>>> net.inet.ip.maxfragpackets=10
>>>> kern.ipc.somaxconn=2048
>>>>
>>>> then 'cd' to /usr/src/sys/i386/conf
>>>> cp GENERIC SERVER
>>>> vi SERVER
>>>>
>>>> and add the following lines at the bottom of the file: options
>>>> TCPDEBUG options         RANDOM_IP_ID
>>>> options         TCP_DROP_SYNFIN
>>>> options         NMBCLUSTERS=65535
>>>> options         NMBUFS=40960
>>>>
[...]
>> I'm not sure if the options are useful for your setup, so I'm
>> not going to comment for or against them.
>
> Well, the server is an email/web server primarily.  Not a huge
> load, but I want to be hardened against DOS attacks...would
> these help?

kern.maxfiles and kern.masfilesperproc may need some tuning, but
you would have to look at other related sysctls to be sure that
you really need all those sizes, i.e.:

    # sysctl kern.openfiles

will provide a measure of how many files your system keeps open.
If this is too close to kern.maxfiles, you should definitely
increase kern.maxfiles a bit, to be able to handle a bigger load.

net.inet.tcp.delayed_ack may actually help for bulk transfers,
by sending a smaller amount of packets for TCP acknowledgements.

Reducing net.inet.ip.maxfragpackets so much will decrease the
memory amount used for keeping around fragments of packets, but
it also has the potential of increasing the number of fragments
that are dropped & retransmitted.  You should first look at:

    # sysctl net.inet.ip.fragpackets

to see how many fragments your system usually keeps around.

Increasing kern.ipc.somaxconn to 2048 will also require a bit
more memory, for keeping the state of 'sockets pending a
connection' around.  But it will also decrease the amount of
sockets that drop connections, potentially allowing more clients
to connect at about the same time without having their connection
being reset immediately.

TCPDEBUG is not really a good option for a production machine,
as it will probably slow things down a bit.

RANDOM_IP_ID is more secure than not having it, but it also puts
a bit more strain on the system by making frequent calls to the
random IP id generator.

TCP_DROP_SYNFIN has interesting comments in the `NOTES' files, so
use it with care.

NMBCLUSTERS and NMBUS can be probably optimized a bit, but first
you should take a look at the statistics of:

    # netstat -m
    258/387/645 mbufs in use (current/cache/total)
    256/134/390/17024 mbuf clusters in use (current/cache/total/max)
    576K/364K/941K bytes allocated to network (current/cache/total)
    0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
    0/0/0 sfbufs in use (current/peak/max)
    0 requests for sfbufs denied
    0 requests for sfbufs delayed
    0 requests for I/O initiated by sendfile
    0 calls to protocol drain routines

If the 'current' values are very close to 'total' or 'max', you
probably need to bump these a bit.