Difference between revisions of "OS: Tuning Kernel Scheduler"

From OnnoWiki
Jump to navigation Jump to search
Line 2: Line 2:
  
  
−
==Why tune a kernel?==
+
==Mengapa tune kernel?==
  
 
The default UNIX kernel behavior is suboptimal out of the box because it is difficult to anticipate what type of work or workload the operating system will be assigned. Therefore, UNIX products provide parameters that may change the allocation of critical resources. The kernel tuning parameters are UNIX product specific.
 
The default UNIX kernel behavior is suboptimal out of the box because it is difficult to anticipate what type of work or workload the operating system will be assigned. Therefore, UNIX products provide parameters that may change the allocation of critical resources. The kernel tuning parameters are UNIX product specific.
Line 173: Line 173:
 
  kernel.sem = 430 129000 430 300
 
  kernel.sem = 430 129000 430 300
 
  kernel.shmmni = 300
 
  kernel.shmmni = 300
−
  kernel.shmmax = 2147483648  
+
  kernel.shmmax = 2147483648
  
 
==Benchmark==
 
==Benchmark==

Revision as of 09:50, 8 March 2013

Sumber: http://www.techtinker.com/linux/LinuxKernel.html#HowRedHat


Mengapa tune kernel?

The default UNIX kernel behavior is suboptimal out of the box because it is difficult to anticipate what type of work or workload the operating system will be assigned. Therefore, UNIX products provide parameters that may change the allocation of critical resources. The kernel tuning parameters are UNIX product specific.

The system administrator is responsible to determine the target type of work and workload for a machine and to monitor whether either change over time. The system administrator should ensure that any tunable kernel parameters are set to optimize machine performance.

NOTE: Kernel tuning is an advanced topic and should not be done without a complete understanding of the subject. 

   How to tune Red Hat?

   The super user should configure the tunable parameters for the Red Hat Application Server 2.1 Linux kernel before installing Oracle9i or Oracle Applications 11i. If using an Oracle Development Services slot, the concurrent number of Oracle9i and Oracle 9iAS instances should be determined. The number of concurrent instances will enable validating whether the tunable kernel parameters are correctly configured.

Edit the /etc/sysctl.conf file.

The changes noted below should be made in the /etc/sysctl.conf file. If using a slot, log a bug to effect changes to a slot environment. Copy the following from the web page into the /etc/sysctl.conf file. Recalculate the numeric values and use the new values to edit the file. 

