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.
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:
When the amount of dirty pagecache exceeds this percentage, writeback threads start writing back dirty memory. Default: 10%
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
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
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.
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
联系客服
