sysctl and you

If you have a Gig connection on your Linux server, your O/S might be robbing you of power. Try this out to start with, if it doesn’t work, reboot and your server will default back to their original settings

sysctl -w net.core.rmem_max=8388608
sysctl -w net.core.wmem_max=8388608
sysctl -w net.core.rmem_default=65536
sysctl -w net.core.wmem_default=65536
sysctl -w net.ipv4.tcp_rmem=’4096 87380 8388608′
sysctl -w net.ipv4.tcp_wmem=’4096 65536 8388608′
sysctl -w net.ipv4.tcp_mem=’8388608 8388608 8388608′
sysctl -w net.ipv4.route.flush=1

THP (Transparent Huge Pages)

According to RedHat
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge

I usually use THP and this can be enabled very easily within the running system by issuing

echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo always > /sys/kernel/mm/transparent_hugepage/defrag

With the above I always set the nr_hugepages to 512 or for smaller systems 128.

echo 512 > /proc/sys/vm/nr_hugepages

Kernel params used for synfloods

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 45 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_recv
echo 3 > /proc/sys/net/ipv4/tcp_synack_retries
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

I tried to use these common values to help deter a syn flood from occurring. Syn-cookies challenges the other opponent. While you change the default timing of syn_recv from 60 seconds to 45 seconds which would also be the equivalent of 3 tcP_synack_retries.

Last but not least, reuse that old ttimewait port. 🙂

Getting tired of a Synflood?

This dirty last ditch modification to the kernel will force close connections after so many seconds. The default is 60.

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

This will tell everyone that you have 30 seconds to finish or else I will drop your connection. This is good in a pinch, but do not recommend running this at all times.

Instant kernel panic

After researching what could cause an instant kernel panic with no documentation or messages in kdump, I found that if manually execute the following code (warning: will cause system disruption, I am not held responsible for your copy and pasting):

echo c > /proc/sysrq-trigger

More information regarding this can be found on the Old Internet Archives at https://web.archive.org/web/20160816230132/https://www.kernel.org/doc/Documentation/sysrq.txt

while loop (true)

Need to execute a set of commands in a loop, non-stop?

while true; do killall -9 program; sleep 3; done

This will tell your Linux O/S do killall -9, sleep for 3 seconds, and start it again. This is great if you don’t have access to a crontab or just need it for a quick fix.

named-checkzone

Do you need to check the zone file syntax via command line after making a change. You can run the following:

named-checkzone domain.com /var/named/domain.com.db

Results should be similar to

zone domain.com/IN: loaded serial 20190xxxxx
OK