Last active
March 25, 2017 11:46
-
-
Save giovtorres/3d4429d53fc98c315a0e41c179ea1bd2 to your computer and use it in GitHub Desktop.
Custom Sysctl settings
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# WARNING: know why you are changing every single sysctl option. Do not blindly change them. | |
# You need to understand the effects of each setting. For some settings, you may want to | |
# increment until errors subside, rather than increasing the values to their max values. | |
# References: | |
# https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf | |
# https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt | |
# Red Hat Tuned profiles | |
# Adapter Queue | |
# Maximum number of packets taken from all interfaces in one polling cycle | |
# (NAPI poll). In one polling cycle interfaces which are registered to polling | |
# are probed in a round-robin manner. | |
# Default: 300 | |
# check for increments in third column of /proc/net/softnet_stat | |
net.core.netdev_budget = 10000 | |
# Adapter Queue | |
# The netdev_max_backlog is a queue within the Linux kernel where traffic is | |
# stored after reception from the NIC, but before processing by the protocol | |
# stacks (IP, TCP, etc.). There is one backlog queue per CPU core. A given | |
# core's queue can grow automatically, containing a number of packets up to the | |
# maximum specified by the netdev_max_backlog setting. The netif_receive_skb() | |
# kernel function will find the corresponding CPU for a packet, and enqueue | |
# packets in that CPU's queue. If the queue for that processor is full and | |
# already at maximum size, packets will be dropped. | |
# Default: 1000 | |
# check for increments in second column of /proc/net/softnet_stat | |
net.core.netdev_max_backlog = 100000 | |
# TCP Listen Backlog | |
# When a TCP socket is opened by a server in LISTEN state, that socket has a | |
# maximum number of unaccepted client connections it can handle. If an | |
# application is slow at processing client connections, or the server gets may | |
# new connections rapidly (commonly known as SYN flood), the new connections | |
# may be lost of specially crafted reply packets known as "SYN cookies" may be | |
# sent. Tune the system to avoid them. | |
# Default: 128 | |
# check /var/log/messages for SYN cookies | |
# check for increments in `netstat -s | grep "listen queue of a socket overflowed"` | |
net.core.somaxconn = 2048 | |
# TCP Buffer Tuning | |
# Once network traffic is process from the network adapter, reception directly | |
# into the application is attempted. If that is not possible, data is queued | |
# on the applications socket buffer. If the receive queue is full, the TCP | |
# stack will call a routing which "collapses" the receive queue. If collapsing | |
# fails to free sufficient space for additional traffic, then data is "pruned", | |
# i.e. data is dropped from memory and the packet is lost. Tune around this | |
# condition to avoide the buffer collapsing and pruning altogether. | |
# Default: 4096 87380 2916352 | |
# check for increments in `netstat -s | egrep '(prune|collapse)'` | |
net.ipv4.tcp_rmem = 4096 87380 16777216 | |
# UDP Buffer Tuning | |
# The only available tuning for UDP comprises of increasing the receive buffer | |
# size. If netstat -us reports UDP "packet receive errors", tune the buffer. | |
# Default: 124928 | |
# check for increments in `netstat -s | grep "packet receive errors"` under UDP stats | |
net.core.rmem_max = 16777216 | |
# Maximizing I/O Throughput | |
# Minimal preemption granularity for CPU-bound tasks: | |
# (default: 1 msec# (1 + ilog(ncpus)), units: nanoseconds) | |
kernel.sched_min_granularity_ns = 10000000 | |
# SCHED_OTHER wake-up granularity. | |
# (default: 1 msec# (1 + ilog(ncpus)), units: nanoseconds) | |
# | |
# This option delays the preemption effects of decoupled workloads | |
# and reduces their over-scheduling. Synchronous workloads will still | |
# have immediate wakeup/sleep latencies. | |
kernel.sched_wakeup_granularity_ns = 15000000 | |
# If a workload mostly uses anonymous memory and it hits this limit, the entire | |
# working set is buffered for I/O, and any more write buffering would require | |
# swapping, so it's time to throttle writes until I/O can catch up. Workloads | |
# that mostly use file mappings may be able to use even higher values. | |
# | |
# The generator of dirty data starts writeback at this percentage (system default | |
# is 20%) | |
vm.dirty_ratio = 40 | |
# Filesystem I/O is usually much more efficient than swapping, so try to keep | |
# swapping low. It's usually safe to go even lower than this on systems with | |
# server-grade storage. | |
vm.swappiness = 10 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment