| Managing power consumption on Red Hat Enterprise Linux 6Edition 1.0 Red Hat Inc.Don DomingoRed Hat Engineering Content Services Rüdiger LandmannRed Hat Engineering Content Services Legal NoticeCopyright © 2010 Red Hat Inc.. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution-Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Java® is a registered trademark of Oracle and/or its affiliates. XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries. All other trademarks are the property of their respective owners.
1801 Varsity Drive
Raleigh, NC 27606-2072 USA
Phone: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701
Daftar IsiAbstract This document explains how to manage power consumption on Red Hat Enterprise Linux 6 systems effectively. The following sections discuss different techniques that lower power consumption (for both server and laptop), and how each technique affects the overall performance of your system. This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information. In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default. 1.1. Typographic ConventionsFour typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows. Mono-spaced Bold
Used to highlight system input, including shell commands, file names and paths. Also used to highlight keys and key combinations. For example: To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.
The above includes a file name, a shell command and a key, all presented in mono-spaced bold and all distinguishable thanks to context. Key combinations can be distinguished from an individual key by the plus sign that connects each part of a key combination. For example: Press Enter to execute the command. Press Ctrl+Alt+F2 to switch to a virtual terminal.
The first example highlights a particular key to press. The second example highlights a key combination: a set of three keys pressed simultaneously. If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in mono-spaced bold. For example: File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.
Proportional Bold This denotes words or phrases encountered on a system, including application names; dialog box text; labeled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example: Choose ⤍ ⤍ from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand). To insert a special character into a gedit file, choose ⤍ ⤍ from the main menu bar. Next, choose ⤍ from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose ⤍ from the gedit menu bar.
The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context. Mono-spaced Bold ItalicProportional Bold Italic
Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example: To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh [email protected]. The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home. To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release
Note the words in bold italics above - username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system. Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example: Publican is a DocBook publishing system.
1.2. Pull-quote ConventionsTerminal output and source code listings are set off visually from the surrounding text. Output sent to a terminal is set in mono-spaced roman and presented thus: books Desktop documentation drafts mss photos stuff svnbooks_tests Desktop1 downloads images notes scripts svgs Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows: package org.jboss.book.jca.ex1;import javax.naming.InitialContext;public class ExClient{ public static void main(String args[]) throws Exception { InitialContext iniCtx = new InitialContext(); Object ref = iniCtx.lookup("EchoBean"); EchoHome home = (EchoHome) ref; Echo echo = home.create(); System.out.println("Created Echo"); System.out.println("Echo.echo('Hello') = " + echo.echo("Hello")); }}Finally, we use three visual styles to draw attention to information that might otherwise be overlooked. Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier. Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled 'Important' will not cause data loss but may cause irritation and frustration. Warnings should not be ignored. Ignoring warnings will most likely cause data loss. 2. Getting Help and Giving FeedbackIf you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer Portal at http://access.redhat.com. Through the customer portal, you can: search or browse through a knowledgebase of technical support articles about Red Hat products. submit a support case to Red Hat Global Support Services (GSS). access other product documentation.
Red Hat also hosts a large number of electronic mailing lists for discussion of Red Hat software and technology. You can find a list of publicly available mailing lists at https://www.redhat.com/mailman/listinfo. Click on the name of any mailing list to subscribe to that list or to access the list archives. If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla: http://bugzilla.redhat.com/ against the product Red_Hat_Enterprise_Linux.When submitting a bug report, be sure to mention the manual's identifier: doc-Power_Management_Guide If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily. Power management has been one of our focus points for improvements for Red Hat Enterprise Linux 6. Limiting the power used by computer systems is one of the most important aspects of green IT (environmentally friendly computing), a set of considerations that also encompasses the use of recyclable materials, the environmental impact of hardware production, and environmental awareness in the design and deployment of systems. In this document, we provide guidance and information regarding power management of your systems running Red Hat Enterprise Linux 6. 1.1. Importance of Power ManagementAt the core of power management is an understanding of how to effectively optimize energy consumption of each system component. This entails studying the different tasks that your system performs, and configuring each component to ensure that its performance is just right for the job. The main motivator for power management is: The proper use of power management results in: heat reduction for servers and computing centers reduced secondary costs, including cooling, space, cables, generators, and uninterruptible power supplies (UPS) extended battery life for laptops lower carbon dioxide output meeting government regulations or legal requirements regarding Green IT, for example Energy Star meeting company guidelines for new systems
As a rule, lowering the power consumption of a specific component (or of the system as a whole) will lead to lower heat and naturally, performance. As such, you should thoroughly study and test the decrease in performance afforded by any configurations you make, especially for mission-critical systems. By studying the different tasks that your system performs, and configuring each component to ensure that its performance is just sufficient for the job, you can save energy, generate less heat, and optimize battery life for laptops. Many of the principles for analysis and tuning of a system in regard to power consumption are similar to those for performance tuning. To some degree, power management and performance tuning are opposite approaches to system configuration, because systems are usually optimized either towards performance or power. This manual describes the tools that Red Hat provides and the techniques we have developed to help you in this process. Red Hat Enterprise Linux 6 already comes with a lot of new power management features that are enabled by default. They were all selectively chosen to not impact the performance of a typical server or desktop use case. However, for very specific use cases where maximum throughput, lowest latency, or highest CPU performance is absolutely required, a review of those defaults might be necessary. To decide whether you should optimize your machines using the techniques described in this document, ask yourself a few questions: - Q: Must I optimize?
- Q: How much do I need to optimize?
- Q: Will optimization reduce system performance to an unacceptable level?
- Q: Will the time and resources spent to optimize the system outweigh the gains achieved?
A: The importance of power optimization depends on whether your company has guidelines that need to be followed or if there are any regulations that you have to fulfill. Q: How much do I need to optimize? A: Several of the techniques we present do not require you to go through the whole process of auditing and analyzing your machine in detail but instead offer a set of general optimizations that typically improve power usage. Those will of course typically not be as good as a manually audited and optimized system, but provide a good compromise. Q: Will optimization reduce system performance to an unacceptable level? A: Most of the techniques described in this document impact the performance of your system noticeably. If you choose to implement power management beyond the defaults already in place in Red Hat Enterprise Linux 6, you should monitor the performance of the system after power optimization and decide if the performance loss is acceptable. Q: Will the time and resources spent to optimize the system outweigh the gains achieved? A: Optimizing a single system manually following the whole process is typically not worth it as the time and cost spent doing so is far higher than the typical benefit you would get over the lifetime of a single machine. On the other hand if you for example roll out 10000 desktop systems to your offices all using the same configuration and setup then creating one optimized setup and applying that to all 10000 machines is most likely a good idea. The following sections will explain how optimal hardware performance benefits your system in terms of energy consumption. 1.2. Power Management BasicsEffective power management is built on the following principles: Because of this, the Linux kernel in Red Hat Enterprise Linux 6 eliminates the periodic timer: as a result, the idle state of a CPU is now tickless. This prevents the CPU from consuming unnecessary power when it is idle. However, benefits from this feature can be offset if your system has applications that create unnecessary timer events. Polling events (such as checks for volume changes, mouse movement, and the like) are examples of such events. SpeedStep PowerNow! Cool'n'Quiet ACPI (C state) Smart
If your hardware has support for these features and they are enabled in the BIOS, Red Hat Enterprise Linux 6 will use them by default. A CPU running on the lowest sleep state possible consumes the least amount of watts, but it also takes considerably more time to wake it up from that state when needed. In very rare cases this can lead to the CPU having to wake up immediately every time it just went to sleep. This situation results in an effectively permanently busy CPU and loses some of the potential power saving if another state had been used. Chapter 2. Power management auditing and analysis2.1. Audit and analysis overviewThe detailed manual audit, analysis, and tuning of a single system is usually the exception because the time and cost spent to do so typically outweighs the benefits gained from these last pieces of system tuning. However, performing these tasks once for a large number of nearly identical systems where you can reuse the same settings for all systems can be very useful. For example, consider the deployment of thousands of desktop systems, or a HPC cluster where the machines are nearly identical. Another reason to do auditing and analysis is to provide a basis for comparison against which you can identify regressions or changes in system behavior in the future. The results of this analysis can be very helpful in cases where hardware, BIOS, or software updates happen regularly and you want to avoid any surprises with regard to power consumption. Generally, a thorough audit and analysis gives you a much better idea of what is really happening on a particular system. Auditing and analyzing a system with regard to power consumption is relatively hard, even with the most modern systems available. Most systems do not provide the necessary means to measure power use via software. Exceptions exist though: the ILO management console of Hewlett Packard server systems has a power management module that you can access through the web. IBM provides a similar solution in their BladeCenter power management module. On some Dell systems, the IT Assistant offers power monitoring capabilities as well. Other vendors are likely to offer similar capabilities for their server platforms, but as can be seen there is no single solution available that is supported by all vendors. If your system has no inbuilt mechanism to measure power consumption, a few other choices exist. You could install a special power supply for your system that offers power consumption information through USB. The Gigabyte Odin GT 550 W PC power supply is one such example, and software to read out those values under Linux is available externally from http://mgmt.sth.sze.hu/~andras/dev/gopsu/. As a last resort, some external watt meters like the Watts up? PRO have a USB connector. Direct measurements of power consumption is often only necessary to maximize savings as far as possible. Fortunately, other means are available to measure if changes are in effect or how the system is behaving. This chapter describes the necessary tools. The introduction of the tickless kernel in Red Hat Enterprise Linux 6 (refer to Section 3.6, "Tickless Kernel") allows the CPU to enter the idle state more frequently, reducing power consumption and improving power management. The new PowerTOP tool identifies specific components of kernel and userspace applications that frequently wake up the CPU. PowerTOP was used in development to perform the audits described in Section 3.13, "Optimizations in User Space" that led to many applications being tuned in this release, reducing unnecessary CPU wake up by a factor of ten. Install PowerTOP with the command: yum install powertop
Run PowerTOP with the command: powertop
Note that you will need to run PowerTOP with root privileges to allow the application to do anything useful. When it runs, PowerTOP gathers statistics from the system and presents you with a list of the components that are sending wakeups to the CPU most frequently. PowerTOP also makes suggestions for tuning the system for lower power consumption. These suggestions appear at the bottom of the screen, and specify a key for you to press to accept PowerTOP's suggestion. As PowerTOP refreshes periodically, further suggestions appear. In Figure 2.1, "PowerTOP in Operation", note the suggestion to increase the VM dirty writeback time, and the key ( W) to press to accept the suggestion. When it runs, PowerTOP gathers statistics from the system and presents you with several important lists of information. At the top is a list of how long your CPU cores have been in each of the available C and P states. The longer the CPU stays in the higher C or P stats the better (C4 being higher than C3) and is a good indicator of how well the system is tuned towards CPU utilization. Your goal should be residency of 90% or more in the highest C or P state while the system is idle. The second piece of information is a summary of the actual wakeups per second of the machine. The number of wakeups per second gives you a good measure of how well the services or the devices and drivers of the kernel are performing with regard to power usage on your system. The more wakeups per second you have, the more power is consumed, so lower is better here. Next, PowerTOP provides an estimate of the actual power usage of the system, if available. Expect PowerTOP to report this figure on laptops while they are in battery mode. Any available estimates of power usage are followed by a detailed list of the components that send wakeups to the CPU most frequently. At the top of the list are those components that you should investigate more closely to optimize your system to reduce power usage. If they are kernel components, (indicated by the name of the component being listed in <>) then the wakeups are often associated with a specific driver that causes them. Tuning drivers most usually requires kernel changes which go beyond the scope of this document. However, userland processes that send wakeups are more easily managed. First, identify if this service or application should run at all on this system. If not, simply deactivate it. To turn off a service permanently, run: chkconfig servicename off
If you need more details about the what the component actually does, run: ps -awux | grep componentname strace -p processid
If the trace looks like it is repeating itself, then you probably have found a busy loop. To fix this would require a code change in that component and that again goes beyond the scope of this document. Finally, PowerTOP also makes suggestions for tuning the system for lower power consumption. These suggestions appear at the bottom of the screen, and specify a key for you to press to accept PowerTOP's suggestion. As PowerTOP refreshes periodically, further suggestions appear. In Figure 2.1, "PowerTOP in Operation", note the suggestion to increase the VM dirty writeback time, and the key ( W) to press to accept the suggestion. These changes will only be active until the next reboot. To help you make the changes permanent, PowerTOP displays the exact command it runs to perform this optimization. Add the command to your /etc/rc.local file with your preferred text editor so that it takes effect every time that the computer starts. 2.3. Diskdevstat and netdevstatDiskdevstat and netdevstat are SystemTap tools that collect detailed information about the disk activity and network activity of all applications running on a system. These tools were inspired by PowerTOP, which shows the number of CPU wakeups by every application per second (refer to Section 2.2, "PowerTOP"). The statistics that these tools collect allow you to identify applications that waste power with many small I/O operations rather than fewer, larger operations. Other monitoring tools that measure only transfer speeds do not help to identify this type of usage. Install these tools with SystemTap with the command: yum install systemtap tuned-utils kernel-debuginfo
Run the tools with the command: diskdevstat
or the command: netdevstat
Both commands can take up to three parameters, as follows: diskdevstat update_interval total_duration display_histogram
netdevstat update_interval total_duration display_histogram
update_intervalThe time in seconds between updates of the display. Default: 5 total_durationThe time in seconds for the whole run. Default: 86400 (1 day) display_histogramFlag whether to histogram for all the collected data at the end of the run.
The output resembles that of PowerTOP. Here is sample output from a longer diskdevstat run on a Fedora 10 system running KDE 4.2: PID UID DEV WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG READ_CNT READ_MIN READ_MAX READ_AVG COMMAND 2789 2903 sda1 854 0.000 120.000 39.836 0 0.000 0.000 0.000 plasma 15494 0 sda1 0 0.000 0.000 0.000 758 0.000 0.012 0.000 0logwatch 15520 0 sda1 0 0.000 0.000 0.000 140 0.000 0.009 0.000 perl 15549 0 sda1 0 0.000 0.000 0.000 140 0.000 0.009 0.000 perl 15585 0 sda1 0 0.000 0.000 0.000 108 0.001 0.002 0.000 perl 2573 0 sda1 63 0.033 3600.015 515.226 0 0.000 0.000 0.000 auditd 15429 0 sda1 0 0.000 0.000 0.000 62 0.009 0.009 0.000 crond 15379 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15473 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15415 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15433 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15425 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 15375 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15477 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 15469 0 sda1 0 0.000 0.000 0.000 62 0.007 0.007 0.000 crond 15419 0 sda1 0 0.000 0.000 0.000 62 0.008 0.008 0.000 crond 15481 0 sda1 0 0.000 0.000 0.000 61 0.000 0.001 0.000 crond 15355 0 sda1 0 0.000 0.000 0.000 37 0.000 0.014 0.001 laptop_mode 2153 0 sda1 26 0.003 3600.029 1290.730 0 0.000 0.000 0.000 rsyslogd 15575 0 sda1 0 0.000 0.000 0.000 16 0.000 0.000 0.000 cat 15581 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 15582 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 15579 0 sda1 0 0.000 0.000 0.000 12 0.000 0.001 0.000 perl 15580 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 15354 0 sda1 0 0.000 0.000 0.000 12 0.000 0.170 0.014 sh 15584 0 sda1 0 0.000 0.000 0.000 12 0.001 0.002 0.000 perl 15548 0 sda1 0 0.000 0.000 0.000 12 0.001 0.014 0.001 perl 15577 0 sda1 0 0.000 0.000 0.000 12 0.001 0.003 0.000 perl 15519 0 sda1 0 0.000 0.000 0.000 12 0.001 0.005 0.000 perl 15578 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 15583 0 sda1 0 0.000 0.000 0.000 12 0.001 0.001 0.000 perl 15547 0 sda1 0 0.000 0.000 0.000 11 0.000 0.002 0.000 perl 15576 0 sda1 0 0.000 0.000 0.000 11 0.001 0.001 0.000 perl 15518 0 sda1 0 0.000 0.000 0.000 11 0.000 0.001 0.000 perl 15354 0 sda1 0 0.000 0.000 0.000 10 0.053 0.053 0.005 lm_lid.sh The columns are: - PID
the process ID of the application - UID
the user ID under which the applications is running - DEV
the device on which the I/O took place - WRITE_CNT
the total number of write operations - WRITE_MIN
the lowest time taken for two consecutive writes (in seconds) - WRITE_MAX
the greatest time taken for two consecutive writes (in seconds) - WRITE_AVG
the average time taken for two consecutive writes (in seconds) - READ_CNT
the total number of read operations - READ_MIN
the lowest time taken for two consecutive reads (in seconds) - READ_MAX
the greatest time taken for two consecutive reads (in seconds) - READ_AVG
the average time taken for two consecutive reads (in seconds) - COMMAND
the name of the process
In this example, three very obvious applications stand out: PID UID DEV WRITE_CNT WRITE_MIN WRITE_MAX WRITE_AVG READ_CNT READ_MIN READ_MAX READ_AVG COMMAND 2789 2903 sda1 854 0.000 120.000 39.836 0 0.000 0.000 0.000 plasma 2573 0 sda1 63 0.033 3600.015 515.226 0 0.000 0.000 0.000 auditd 2153 0 sda1 26 0.003 3600.029 1290.730 0 0.000 0.000 0.000 rsyslogd These three applications have a WRITE_CNT greater than 0, which means that they performed some form of write during the measurement. Of those, plasma was the worst offender by a large degree: it performed the most write operations, and of course the average time between writes was the lowest. Plasma would therefore be the best candidate to investigate if you were concerned about power-inefficient applications. Use the strace and ltrace commands to examine applications more closely by tracing all system calls of the given process ID. In the present example, you could run: strace -p 2789
In this example, the output of the strace contained a repeating pattern every 45 seconds that opened the KDE icon cache file of the user for writing followed by an immediate close of the file again. This led to a necessary physical write to the hard disk as the file metadata (specifically, the modification time) had changed. The final fix was to prevent those unnecessary calls when no updates to the icons had occurred. 2.4. Battery Life Tool KitRed Hat Enterprise Linux 6 introduces the Battery Life Tool Kit ( BLTK), a test suite that simulates and analyzes battery life and performance. BLTK achieves this by performing sets of tasks that simulate specific user groups and reporting on the results. Although developed specifically to test notebook performance, BLTK can also report on the performance of desktop computers when started with the -a. BLTK allows you to generate very reproducible workloads that are comparable to real use of a machine. For example, the office workload writes a text, corrects things in it, and does the same for a spreadsheet. Running BLTK combined with PowerTOP or any of the other auditing or analysis tool allows you to test if the optimizations you performed have an effect when the machine is actively in use instead of only idling. Because you can run the exact same workload multiple times for different settings, you can compare results for different settings. Install BLTK with the command: yum install bltk
Run BLTK with the command: bltk workload options
For example, to run the idle workload for 120 seconds: bltk -I -T 120
The workloads available by default are: -I, --idlesystem is idle, to use as a baseline for comparison with other workloads -R, --readersimulates reading documents (by default, with Firefox) -P, --playersimulates watching multimedia files from a CD or DVD drive (by default, with mplayer) -O, --officesimulates editing documents with the OpenOffice.org suite
Other options allow you to specify: -a, --ac-ignoreignore whether AC power is available (necessary for desktop use) -T number_of_seconds, --time number_of_secondsthe time (in seconds) over which to run the test; use this option with the idle workload -F filename, --file filenamespecifies a file to be used by a particular workload, for example, a file for the player workload to play instead of accessing the CD or DVD drive -W application, --prog applicationspecifies an application to be used by a particular workload, for example, a browser other than Firefox for the reader workload
BLTK supports a large number of more specialized options. For details, refer to the bltk man page. BLTK saves the results that it generates in a directory specified in the /etc/bltk.conf configuration file - by default, ~/.bltk/workload.results.number/. For example, the ~/.bltk/reader.results.002/ directory holds the results of the third test with the reader workload (the first test is not numbered). The results are spread across several text files. To condense these results into a format that is easy to read, run: bltk_report path_to_results_directory
The results now appear in a text file named Report in the results directory. To view the results in a terminal emulator instead, use the -o option: bltk_report -o path_to_results_directory
Tuned is a daemon that monitors the use of system components and dynamically tunes system settings based on that monitoring information. Dynamic tuning accounts for the way that various system components are used differently throughout the uptime for any given system. For example, the hard drive is used heavily during startup and login, but is barely used later when a user might mainly work with applications like OpenOffice or email clients. Similarly, the CPU and network devices are used differently at different times. Tuned monitors the activity of these components and reacts to changes in their use. As a practical example, consider a typical office workstation. Most of the time, the Ethernet network interface will be very inactive. Only a few emails will go in and out every once in a while or some web pages might be loaded. For those kinds of loads, the network interface doesn't have to run at full speed all the time, as it does by default. Tuned has a monitoring and tuning plugin for network devices that can detect that low activity and then automatically lower the speed of that interface, typically resulting in lower power usage. If activity on the interface increases drastically for a longer period of time, for example because a DVD image is being downloaded or an email with a large attachment is opened, tuned detects this and sets the interface speed to maximum to offer the best performance while the activity level is so high. This principle is used for the other plugins for CPU and hard disks as well. Network devices are not configured to behave this way by default because speed changes can take several seconds to take effect and therefore directly and visibly impact the user experience. Similar considerations apply for the CPU and hard drive tuning plugins. When a hard drive has been spun down, it can take several seconds for it to spin up again which results in an observed lack of responsiveness of the system during that period. The latency side effect is smallest for the CPU plugin, but it is still at least measurable, though hardly noticeable by a user. Alongside of tuned we now also offer ktune. Ktune was introduced in Red Hat Enterprise Linux 5.3 as a framework and service to optimize the performance of a machine for a specific use cases. Since then, ktune has improved to such a degree that we now use it as the static part of our general tuning framework. It is mainly used in the different predefined profiles described in Section 2.5.2, "Tuned-adm". Install the tuned package and its associated systemtap scripts with the command: yum install tuned
Installing the tuned package also sets up a sample configuration file at /etc/tuned.conf and activates the default profile. Start tuned by running: service tuned start
To start tuned every time the machine boots, run: chkconfig tuned on
Tuned itself has additional options that you can use when you run it manually. The available options are: -d, --daemonstart tuned as a daemon instead of in the foreground. -c, --conffileuse a configuration file with the specified name and path, for example, --conffile=/etc/tuned2.conf. The default is /etc/tuned.conf. -D, --debuguse the highest level of logging.
2.5.1. The tuned.conf fileThe tuned.conf file contains configuration settings for tuned. By default, it is located at /etc/tuned.conf, but you can specify a different name and location by starting tuned with the --conffile option. The config file must always contain a [main] section that defines the general parameters for tuned. The file then contains a section for each plugin. The [main] section contains the following options: intervalthe interval at which tuned should monitor and tune the system, in seconds. The default value is 10. verbosespecifies whether output should be verbose. The default value is False. loggingspecifies the minimum priority of messages to be logged. In descending order, allowable values are: critical, error, warning, info, and debug. The default value is info. logging_disablespecifies the maximum priority of messages to be logged; any messages with this priority or lower will not be logged. In descending order, allowable values are: critical, error, warning, info, and debug. The value notset disables this option.
Each plugin has its own section, specified with the name of the plugin in square brackets; for example: [CPUTuning]. Each plugin can have its own options, but the following apply to all plugins: enabledspecifies whether the plugin is enabled or not. The default value is True. verbosespecifies whether output should be verbose. If not set for this plugin, the value is inherited from [main]. loggingspecifies the minimum priority of messages to be logged. If not set for this plugin, the value is inherited from [main].
A sample config file follows: [main]interval=10pidfile=/var/run/tuned.pidlogging=infologging_disable=notset# Disk monitoring section[DiskMonitor]enabled=Truelogging=debug# Disk tuning section[DiskTuning]enabled=Truehdparm=Falsealpm=Falselogging=debug# Net monitoring section[NetMonitor]enabled=Truelogging=debug# Net tuning section[NetTuning]enabled=Truelogging=debug# CPU monitoring section[CPUMonitor]# Enabled or disable the plugin. Default is True. Any other value# disables it.enabled=True# CPU tuning section[CPUTuning]# Enabled or disable the plugin. Default is True. Any other value# disables it.enabled=True Often, a detailed audit and analysis of a system can be very time consuming and might not be worth the few extra watts you might be able to save by doing so. Previously, the only alternative was simply to use the defaults. Therefore, Red Hat Enterprise Linux 6 includes separate profiles for specific use cases as an alternative between those two extremes, together with the tuned-adm tool that allows you to switch between these profiles easily at the command line. Red Hat Enterprise Linux 6 includes a number of predefined profiles for typical use cases that you can simply select and activate with the tuned-adm command, but you can also create, modify or delete profiles yourself. To list all available profiles and identify the current active profile, run: tuned-adm list
To only display the currently active profile, run: tuned-adm active
To switch to one of the available profiles, run: tuned-adm profile profile_name
for example: tuned-adm profile server-powersave
To disable all tuning: tuned-adm off
When you first install tuned, the default profile will be active. Red Hat Enterprise Linux 6 also includes the following predefined profiles: - default
the default power-saving profile. It has the lowest impact on power saving of the available profiles and only enables CPU and disk plugins of tuned. - desktop-powersave
- server-powersave
a power-saving profile directed at server systems. Enables ALPM powersaving for SATA host adapters, disables CD-ROM polling through HAL (refer to the hal-disable-polling man page) and activates the CPU and disk plugins of tuned. - laptop-ac-powersave
a medium-impact power-saving profile directed at laptops running on AC. Enables ALPM powersaving for SATA host adapters, WiFi power saving, as well as the CPU, Ethernet and disk plugins of tuned. - laptop-battery-powersave
a high-impact power-saving profile directed at laptops running on battery. It activates all power saving mechanisms from the previous profiles plus it enables the multi-core power-savings scheduler for low wakeup systems and makes sure that the ondemand governor is active and that AC97 audio power-saving is enabled. You can use this profile to save the maximum amount of power on any kind of system, not only laptops on battery power. The tradeoff for this profile is a noticeable impact on performance, specifically latency of disk and network I/O. - spindown-disk
a strong power-saving profile directed at machines with classic hard disks. It enables aggressive disk spin-down by increasing disk writeback values, lowering disk swappiness, and disabling log syncing. All partitions are remounted with a noatime option. All tuned plugins are disabled. - throughput-performance
a server profile for typical throughput performance tuning. It disables tuned and ktune power saving mechanisms, enables sysctl settings that improve the throughput performance of your disk and network I/O, and switches to the deadline scheduler. - latency-performance
a server profile for typical latency performance tuning. it disables tuned and ktune power saving mechanisms and enables sysctl settings that improve the latency performance of your network I/O. - enterprise-storage
A server profile to improve throughput performance for enterprise-sized server configurations. This switches to the deadline scheduler and disables certain I/O barriers, dramatically improving throughput.
All the profiles are stored in separate subdirectories under /etc/tune-profiles. So /etc/tune-profiles/desktop-powersave contains all the necessary files and settings for that profile. Each of these directories contains up to four files: tuned.confthe configuration for the tuned service to be active for this profile. sysctl.ktunethe sysctl settings used by ktune. The format is identical to the /etc/sysconfig/sysctl file (refer to the sysctl and sysctl.conf man pages). ktune.sysconfigthe configuration file of ktune itself, typically /etc/sysconfig/ktune. ktune.shan init-style shell script used by the ktune service which can run specific commands during system startup to tune the system.
The easiest way to start a new profile is to copy an existing one. The laptop-battery-powersave profile contains a very rich set of tunings already and is therefore a useful starting point. Simply copy the whole directory to the new profile name like this: cp -a /etc/tune-profiles/laptop-battery-powersave/ /etc/tune-profiles/myprofile
Modify any of the files in the new profile to match your personal requirements. For example, if you require the detection of CD changes you could disable that optimization by commenting out the appropriate line in the ktune.sh script: # Disable HAL polling of CDROMS# for i in /dev/scd*; do hal-disable-polling --device $i; done > /dev/null 2>&1 2.6. DeviceKit-power and devkit-powerIn Red Hat Enterprise Linux 6 DeviceKit-power assumes the power management functions that were part of HAL and some of the functions that were part of GNOME Power Manager in previous releases of Red Hat Enterprise Linux (refer also to Section 2.7, "GNOME Power Manager". DeviceKit-power provides a daemon, an API, and a set of command-line tools. Each power source on the system is represented as a device, whether it is a physical device or not. For example, a laptop battery and an AC power source are both represented as devices. You can access the command-line tools with the devkit-power command and the following options: --enumerate, -edisplays an object path for each power devices on the system, for example: /org/freedesktop/DeviceKit/power/devices/line_power_AC/org/freedesktop/UPower/DeviceKit/power/battery_BAT0
--dump, -ddisplays the parameters for all power devices on the system. --wakeups, -wdisplays the CPU wakeups on the system. --monitor, -mmonitors the system for changes to power devices, for example, the connection or disconnection of a source of AC power, or the depletion of a battery. Press Ctrl+C to stop monitoring the system. --monitor-detailmonitors the system for changes to power devices, for example, the connection or disconnection of a source of AC power, or the depletion of a battery. The --monitor-detail option presents more detail than the --monitor option. Press Ctrl+C to stop monitoring the system. --show-info object_path, -i object_pathdisplays all information available for a particular object path. For example, to obtain information about a battery on your system represented by the object path /org/freedesktop/UPower/DeviceKit/power/battery_BAT0, run: devkit-power -i /org/freedesktop/UPower/DeviceKit/power/battery_BAT0
GNOME Power Manager is a daemon that is installed as part of the GNOME desktop. Much of the power-management functionality that GNOME Power Manager provided in earlier versions of Red Hat Enterprise Linux has become part of DeviceKit-power in Red Hat Enterprise Linux 6 (refer to Section 2.6, "DeviceKit-power and devkit-power". However, GNOME Power Manager remains a front end for that functionality. Through an applet in the system tray, GNOME Power Manager notifies you of changes in your system's power status; for example, a change from battery to AC power. It also reports battery status, and warns you when battery power is low. GNOME Power Manager also allows you to configure some basic power management settings. To access these settings, click the GNOME Power Manager icon in the system tray, then click The Power Management Preferences screen contains two tabs: On a laptop, Power Management Preferences will contain a third tab: Use the On AC Power and On Battery Power tabs to specify how much time must pass before the display is turned off on an inactive system, how much time must pass before an inactive system is put to sleep, and whether the system should spin down hard disks when not in use. The On Battery Power tab also allows you to set the display brightness and to choose a behavior for a system with a critically low battery. For example, by default, GNOME Power Manager makes a system hibernate when its battery level reaches a critically low level. Use the General tab to set behaviours for the (physical) power button and suspend button on your system, and to specify the circumstances under which the GNOME Power Manager icon should appear in the system tray. 2.8. Other means for auditingRed Hat Enterprise Linux 6 offers quite a few more tools with which to perform system auditing and analysis. Most of them can be used as a supplementary sources of information in case you want to verify what you have discovered already or in case you need more in-depth information on certain parts. Many of these tools are used for performance tuning as well. They include: - vmstat
vmstat gives you detailed information about processes, memory, paging, block I/O, traps, and CPU activity. Use it to take a closer look at what the system overall does and where it is busy. - iostat
iostat is similar to vmstat, but only for I/O on block devices. It also provides more verbose output and statistics. - blktrace
blktrace is a very detailed block I/O trace program. It breaks down information to single blocks associated with applications. It is very useful in combination with diskdevstat.
|
| |