# -------------------------------------------------------------------------
# Kernel parameter assumptions and rationale.
# ===========================================
       #
       # Linux Advanced Server 2.1 has a configure restricted kernel.
       #
       # -------------------------------------------------------------------------
       # Disables packet forwarding
       # -------------------------------------------------------------------------

        net.ipv4.ip_forward = 0

       # -------------------------------------------------------------------------
       # Enables source route verification
       # -------------------------------------------------------------------------

        net.ipv4.conf.default.rp_filter = 1

       # -------------------------------------------------------------------------
       # Set the default local port range.
       # -------------------------------------------------------------------------

        net.ipv4.ip_local_port_range = 1024 65000

       # -------------------------------------------------------------------------
       # Enables the magic-sysrq key
       # -------------------------------------------------------------------------

        kernel.sysrq = 1

       # -------------------------------------------------------------------------
       # General semaphore rules:
       # -----------------------
       # 1. Semaphore tunable parameters are limited to semmsl, semmns,
       #    semopm and semmni and must be entered in the /etc/sysctl.conf
       #    file with the following syntax.
       #
       #    kernel.sem = semmsl semmns semopm semmni
       #
       # 2. The tunable kernel resource of semmsl sets the maximum number
       #    of semaphore per set. The semopm should be set equal to semmsl
       #    so that an operation can be performed on every semaphore in
       #    the set. If semopm is larger than semmsl it should raise an
       #    OS exception but doesn't in Linux.
       #
       #    Oracle8i Installation Manual for UNIX recommends this value be
       #    derived as "... the sum of the PROCESSES parameter for each
       #    Oracle database except the largest one, plus 2 times the largest
       #    PROCESSES value, plus 10 times the number of Oracle databases."
       #    Assuming 2 Oracle8i databases with the init{SID}.ora "processes"
       #    parameter set to 100 and 1 Oracle 9iAS server with "processes"
       #    parameter set to 100, the following is the recommended value:
       #
       #    Variables:
       #    =========
       #    s = sum of processes for all but largest instance
       #    m = maximum number of process for a single instance
       #    n = total number of instances
       #    i = n - largest instance.
       #
       #    semmsl = ((s * i) + (m * 2)) + (n * 10))
       #
       #    semmsl = ((100*2) + (100)*2) + (3 * 10)) = (400 + 30) = 430
       #
       #    semopm = semmsl = 430
       #
       # 3. The tunable kernel resource of semmni sets the system wide
       #    semaphore sets by creating a semid_ds control structure of
       #    84 bytes, so this parameter should not be set arbitrarily large.
       #    The Oracle8i and Oracle9i installation manual recommends 100
       #    for each Oracle instance. Assuming 2 Oracle8i databases with
       #    the init{SID}.ora processes parameter set to 100 and 1 Oracle
       #    9iAS server with processes parameter set to 100, the following
       #    is the recommended value:
       #
       #    semmni = 300
       #
       # 4. The semmsl (maximum number of semaphores per identifier) value
       #    is the product of the semmni and semmsl values, as qualified
       #    below:
       #
       #    semmns = (semmni * semmsl) = 300 * 430 = 129000
       #
       # 5. Therefore, semaphores should be set in the /etc/sysctl.conf
       #    file as follows:
       # -------------------------------------------------------------------------

        kernel.sem = 430 129000 430 300

       # -------------------------------------------------------------------------
       # General semaphore rules:
       # -----------------------
       # 1. The "Oracle9i Installation Guide, Release 2 (9.2.0.1.0) for
       #    UNIX Systems: AIX-Based Systems, Compaq Tru64 UNIX, HP 9000
       #    Series HP-UX, Linux Intel, and Sun Solaris" manual (A96167)
       #    advises default settings for shmmin, shmmni, shmseg and
       #    shmvmx shared memory kernel values.
       #
       # 2. The shmmin should be set to 1.
       #
       # 3. The shmmni memory variable sets the maximum number of
       #    system wide shmid_ds structures and should be equal to the
       #    value determined for semmni value.
       #
       #    shmmni = semmni = 300
       #
       # 4. The shmmax should be set to 50% of available memory or 2 GB but
       #    setting above 50% of available memory can cause some memory use
       #    issues in Oracle8i.
       #
       # 5. The shmmin, shmmsg and shmvmx cannot be set when using the
       #    Red Hat Advanced Server 2.1 because alteration of the kernel is
       #    not supported by Oracle and these typically tunable parameters
       #    are fixed in the supported and shipped kernels.
       #
       # -------------------------------------------------------------------------

        kernel.shmmni = 300
        kernel.shmmax = 2147483648

       # -------------------------------------------------------------------------
       # General File Management:
       # -----------------------
       # The default value of 8192 is not compatible with Oracle's file limit
       # of 65536 and should be changed to that value or higher provided memory
       # is available. For example, the typical rule-of-thumb is to divide real
       # memory by 16,384, or 64 simultaneous open files per 1 MB of memory.
       # In systems with large amounts of memory, concurrency of file access
       # would be a better rule-of-thumb. The value is set based on 2 GB of
       # real memory as follows below.
       #
       #    fs.file-max = ( 2,097,152,000 / 16384 ) = 128,000
       #
       # Using the 2.2.x Linux kernel you will need to set the inode-max
       # value to 4 to 5 times the file-max value. However, beginning with the
       # 2.4.x Linux kernel inode-max is managed dynamically and should not be
       # set in the /etc/sysctl.conf file.
       # -------------------------------------------------------------------------

        fs.file-max=128000

       Reboot to effect the changes.

       Validate kernel boot parameters.

       The following command enables validation of kernel parameters that are set in the /etc/sysctl.conf file that are processed at boot time.

sysctl -a | grep kernel

Hasilnya 

kernel.sysrq = 0
kernel.core_uses_pid = 1
kernel.sem = 430 129000 430 300
kernel.shmmni = 300
kernel.shmmax = 2147483648

Benchmark

Kernel tuning with sysctl

Sumber: http://archive09.linux.com/feature/146599

By Federico Kereki on September 09, 2008 (4:00:00 PM)

Share Print Comments

The Linux kernel is flexible, and you can even modify the way it works on the fly by dynamically changing some of its parameters, thanks to the sysctl command. Sysctl provides an interface that allows you to examine and change several hundred kernel parameters in Linux or BSD. Changes take effect immediately, and there's even a way to make them persist after a reboot. By using sysctl judiciously, you can optimize your box without having to recompile your kernel, and get the results immediately.

