Best Linux Kernel Parameters (Sysctl) Settings?
I was wondering what are the best settings for my 4 servers - here are the specs:
2 Quad core (8 CPUs)
Also what about TCP tuning? This is what I have so far - Thanks
# Kernel sysctl configuration file for Red Hat Linux
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 1
# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid = 1
# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 0
# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536
# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536
# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736
# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 30
# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time = 1800
# Turn off the tcp_window_scaling
net.ipv4.tcp_window_scaling = 0
# Turn off the tcp_sack
net.ipv4.tcp_sack = 0
# Turn off the tcp_timestamps
net.ipv4.tcp_timestamps = 0
Generally, I think you've picked good systems. Some people prefer more, smaller system for fault isolation and better $/GB on memory costs, but that very much depends.
Some of this depends on how you're planning to use the system, as the version and kind of client you use will affect whether you have lots of short lived connections or a lot of long lived connections. Those are the only situations where we sometimes need to adjust OS tuneables.
Also, some people care about throughput, others care about latency and tuneables for the two often oppose each other. We don't use shared memory, but it won't hurt to have it defined.
My general recommendation would be to use the out of the box defaults and do some testing with as close to a real live version of the app as you can. Then, measure how the system performs and decide which, if any, tuneables need adjustment. In many, many cases you won't need to adjust anything because you're just not operating at the edge or the out of the box settings are okay.