possible ideas for new GENERIC kernel on UP systems

Chris chrcoluk at gmail.com
Thu Mar 3 21:37:23 GMT 2005


I made a post earlier in the month about my concerns with 5.3 and I
reffered to 2 of my servers having tcp lockups, but on the most
problematic service I made some changes to the kernel and so far it
has been running very good network wise.

 9:26PM  up 28 days,  1:01, 1 user, load averages: 0.16, 0.17, 0.16
FreeBSD 5.3-STABLE #0: Thu Feb  3 15:48:42 GMT 2005

Now the server is a celeron 2ghz realtek network card on a 100mbit
connection, its average load is 1500 simultaneous connections, handles
average sustained traffic of 0.5mbit-1mbit/sec and often has to burst
to over 20mbit.  During this time it has also taken around half a
dozen DDOS attacks using 100% network utilisation.

My kernel config (not full paste but whats diff to normal GENERIC)

cpu             I686_CPU (others removed)

options        AHC_REG_PRETTY_PRINT - disabled
options        AHD_REG_PRETTY_PRINT - disabled
options        ADAPTIVE_GIANT - disabled (*)
device         apic - disabled (*)
device         sl - disabled
device         ppp - disabled

new options
options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=50
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         IPFIREWALL_FORWARD
options         IPDIVERT
options         IPSTEALTH
options         DUMMYNET
options         TCP_DROP_SYNFIN
options         HZ=1000
options         NO_ADAPTIVE_MUTEXES (*)
options         CPU_ENABLE_SSE
options         SC_DISABLE_REBOOT
options         SC_NO_HISTORY
options         DEVICE_POLLING

* = I think these 3 things are what has greatly improved the stability
of the server, the other changes listed are for different reasons
other then stability but I showed them so others know what I am
running with.  Are adaptive_giant and adaptive mutexes advantageous to
UP systems?

Note - also hardware devices disabled in kernel not in server, device
polling in kernel but not activated, cpu_enable_sse probably useless
line.


More information about the freebsd-stable mailing list