3 |
- |
1 |
# ktune sysctl settings for rhel6 servers with enterprise-class
|
|
|
2 |
# storage, maximizing i/o throughput
|
|
|
3 |
#
|
|
|
4 |
# Minimal preemption granularity for CPU-bound tasks:
|
|
|
5 |
# (default: 1 msec# (1 + ilog(ncpus)), units: nanoseconds)
|
|
|
6 |
kernel.sched_min_granularity_ns = 10000000
|
|
|
7 |
|
|
|
8 |
# SCHED_OTHER wake-up granularity.
|
|
|
9 |
# (default: 1 msec# (1 + ilog(ncpus)), units: nanoseconds)
|
|
|
10 |
#
|
|
|
11 |
# This option delays the preemption effects of decoupled workloads
|
|
|
12 |
# and reduces their over-scheduling. Synchronous workloads will still
|
|
|
13 |
# have immediate wakeup/sleep latencies.
|
|
|
14 |
kernel.sched_wakeup_granularity_ns = 15000000
|
|
|
15 |
|
|
|
16 |
# Filesystem I/O is usually much more efficient than swapping, so try to keep
|
|
|
17 |
# swapping low. It's usually safe to go even lower than this on systems with
|
|
|
18 |
# server-grade storage.
|
|
|
19 |
vm.swappiness = 30
|
|
|
20 |
|
|
|
21 |
# If a workload mostly uses anonymous memory and it hits this limit, the entire
|
|
|
22 |
# working set is buffered for I/O, and any more write buffering would require
|
|
|
23 |
# swapping, so it's time to throttle writes until I/O can catch up. Workloads
|
|
|
24 |
# that mostly use file mappings may be able to use even higher values.
|
|
|
25 |
#
|
|
|
26 |
# The generator of dirty data starts writeback at this percentage (system default
|
|
|
27 |
# is 20%)
|
|
|
28 |
vm.dirty_ratio = 40
|
|
|
29 |
|
|
|
30 |
# Start background writeback (via writeback threads) at this percentage (system
|
|
|
31 |
# default is 10%)
|
|
|
32 |
#vm.dirty_background_ratio = 15
|
|
|
33 |
|
|
|
34 |
# PID allocation wrap value. When the kernel's next PID value
|
|
|
35 |
# reaches this value, it wraps back to a minimum PID value.
|
|
|
36 |
# PIDs of value pid_max or larger are not allocated.
|
|
|
37 |
#
|
|
|
38 |
# A suggested value for pid_max is 1024 * <# of cpu cores/threads in system>
|
|
|
39 |
# e.g., a box with 32 cpus, the default of 32768 is reasonable, for 64 cpus,
|
|
|
40 |
# 65536, for 4096 cpus, 4194304 (which is the upper limit possible).
|
|
|
41 |
#kernel.pid_max = 65536
|