Linux Performance and Tuning Guidelines

Total Page：16

File Type：pdf, Size：1020Kb

Front cover Linux Performance and Tuning Guidelines Operating system tuning methods Performance monitoring tools Performance analysis Eduardo Ciliendo Takechika Kunimasa ibm.com/redbooks Redpaper International Technical Support Organization Linux Performance and Tuning Guidelines July 2007 REDP-4285-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (July 2007) This edition applies to kernel 2.6 Linux distributions. This paper was updated on April 25, 2008. © Copyright International Business Machines Corporation 2007. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix How this paper is structured. ix The team that wrote this paper . .x Become a published author . xi Comments welcome. xii Chapter 1. Understanding the Linux operating system. 1 1.1 Linux process management . 2 1.1.1 What is a process? . 2 1.1.2 Life cycle of a process . 3 1.1.3 Thread. 4 1.1.4 Process priority and nice level . 5 1.1.5 Context switching . 5 1.1.6 Interrupt handling . 6 1.1.7 Process state . 6 1.1.8 Process memory segments. 8 1.1.9 Linux CPU scheduler . 9 1.2 Linux memory architecture . 10 1.2.1 Physical and virtual memory . 10 1.2.2 Virtual memory manager. 12 1.3 Linux file systems . 15 1.3.1 Virtual file system . 15 1.3.2 Journaling . 16 1.3.3 Ext2. 17 1.3.4 Ext3. 18 1.3.5 ReiserFS . 19 1.3.6 Journal File System . 19 1.3.7 XFS . 19 1.4 Disk I/O subsystem . 19 1.4.1 I/O subsystem architecture . 20 1.4.2 Cache . 21 1.4.3 Block layer . 23 1.4.4 I/O device driver . 24 1.4.5 RAID and storage system . 25 1.5 Network subsystem. 26 1.5.1 Networking implementation. 26 1.5.2 TCP/IP . 30 1.5.3 Offload . 33 1.5.4 Bonding module . 34 1.6 Understanding Linux performance metrics . 34 1.6.1 Processor metrics . 34 1.6.2 Memory metrics. 35 1.6.3 Network interface metrics . 36 1.6.4 Block device metrics . 36 Chapter 2. Monitoring and benchmark tools . 39 © Copyright IBM Corp. 2007. All rights reserved. iii 2.1 Introduction . 40 2.2 Overview of tool functions . 40 2.3 Monitoring tools. 41 2.3.1 top . 41 2.3.2 vmstat . 42 2.3.3 uptime . 43 2.3.4 ps and pstree . 44 2.3.5 free . 46 2.3.6 iostat . 48 2.3.7 sar . 50 2.3.8 mpstat . 51 2.3.9 numastat . 52 2.3.10 pmap . 52 2.3.11 netstat . 53 2.3.12 iptraf . 54 2.3.13 tcpdump / ethereal . 55 2.3.14 nmon . ..

168

Copy Link

Recommended publications

