Difference between revisions of "Linux Performance and Tuning Tricks"
m |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | <seo title="Linux Performance and Tuning Tricks | Tuning Linux Kernel" titlemode="replace" keywords="GStreamer, Linux SDK, Linux BSP, Embedded Linux, Device Drivers, Nvidia, Xilinx, TI, NXP, Freescale, Embedded Linux driver development, Linux Software development, Embedded Linux SDK, Embedded Linux Application development, GStreamer Multimedia Framework." description="RidgeRun explains how the Linux operating system manages system resources, how to tune I/O performance & more. Check out this performance & tuning guide!"></seo> | ||
| + | |||
=Introduction= | =Introduction= | ||
| − | Usually the biggest bottlenecks for performance | + | Usually the biggest bottlenecks for processes performance are the I/O operations mainly on memory, disk and network. There are several parameters and criteria available to tune the Linux kernel according with specific application requirements. Tuning Linux kernel is a challenging task specially because it requires in-depth understanding of the hardware, operating system, and application. The references bellow offer useful information describing how Linux operating system manages system resources, important performance metrics that are needed to quantify system performance and how to tune I/O performance, task scheduler, memory management subsystem and network. |
= Tuning Write/Read memory operations = | = Tuning Write/Read memory operations = | ||
| Line 13: | Line 15: | ||
* /proc/sys/vm/dirty_ratio | * /proc/sys/vm/dirty_ratio | ||
When this is exceeded, applications that want to write to the pagecache are blocked and start performing writeback as well. Default: 20% | When this is exceeded, applications that want to write to the pagecache are blocked and start performing writeback as well. Default: 20% | ||
| + | <pre> | ||
| + | echo 3 > /proc/sys/vm/dirty_ratio | ||
| + | </pre> | ||
| + | |||
* /proc/sys/vm/dirty_expire_centisecs | * /proc/sys/vm/dirty_expire_centisecs | ||
This defines the interval between writeback operations. Default: 3000 | This defines the interval between writeback operations. Default: 3000 | ||
| + | <pre> | ||
| + | echo 200 > /proc/sys/vm/dirty_expire_centisecs | ||
| + | </pre> | ||
It's recommendable to modify only one of the previous tuning parameters. | It's recommendable to modify only one of the previous tuning parameters. | ||
| + | |||
| + | Sometimes tuning these parameters is not sufficient and more aggressive decisions have to be made. Changing the file system is one of them, as it's explained in this page: [[High performance SD card tuning using the EXT4 file system | High performance SD card tuning using the EXT4 file system]] | ||
==Readahead== | ==Readahead== | ||
When a process reads sequentially a file the kernel starts reading some data in advance to reduce the amount of time that a process have to wait for data to be available, so this parameter sets the maximum amount of data that the kernel reads ahead for a single file. Also, the actual amount of data being read in advance is computed dynamically, based on how much "sequential" the I/O seems to be. This is why for large video files it's needed to increase the maximum amount of data to be read ahead in order to display large videos properly. | When a process reads sequentially a file the kernel starts reading some data in advance to reduce the amount of time that a process have to wait for data to be available, so this parameter sets the maximum amount of data that the kernel reads ahead for a single file. Also, the actual amount of data being read in advance is computed dynamically, based on how much "sequential" the I/O seems to be. This is why for large video files it's needed to increase the maximum amount of data to be read ahead in order to display large videos properly. | ||
| + | |||
| + | For example, a simple GStreamer pipeline to decode and display large video files may present performance problems (eg. stopping for a while each undefined quantity of minutes) that can be fixed tuning the memory management subsystem in order to avoid processes waiting for data to be available. | ||
* /sys/block/<bdev>/queue/read_ahead_kb | * /sys/block/<bdev>/queue/read_ahead_kb | ||
This parameter sets the maximum amount of data that the kernel reads ahead for a single file. Default: 128KB | This parameter sets the maximum amount of data that the kernel reads ahead for a single file. Default: 128KB | ||
| + | <pre> | ||
| + | echo 640 > /sys/block/mmcblk0/queue/read_ahead_kb | ||
| + | </pre> | ||
=References= | =References= | ||
| Line 29: | Line 45: | ||
* http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.memory.html | * http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.memory.html | ||
* http://www.redbooks.ibm.com/redpapers/pdfs/redp4285.pdf | * http://www.redbooks.ibm.com/redpapers/pdfs/redp4285.pdf | ||
| + | |||
| + | [[Category:Whitepaper]][[Category:RidgeRunTechnology]] | ||
Latest revision as of 06:28, 25 August 2017
Contents
Introduction
Usually the biggest bottlenecks for processes performance are the I/O operations mainly on memory, disk and network. There are several parameters and criteria available to tune the Linux kernel according with specific application requirements. Tuning Linux kernel is a challenging task specially because it requires in-depth understanding of the hardware, operating system, and application. The references bellow offer useful information describing how Linux operating system manages system resources, important performance metrics that are needed to quantify system performance and how to tune I/O performance, task scheduler, memory management subsystem and network.
Tuning Write/Read memory operations
Writeback
While writing files, there are cache pages becoming dirty, each amount of time or once dirty memory reaches a percentage of RAM, the kernel starts doing writeback. If dirty data reaches a critical percentage of RAM, processes begin to be throttled to prevent dirty data exceeding this threshold.
Writeback tuning parameters:
- /proc/sys/vm/dirty_background_ratio
When the amount of dirty pagecache exceeds this percentage, writeback threads start writing back dirty memory. Default: 10%
- /proc/sys/vm/dirty_ratio
When this is exceeded, applications that want to write to the pagecache are blocked and start performing writeback as well. Default: 20%
echo 3 > /proc/sys/vm/dirty_ratio
- /proc/sys/vm/dirty_expire_centisecs
This defines the interval between writeback operations. Default: 3000
echo 200 > /proc/sys/vm/dirty_expire_centisecs
It's recommendable to modify only one of the previous tuning parameters.
Sometimes tuning these parameters is not sufficient and more aggressive decisions have to be made. Changing the file system is one of them, as it's explained in this page: High performance SD card tuning using the EXT4 file system
Readahead
When a process reads sequentially a file the kernel starts reading some data in advance to reduce the amount of time that a process have to wait for data to be available, so this parameter sets the maximum amount of data that the kernel reads ahead for a single file. Also, the actual amount of data being read in advance is computed dynamically, based on how much "sequential" the I/O seems to be. This is why for large video files it's needed to increase the maximum amount of data to be read ahead in order to display large videos properly.
For example, a simple GStreamer pipeline to decode and display large video files may present performance problems (eg. stopping for a while each undefined quantity of minutes) that can be fixed tuning the memory management subsystem in order to avoid processes waiting for data to be available.
- /sys/block/<bdev>/queue/read_ahead_kb
This parameter sets the maximum amount of data that the kernel reads ahead for a single file. Default: 128KB
echo 640 > /sys/block/mmcblk0/queue/read_ahead_kb