To start getting a taste of what sysctl can modify, run sysctl -a and you will see all the possible parameters. The list can be quite long: in my current box there are 712 possible settings.

$ sysctl -a kernel.panic = 0 kernel.core_uses_pid = 0 kernel.core_pattern = core kernel.tainted = 129 ...many lines snipped...

If you want to get the value of just a single variable, use something like sysctl vm.swappiness, or just sysctl vm to list all variables that start with "vm." Add the -n option to output just the variable values, without the names; -N has the opposite effect, and produces the names but not the values.

You can change any variable by using the -w option with the syntax sysctl -w variable=value. For example, sysctl -w net.ipv6.conf.all.forwarding=1 sets the corresponding variable to true (0 equals "no" or "false"; 1 means "yes" or "true") thus allowing IP6 forwarding. You may not even need the -w option -- it seems to be deprecated. Do some experimenting on your own to confirm that.

For more information, run man sysctl to display the standard documentation.

sysctl and the /proc directory

The /proc/sys virtual directory also provides an interface to the sysctl parameters, allowing you to examine and change them. For example, the /proc/sys/vm/swappiness file is equivalent to the vm.swappiness parameter in sysctl.conf; just forget the initial "/proc/sys/" part, substitute dots for the slashes, and you get the corresponding sysctl parameter. (By the way, the substitution is not actually required; slashes are also accepted, though it seems everybody goes for the notation with the dots instead.) Thus, echo 10 >/proc/sys/vm/swappiness is exactly the same as sysctl -w vm.swappiness=10. But as a rule of thumb, if a /proc/sys file is read-only, you cannot set it with sysctl either.

sysctl values are loaded at boot time from the /etc/sysctl.conf file. This file can have blank lines, comments (lines starting either with a "#" character or a semicolon), and lines in the "variable=value" format. For example, my own sysctl.conf file is listed below. If you want to apply it at any time, you can do so with the command sysctl -p.

  1. Disable response to broadcasts. net.ipv4.icmp_echo_ignore_broadcasts = 1 # enable route verification on all interfaces net.ipv4.conf.all.rp_filter = 1 # enable ipV6 forwarding net.ipv6.conf.all.forwarding = 1 # increase the number of possible inotify(7) watches fs.inotify.max_user_watches = 65536

Getting somewhere?

With so many tunable parameters, how do you decide what to do? Alas, this is a sore point with sysctl: most of the relevant documentation is hidden in the many source files of the Linux kernel, and isn't easily available, and it doesn't help that the explanations given are sometime arcane and difficult to understand. You may find something in the /usr/src/linux/Documentation/sysctl directory, but most (if not all) files there refer to kernel 2.2, and seemingly haven't been updated in the last several years.

Looking around for books on the subject probably won't help much. I found hack #71 in O'Reilly's Linux Server Hacks, Volume 2, from 2005, but that was about it. Several other books include references to sysctl, but as to specific parameters or hints, you are on your own.

As an experiment, I tried looking for information on the swappiness parameter, which can optimize virtual memory management. The /usr/src/Linux/Documentation/sysctl/vm.txt file didn't even refer to it, probably because this parameter appeared around version 2.6 of the kernel. Doing a general search in the complete /usr/src/linux directory turned up five files that mention "swappiness": three "include" (.h) files in include/linux, plus kernel/sysctl.c and mm/vmscan.c. The latter file included the information:

/* * From 0 .. 100. Higher means more swappy. */ int vm_swappiness = 60;

That was it! You can see the default value (60) and a minimal reference to the field meaning. How helpful is that?

My suggestion would be to use sysctl -a to learn the available parameters, then Google around for extra help. You may find, say, an example of changing the shared memory allocation to solve a video program problem, or an explanation on vm.swappiness, or even more suggestions for optimizing IP4 network traffic.

sysctl shows yet another aspect of the great flexibility of Linux systems. While documentation for it is not widely available, learning its features and capabilities on your own can help you get even more performance out of your box. That's system administration at its highest (or lowest?) level. Federico Kereki is an Uruguayan systems engineer with more than 20 years' experience developing systems, doing consulting work, and teaching at universities.


Referensi

I/O Scheduler

Pranala Menarik

Retrieved from "https://onnocenter.or.id/wiki/index.php?title=OS:_Tuning_Kernel_Scheduler&oldid=35670"