Better Performance Through a Disk/Persistent-RAM Hybrid Design
The Conquest File System: Better Performance Through a Disk/Persistent-RAM Hybrid Design AN-I ANDY WANG Florida State University GEOFF KUENNING Harvey Mudd College PETER REIHER, GERALD POPEK University of California, Los Angeles ________________________________________________________________________ Modern file systems assume the use of disk, a system-wide performance bottleneck for over a decade. Current disk caching and RAM file systems either impose high overhead to access memory content or fail to provide mechanisms to achieve data persistence across reboots. The Conquest file system is based on the observation that memory is becoming inexpensive, which enables all file system services to be delivered from memory, except providing large storage capacity. Unlike caching, Conquest uses memory with battery backup as persistent storage, and provides specialized and separate data paths to memory and disk. Therefore, the memory data path contains no disk-related complexity. The disk data path consists of only optimizations for the specialized disk usage pattern. Compared to a memory-based file system, Conquest incurs little performance overhead. Compared to several disk-based file systems, Conquest achieves 1.3x to 19x faster memory performance, and 1.4x to 2.0x faster performance when exercising both memory and disk. Conquest realizes most of the benefits of persistent RAM at a fraction of the cost of a RAM-only solution. Conquest also demonstrates that disk-related optimizations impose high overheads for accessing memory content in a memory-rich environment. Categories and Subject Descriptors: D.4.2 [Operating Systems]: Storage Management—Storage Hierarchies; D.4.3 [Operating Systems]: File System Management—Access Methods and Directory Structures; D.4.8 [Operating Systems]: Performance—Measurements General Terms: Design, Experimentation, Measurement, and Performance Additional Key Words and Phrases: Persistent RAM, File Systems, Storage Management, and Performance Measurement ________________________________________________________________________ 1.
[Show full text]
Embedding Redhat Linux in a Diskonchip - HOWTO
Embedding Redhat Linux in a DiskOnChip - HOWTO Don Davies, Prosig Ltd ( [email protected]) October 2002 Describes the configuration and setup of a development environment for a Single Board Computer running Redhat Linux from a DiskOnChip device. Contents 1.0 Introduction ..........................................................................................................3 1.1 Hardware Details..................................................................................................3 1.2 System Configuration ...........................................................................................4 2.0 DOS Development Environment...........................................................................5 2.1 DiskOnChip Tools ................................................................................................5 2.2 Boot Loader..........................................................................................................6 2.3 MS-DOS System Startup......................................................................................6 3.0 Linux Development Environment ......................................................................7 3.1 Custom Kernel Configuration ............................................................................8 3.2 Building Custom Kernel ..................................................................................10 3.3 Booting Custom Kernel ...................................................................................10 3.4 Formatting DiskOnChip for Linux
[Show full text]
MLNX OFED Documentation Rev 5.0-2.1.8.0
MLNX_OFED Documentation Rev 5.0-2.1.8.0 Exported on May/21/2020 06:13 AM https://docs.mellanox.com/x/JLV-AQ Notice This document is provided for information purposes only and shall not be regarded as a warranty of a certain functionality, condition, or quality of a product. NVIDIA Corporation (“NVIDIA”) makes no representations or warranties, expressed or implied, as to the accuracy or completeness of the information contained in this document and assumes no responsibility for any errors contained herein. NVIDIA shall have no liability for the consequences or use of such information or for any infringement of patents or other rights of third parties that may result from its use. This document is not a commitment to develop, release, or deliver any Material (defined below), code, or functionality. NVIDIA reserves the right to make corrections, modifications, enhancements, improvements, and any other changes to this document, at any time without notice. Customer should obtain the latest relevant information before placing orders and should verify that such information is current and complete. NVIDIA products are sold subject to the NVIDIA standard terms and conditions of sale supplied at the time of order acknowledgement, unless otherwise agreed in an individual sales agreement signed by authorized representatives of NVIDIA and customer (“Terms of Sale”). NVIDIA hereby expressly objects to applying any customer general terms and conditions with regards to the purchase of the NVIDIA product referenced in this document. No contractual obligations are formed either directly or indirectly by this document. NVIDIA products are not designed, authorized, or warranted to be suitable for use in medical, military, aircraft, space, or life support equipment, nor in applications where failure or malfunction of the NVIDIA product can reasonably be expected to result in personal injury, death, or property or environmental damage.
[Show full text]
Virtual Memory
Chapter 4 Virtual Memory Linux processes execute in a virtual environment that makes it appear as if each process had the entire address space of the CPU available to itself. This virtual address space extends from address 0 all the way to the maximum address. On a 32-bit platform, such as IA-32, the maximum address is 232 − 1or0xffffffff. On a 64-bit platform, such as IA-64, this is 264 − 1or0xffffffffffffffff. While it is obviously convenient for a process to be able to access such a huge ad- dress space, there are really three distinct, but equally important, reasons for using virtual memory. 1. Resource virtualization. On a system with virtual memory, a process does not have to concern itself with the details of how much physical memory is available or which physical memory locations are already in use by some other process. In other words, virtual memory takes a limited physical resource (physical memory) and turns it into an inﬁnite, or at least an abundant, resource (virtual memory). 2. Information isolation. Because each process runs in its own address space, it is not possible for one process to read data that belongs to another process. This improves security because it reduces the risk of one process being able to spy on another pro- cess and, e.g., steal a password. 3. Fault isolation. Processes with their own virtual address spaces cannot overwrite each other’s memory. This greatly reduces the risk of a failure in one process trig- gering a failure in another process. That is, when a process crashes, the problem is generally limited to that process alone and does not cause the entire machine to go down.
[Show full text]
Oracle Database Licensing Information, 11G Release 2 (11.2) E10594-26
Oracle® Database Licensing Information 11g Release 2 (11.2) E10594-26 July 2012 Oracle Database Licensing Information, 11g Release 2 (11.2) E10594-26 Copyright © 2004, 2012, Oracle and/or its affiliates. All rights reserved. Contributor: Manmeet Ahluwalia, Penny Avril, Charlie Berger, Michelle Bird, Carolyn Bruse, Rich Buchheim, Sandra Cheevers, Leo Cloutier, Bud Endress, Prabhaker Gongloor, Kevin Jernigan, Anil Khilani, Mughees Minhas, Trish McGonigle, Dennis MacNeil, Paul Narth, Anu Natarajan, Paul Needham, Martin Pena, Jill Robinson, Mark Townsend This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.
[Show full text]
Bull SAS: Novascale B260 (Intel Xeon Processor 5110,1.60Ghz)
SPEC CINT2006 Result spec Copyright 2006-2014 Standard Performance Evaluation Corporation Bull SAS SPECint2006 = 10.2 NovaScale B260 (Intel Xeon processor 5110,1.60GHz) SPECint_base2006 = 9.84 CPU2006 license: 20 Test date: Dec-2006 Test sponsor: Bull SAS Hardware Availability: Dec-2006 Tested by: Bull SAS Software Availability: Dec-2006 0 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 9.00 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 12.7 400.perlbench 11.6 8.64 401.bzip2 8.41 6.59 403.gcc 6.38 11.9 429.mcf 12.7 12.0 445.gobmk 10.6 6.90 456.hmmer 6.72 10.8 458.sjeng 9.90 11.0 462.libquantum 10.8 17.1 464.h264ref 16.8 9.22 471.omnetpp 8.38 7.84 473.astar 7.83 12.5 483.xalancbmk 12.4 SPECint_base2006 = 9.84 SPECint2006 = 10.2 Hardware Software CPU Name: Intel Xeon 5110 Operating System: Windows Server 2003 Enterprise Edition (32 bits) CPU Characteristics: 1.60 GHz, 4MB L2, 1066MHz bus Service Pack1 CPU MHz: 1600 Compiler: Intel C++ Compiler for IA32 version 9.1 Package ID W_CC_C_9.1.033 Build no 20061103Z FPU: Integrated Microsoft Visual Studio .NET 2003 (lib & linker) CPU(s) enabled: 1 core, 1 chip, 2 cores/chip MicroQuill SmartHeap Library 8.0 (shlW32M.lib) CPU(s) orderable: 1 to 2 chips Auto Parallel: No Primary Cache: 32 KB I + 32 KB D on chip per core File System: NTFS Secondary Cache: 4 MB I+D on chip per chip System State: Default L3 Cache: None Base Pointers: 32-bit Other Cache: None Peak Pointers: 32-bit Memory: 8 GB (2GB DIMMx4, FB-DIMM PC2-5300F ECC CL5) Other Software: None Disk Subsystem: 73 GB SAS, 10000RPM Other Hardware: None
[Show full text]
Dm-X: Protecting Volume-Level Integrity for Cloud Volumes and Local
dm-x: Protecting Volume-level Integrity for Cloud Volumes and Local Block Devices Anrin Chakraborti Bhushan Jain Jan Kasiak Stony Brook University Stony Brook University & Stony Brook University UNC, Chapel Hill Tao Zhang Donald Porter Radu Sion Stony Brook University & Stony Brook University & Stony Brook University UNC, Chapel Hill UNC, Chapel Hill ABSTRACT on Amazon’s Virtual Private Cloud (VPC) [2] (which provides The verified boot feature in recent Android devices, which strong security guarantees through network isolation) store deploys dm-verity, has been overwhelmingly successful in elim- data on untrusted storage devices residing in the public cloud. inating the extremely popular Android smart phone rooting For example, Amazon VPC file systems, object stores, and movement [25]. Unfortunately, dm-verity integrity guarantees databases reside on virtual block devices in the Amazon are read-only and do not extend to writable volumes. Elastic Block Storage (EBS). This paper introduces a new device mapper, dm-x, that This allows numerous attack vectors for a malicious cloud efficiently (fast) and reliably (metadata journaling) assures provider/untrusted software running on the server. For in- volume-level integrity for entire, writable volumes. In a direct stance, to ensure SEC-mandated assurances of end-to-end disk setup, dm-x overheads are around 6-35% over ext4 on the integrity, banks need to guarantee that the external cloud raw volume while offering additional integrity guarantees. For storage service is unable to remove log entries documenting cloud storage (Amazon EBS), dm-x overheads are negligible. financial transactions. Yet, without integrity of the storage device, a malicious cloud storage service could remove logs of a coordinated attack.
[Show full text]
1 Introduction
Technical report, IDE1202, February 2012 Enhancing Network Security in Linux Environment Master Thesis in Computer Network Engineering By Ali Mohammed, Sachin Sama and Majeed Mohammed School of Information Science, Computer and Electrical Engineering Halmstad University i Enhancing Network Security in Linux Environment Master Thesis in Computer Network Engineering School of Information Science, Computer and Electrical Engineering Halmstad University Box 823, S-301 18 Halmstad, Sweden February 2012 ii Preface First of all, we would like to express our sincere gratitude to our Supervisor Philip Heimer and Professor Tony Larsson for their supervision and assistance in the entire thesis work. We are also thankful to IDE department, Halmstad University for providing this opportunity to complete this thesis. Ali Mohammed Sachin Sama Majeed Mohammed iii iv Abstract Designing a secured network is the most important task in any enterprise or organization development. Securing a network mainly involves applying policies and procedures to protect different network devices from unauthorized access. Servers such as web servers, file servers, mail servers, etc., are the important devices in a network. Therefore, securing these servers is the first and foremost step followed in every security implementation mechanism. To implement this, it is very important to analyse and study the security mechanisms provided by the operating system. This makes it easier for security implementation in a network. This thesis work demonstrates the tasks needed to enhance the network security in Linux environment. The various security modules existing in Linux makes it different from other operating systems. The security measures which are mainly needed to enhance the system security are documented as a baseline for practical implementation.
[Show full text]
Microbenchmarks in Big Data
M Microbenchmark Overview Microbenchmarks constitute the first line of per- Nicolas Poggi formance testing. Through them, we can ensure Databricks Inc., Amsterdam, NL, BarcelonaTech the proper and timely functioning of the different (UPC), Barcelona, Spain individual components that make up our system. The term micro, of course, depends on the prob- lem size. In BigData we broaden the concept Synonyms to cover the testing of large-scale distributed systems and computing frameworks. This chap- Component benchmark; Functional benchmark; ter presents the historical background, evolution, Test central ideas, and current key applications of the field concerning BigData. Definition Historical Background A microbenchmark is either a program or routine to measure and test the performance of a single Origins and CPU-Oriented Benchmarks component or task. Microbenchmarks are used to Microbenchmarks are closer to both hardware measure simple and well-defined quantities such and software testing than to competitive bench- as elapsed time, rate of operations, bandwidth, marking, opposed to application-level – macro or latency. Typically, microbenchmarks were as- – benchmarking. For this reason, we can trace sociated with the testing of individual software microbenchmarking influence to the hardware subroutines or lower-level hardware components testing discipline as can be found in Sumne such as the CPU and for a short period of time. (1974). Furthermore, we can also find influence However, in the BigData scope, the term mi- in the origins of software testing methodology crobenchmarking is broadened to include the during the 1970s, including works such cluster – group of networked computers – acting as Chow (1978). One of the first examples of as a single system, as well as the testing of a microbenchmark clearly distinguishable from frameworks, algorithms, logical and distributed software testing is the Whetstone benchmark components, for a longer period and larger data developed during the late 1960s and published sizes.
[Show full text]
Overview of the SPEC Benchmarks
9 Overview of the SPEC Benchmarks Kaivalya M. Dixit IBM Corporation “The reputation of current benchmarketing claims regarding system performance is on par with the promises made by politicians during elections.” Standard Performance Evaluation Corporation (SPEC) was founded in October, 1988, by Apollo, Hewlett-Packard,MIPS Computer Systems and SUN Microsystems in cooperation with E. E. Times. SPEC is a nonprofit consortium of 22 major computer vendors whose common goals are “to provide the industry with a realistic yardstick to measure the performance of advanced computer systems” and to educate consumers about the performance of vendors’ products. SPEC creates, maintains, distributes, and endorses a standardized set of application-oriented programs to be used as benchmarks. 489 490 CHAPTER 9 Overview of the SPEC Benchmarks 9.1 Historical Perspective Traditional benchmarks have failed to characterize the system performance of modern computer systems. Some of those benchmarks measure component-level performance, and some of the measurements are routinely published as system performance. Historically, vendors have characterized the performances of their systems in a variety of confusing metrics. In part, the confusion is due to a lack of credible performance information, agreement, and leadership among competing vendors. Many vendors characterize system performance in millions of instructions per second (MIPS) and millions of floating-point operations per second (MFLOPS). All instructions, however, are not equal. Since CISC machine instructions usually accomplish a lot more than those of RISC machines, comparing the instructions of a CISC machine and a RISC machine is similar to comparing Latin and Greek. 9.1.1 Simple CPU Benchmarks Truth in benchmarking is an oxymoron because vendors use benchmarks for marketing purposes.
[Show full text]
Comparing Filesystem Performance: Red Hat Enterprise Linux 6 Vs
COMPARING FILE SYSTEM I/O PERFORMANCE: RED HAT ENTERPRISE LINUX 6 VS. MICROSOFT WINDOWS SERVER 2012 When choosing an operating system platform for your servers, you should know what I/O performance to expect from the operating system and file systems you select. In the Principled Technologies labs, using the IOzone file system benchmark, we compared the I/O performance of two operating systems and file system pairs, Red Hat Enterprise Linux 6 with ext4 and XFS file systems, and Microsoft Windows Server 2012 with NTFS and ReFS file systems. Our testing compared out-of-the-box configurations for each operating system, as well as tuned configurations optimized for better performance, to demonstrate how a few simple adjustments can elevate I/O performance of a file system. We found that file systems available with Red Hat Enterprise Linux 6 delivered better I/O performance than those shipped with Windows Server 2012, in both out-of- the-box and optimized configurations. With I/O performance playing such a critical role in most business applications, selecting the right file system and operating system combination is critical to help you achieve your hardware’s maximum potential. APRIL 2013 A PRINCIPLED TECHNOLOGIES TEST REPORT Commissioned by Red Hat, Inc. About file system and platform configurations While you can use IOzone to gauge disk performance, we concentrated on the file system performance of two operating systems (OSs): Red Hat Enterprise Linux 6, where we examined the ext4 and XFS file systems, and Microsoft Windows Server 2012 Datacenter Edition, where we examined NTFS and ReFS file systems.
[Show full text]
Improving Networking
IMPERIAL COLLEGE LONDON FINALYEARPROJECT JUNE 14, 2010 Improving Networking by moving the network stack to userspace Author: Matthew WHITWORTH Supervisor: Dr. Naranker DULAY 2 Abstract In our modern, networked world the software, protocols and algorithms involved in communication are among some of the most critical parts of an operating system. The core communication software in most modern systems is the network stack, but its basic monolithic design and functioning has remained unchanged for decades. Here we present an adaptable user-space network stack, as an addition to my operating system Whitix. The ideas and concepts presented in this report, however, are applicable to any mainstream operating system. We show how re-imagining the whole architecture of networking in a modern operating system offers numerous beneﬁts for stack-application interactivity, protocol extensibility, and improvements in network throughput and latency. 3 4 Acknowledgements I would like to thank Naranker Dulay for supervising me during the course of this project. His time spent offering constructive feedback about the progress of the project is very much appreciated. I would also like to thank my family and friends for their support, and also anybody who has contributed to Whitix in the past or offered encouragement with the project. 5 6 Contents 1 Introduction 11 1.1 Motivation.................................... 11 1.1.1 Adaptability and interactivity.................... 11 1.1.2 Multiprocessor systems and locking................ 12 1.1.3 Cache performance.......................... 14 1.2 Whitix....................................... 14 1.3 Outline...................................... 15 2 Hardware and the LDL 17 2.1 Architectural overview............................. 17 2.2 Network drivers................................. 18 2.2.1 Driver and device setup.......................
[Show full text]