Optimizing AIX 7 Performance: Part 1, Disk I/O Overview and Long-Term Monitoring Tools (Sar, Nmon, and Topas) Martin Brown October 12, 2010 Ken Milberg

Total Page:16

File Type:pdf, Size:1020Kb

Optimizing AIX 7 Performance: Part 1, Disk I/O Overview and Long-Term Monitoring Tools (Sar, Nmon, and Topas) Martin Brown October 12, 2010 Ken Milberg Optimizing AIX 7 performance: Part 1, Disk I/O overview and long-term monitoring tools (sar, nmon, and topas) Martin Brown October 12, 2010 Ken Milberg Learn more about configuring and monitoring AIX 7 based on the investigations of AIX 7 beta compared to the original articles based on AIX 5L. The article covers the support for direct I/O, concurrent I/O, asynchronous I/O, and best practices for each method of I/O implementation. This three-part series on the AIX® disk and I/O subsystem focuses on the challenges of optimizing disk I/O performance. While disk tuning is arguably less exciting than CPU or memory tuning, it is a crucial component in optimizing server performance. In fact, partly because disk I/O is your weakest subsystem link, you can do more to improve disk I/O performance than on any other subsystem. View more content in this series Introduction A critical component of disk I/O tuning involves implementing best practices prior to building your system. Because it is much more difficult to move things around when you are already up and running, it is extremely important that you do things right the first time when planning your disk and I/O subsystem environment. This includes the physical architecture, logical disk geometry, and logical volume and file system configuration. When a system administrator hears that there might be a disk contention issue, the first thing he or she turns to is iostat. iostat, the equivalent of using vmstat for your memory reports, is a quick and dirty way of getting an overview of what is currently happening on your I/O subsystem. While running iostat is not an inappropriate reaction at all, the time to start thinking about disk I/O is long before tuning becomes necessary. All the tuning in the world will not help if your disks are not configured appropriately for your environment from the beginning. Furthermore, it is extremely important to understand the specifics of disk I/O and how it relates to AIX® and your System p™ hardware. When it comes to disk I/O tuning, generic UNIX® commands and tools help you much less than specific AIX tools and utilities that have been developed to help you optimize your native AIX disk I/O subsystem. In this article, we will define and discuss the AIX I/O stack and correlate it to © Copyright IBM Corporation 2010 Trademarks Optimizing AIX 7 performance: Part 1, Disk I/O overview and Page 1 of 13 long-term monitoring tools (sar, nmon, and topas) developerWorks® ibm.com/developerWorks/ both the physical and logical aspects of disk performance. We will discuss direct, concurrent, and asynchronous I/O: what they are, how to turn them on, and how to monitor and tune them. We will also introduce some of the long-term monitoring tools that you should use to help tune your system. You might be surprised to hear that iostat is not one of the tools recommended to help you with long-term gathering of statistical data. This article looks at the support and changes present in a beta release of AIX 7, including the ways in which the configuration of the different subsystems has changed. The main changes in AIX 7 further simplify the operation and configuration of many of the I/O subsystems, work that had originally been started in AIX 6. The result is that many of the different I/O subsystems no longer need to be enabled and configured. Instead, they are supplied in a pre-configured state and are automatically enabled and started when an application requests that functionality. The article also concentrates on changes that will help identify and improve the subsystem you are looking to tune. The best time to start monitoring your systems is when you first put your system in production, and it is running well (rather than waiting until your users are screaming about slow performance). You really need to have a baseline of what the system looked like when it was behaving normally to analyze data when it is presumably not performing adequately. When making changes to your I/O subsystem, make these changes one at a time so that you will be able to assess fully the impact of your change. To assess that impact, you'll be capturing data using one of the long-term monitoring tools recommended in this article. Disk I/O overview It shouldn't surprise you that the slowest operation for running any program is the time actually spent on retrieving the data from disk. This all comes back to the physical component of I/O. The actual disk arms must find the correct cylinder, the control needs to access the correct blocks, and the disk heads have to wait while the blocks rotate to them. The physical architecture of your I/O system should be understood prior to any work on tuning activities for systems, since all the tuning in the world won't help a poorly architected I/O subsystem that consists of a slow disk or inefficient use of adapters. Figure 1 illustrates how tightly integrated the physical I/O components relate to the logical disk and its application I/O. This is what is commonly referred to as the AIX I/O stack. Optimizing AIX 7 performance: Part 1, Disk I/O overview and Page 2 of 13 long-term monitoring tools (sar, nmon, and topas) ibm.com/developerWorks/ developerWorks® Figure 1. The AIX I/O stack You need to be cognizant of all the layers when tuning, as each impacts performance in a different way. When first setting up your systems, start from the bottom (the physical layer) as you configure your disk, the device layer, its logical volumes, file systems, and the files and application. We can't emphasize enough the importance in planning your physical storage environment. This involves determining the amount of disk, type (speed), size, and throughput. One important challenge with storage technology to note is that while storage capabilities of disk are increasing dramatically, the rotational speed of the disk increases at a much slower pace. You must never lose sight of the fact that while RAM access takes about 540 CPU cycles, disk access can take 20 million CPU cycles. Clearly, the weakest link on a system is the disk I/O storage system, and it's your job as the system administrator to make sure it doesn't become even more of a bottleneck. As alluded to earlier, poor layout of data affects I/O performance much more than any tunable I/O parameter. Looking at the I/O stack helps you to understand this, as Logical Volume Manager (LVM) and disk placement are closer to the bottom than the tuning parameters (ioo and vmo). Now let's discuss some best practices of data layout. One important concept is making sure that your data is evenly spread across your entire physical disk. If your data resides on only a few spindles, what is the purpose of having multiple logical unit numbers (LUNs) or physical disks? If you have a SAN or another type of storage array, you should try to create your arrays of equal size and type. You should also create them with one LUN for each array and then spread all your logical volumes across all the physical volumes in your Volume Group. As stated previously, the time to do this is when you first configure your system, as it is much more cumbersome to fix I/O problems than memory or CPU problems, particularly if it involves moving data around in a production environment. You also want to make certain that your mirrors are on separate disks and adapters. Databases pose separate, unique challenges; so, if possible, Optimizing AIX 7 performance: Part 1, Disk I/O overview and Page 3 of 13 long-term monitoring tools (sar, nmon, and topas) developerWorks® ibm.com/developerWorks/ your indexes and redo logs should also reside on separate physical disks. The same is true for temporary tablespaces often used for performing sort operations. Using high-speed adapters to connect the disk drives are extremely important, but you must make certain that the bus itself does not become a bottleneck. To prevent this from happening, make sure to spread the adapters across multiple buses. At the same time, do not attach too many physical disks or LUNs to any one adapter, as this also significantly impacts performance. The more adapters that you configure, the better, particularly if there are large amounts of heavily utilized disk. You should also make sure that the device drivers support multi-path I/O (MPIO), which allows for load balancing and availability of your I/O subsystem. Direct I/O Let's return to some of the concepts mentioned earlier, such as direct I/O. What is direct I/O? First introduced in AIX Version 4.3, this method of I/O bypasses the Virtual Memory Manager (VMM) and transfers data directly to disk from the user's buffer. Depending on your type of application, it is possible to have improved performance when implementing this technique. For example, files that have poor cache utilization are great candidates for using direct I/O. Direct I/O also benefits applications that use synchronous writes, as these writes have to go to disk. CPU usage is reduced because the dual data copy piece is eliminated. This copy occurs when the disk is copied to the buffer cache and then again from the file. One of the major performance costs of direct I/ O is that while it can reduce CPU usage, it can also result in processes taking longer to complete for smaller requests.
Recommended publications
  • 20 Linux System Monitoring Tools Every Sysadmin Should Know by Nixcraft on June 27, 2009 · 315 Comments · Last Updated November 6, 2012
    About Forum Howtos & FAQs Low graphics Shell Scripts RSS/Feed nixcraft - insight into linux admin work 20 Linux System Monitoring Tools Every SysAdmin Should Know by nixCraft on June 27, 2009 · 315 comments · Last updated November 6, 2012 Need to monitor Linux server performance? Try these built-in commands and a few add-on tools. Most Linux distributions are equipped with tons of monitoring. These tools provide metrics which can be used to get information about system activities. You can use these tools to find the possible causes of a performance problem. The commands discussed below are some of the most basic commands when it comes to system analysis and debugging server issues such as: 1. Finding out bottlenecks. 2. Disk (storage) bottlenecks. 3. CPU and memory bottlenecks. 4. Network bottlenecks. #1: top - Process Activity Command The top program provides a dynamic real-time view of a running system i.e. actual process activity. By default, it displays the most CPU-intensive tasks running on the server and updates the list every five seconds. Fig.01: Linux top command Commonly Used Hot Keys The top command provides several useful hot keys: Hot Usage Key t Displays summary information off and on. m Displays memory information off and on. Sorts the display by top consumers of various system resources. Useful for quick identification of performance- A hungry tasks on a system. f Enters an interactive configuration screen for top. Helpful for setting up top for a specific task. o Enables you to interactively select the ordering within top. r Issues renice command.
    [Show full text]
  • Java Bytecode Manipulation Framework
    Notice About this document The following copyright statements and licenses apply to software components that are distributed with various versions of the OnCommand Performance Manager products. Your product does not necessarily use all the software components referred to below. Where required, source code is published at the following location: ftp://ftp.netapp.com/frm-ntap/opensource/ 215-09632 _A0_ur001 -Copyright 2014 NetApp, Inc. All rights reserved. 1 Notice Copyrights and licenses The following component is subject to the ANTLR License • ANTLR, ANother Tool for Language Recognition - 2.7.6 © Copyright ANTLR / Terence Parr 2009 ANTLR License SOFTWARE RIGHTS ANTLR 1989-2004 Developed by Terence Parr Partially supported by University of San Francisco & jGuru.com We reserve no legal rights to the ANTLR--it is fully in the public domain. An individual or company may do whatever they wish with source code distributed with ANTLR or the code generated by ANTLR, including the incorporation of ANTLR, or its output, into commerical software. We encourage users to develop software with ANTLR. However, we do ask that credit is given to us for developing ANTLR. By "credit", we mean that if you use ANTLR or incorporate any source code into one of your programs (commercial product, research project, or otherwise) that you acknowledge this fact somewhere in the documentation, research report, etc... If you like ANTLR and have developed a nice tool with the output, please mention that you developed it using ANTLR. In addition, we ask that the headers remain intact in our source code. As long as these guidelines are kept, we expect to continue enhancing this system and expect to make other tools available as they are completed.
    [Show full text]
  • AIX Version 7.2: Performance Tools Guide and Reference About This Document
    AIX Version 7.2 Performance Tools Guide and Reference IBM AIX Version 7.2 Performance Tools Guide and Reference IBM Note Before using this information and the product it supports, read the information in “Notices” on page 315. This edition applies to AIX Version 7.2 and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright IBM Corporation 2015, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this document ......... v The procmon tool ............ 212 Highlighting .............. v Overview of the procmon tool....... 212 Case-sensitivity in AIX ........... v Components of the procmon tool...... 212 ISO 9000................ v Filtering processes........... 215 Performing AIX commands on processes ... 215 Performance Tools Guide and Reference 1 Profiling tools ............. 215 The timing commands ......... 215 What's new in Performance Tools Guide and The prof command .......... 216 Reference ............... 2 The gprof command .......... 217 CPU Utilization Reporting Tool (curt) ...... 2 The tprof command .......... 219 Syntax for the curt Command ....... 2 The svmon command .......... 226 Measurement and Sampling ........ 3 Security .............. 227 Examples of the curt command ....... 4 The svmon configuration file ....... 227 Simple performance lock analysis tool (splat) ... 32 Summary report metrics......... 227 splat command syntax.......... 32 Report formatting options ........ 228 Measurement and sampling ........ 33 Segment details and -O options ...... 230 Examples of generated reports ....... 35 Additional -O options ......... 234 Hardware performance monitor APIs and tools .. 50 Reports details ............ 238 Performance monitor accuracy ....... 51 Remote Statistics Interface API Overview .... 259 Performance monitor context and state .... 51 Remote Statistics Interface list of subroutines 260 Performance monitoring agent ......
    [Show full text]
  • How to Maintain Happy SAS® Users
    NESUG 2007 Administration & Support How to Maintain Happy SAS ® Users Margaret Crevar, SAS Institute Inc., Cary, NC ABSTRACT Today’s SAS ® environment has high numbers of concurrent SAS processes and ever-growing data volumes. It is imperative to proactively manage system resources and performance to keep your SAS community productive and happy. We have found that ensuring your SAS applications have the proper computer resources is the best way to make sure your SAS users remain happy. INTRODUCTION There is one common thread when working with the IT administration staff at a SAS customer’s location with regard to what they can do to maintain happy SAS users, and that is to ensure that underlying hardware is properly configured to support the SAS applications. This is not a trivial task since different SAS applications need to have the hardware configured differently and depending on where you are with your understanding of how SAS will be used will help you evaluate options for the hardware, operating, and infrastructure (mid-tier) configuration. This is easier for existing SAS customers and more difficult with new SAS customers or new SAS applications at an existing SAS customer site. In this paper we will: • discuss briefly how SAS works, especially from an IO perspective • give some guidance on how to initially configure hardware for SAS usage • give some guidance on how to monitor the hardware to avoid running out of a computer resource • discuss if you should run all your SAS components under a single operating system or split them across multiple operating system This paper pulls together information that has been presented in recent SAS Global Forum and SUGI papers.
    [Show full text]
  • UNIX OS Agent User's Guide
    IBM Tivoli Monitoring Version 6.3.0 UNIX OS Agent User's Guide SC22-5452-00 IBM Tivoli Monitoring Version 6.3.0 UNIX OS Agent User's Guide SC22-5452-00 Note Before using this information and the product it supports, read the information in “Notices” on page 399. This edition applies to version 6, release 3 of IBM Tivoli Monitoring (product number 5724-C04) and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright IBM Corporation 1994, 2013. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Tables ...............vii Solaris System CPU Workload workspace ....28 Solaris Zone Processes workspace .......28 Chapter 1. Using the monitoring agent . 1 Solaris Zones workspace ..........28 System Details workspace .........28 New in this release ............2 System Information workspace ........29 Components of the monitoring agent ......3 Top CPU-Memory %-VSize Details workspace . 30 User interface options ...........4 UNIX OS workspace ...........30 UNIX Detail workspace ..........31 Chapter 2. Requirements for the Users workspace ............31 monitoring agent ...........5 Enabling the Monitoring Agent for UNIX OS to run Chapter 4. Attributes .........33 as a nonroot user .............7 Agent Availability Management Status attributes . 36 Securing your IBM Tivoli Monitoring installation 7 Agent Active Runtime Status attributes .....37 Setting overall file ownership and permissions for AIX AMS attributes............38
    [Show full text]
  • SUSE Linux Enterprise Server 11 SP4 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 11 SP4
    SUSE Linux Enterprise Server 11 SP4 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 11 SP4 Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see http://www.suse.com/company/legal/ . All other third party trademarks are the property of their respective owners. A trademark symbol (®, ™ etc.) denotes a SUSE or Novell trademark; an asterisk (*) denotes a third party trademark. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xi 1 Available Documentation xii 2 Feedback xiv 3 Documentation Conventions xv I BASICS 1 1 General Notes on System Tuning 2 1.1 Be Sure What Problem to Solve 2 1.2 Rule Out Common Problems 3 1.3 Finding the Bottleneck 3 1.4 Step-by-step Tuning 4 II SYSTEM MONITORING 5 2 System Monitoring Utilities 6 2.1 Multi-Purpose Tools 6 vmstat 7
    [Show full text]
  • System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1
    SUSE Linux Enterprise Server 15 SP1 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1 An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to eciently manage resources. Also contains an overview of common problems and solutions and of additional help and documentation resources. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xii 1 Available Documentation xiii
    [Show full text]
  • SUSE Linux Enterprise Server 12 SP4 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 12 SP4
    SUSE Linux Enterprise Server 12 SP4 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 12 SP4 An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to eciently manage resources. Also contains an overview of common problems and solutions and of additional help and documentation resources. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xii 1 Available Documentation xiii
    [Show full text]
  • Nmon Performance Monitor Splunk App for Unix and Linux Systems Documentation Release 1.8.0
    Nmon Performance monitor Splunk app for Unix and Linux systems Documentation Release 1.8.0 Guilhem Marchand October 07, 2016 Contents 1 Overview: 3 1.1 About Nmon Performance monitor for Splunk.............................3 1.2 Release notes...............................................5 1.3 Known Issues............................................... 30 1.4 Support.................................................. 30 1.5 Issues and enhancement requests.................................... 31 1.6 Scripts and Binaries........................................... 31 1.7 licence.................................................. 33 2 Documentation: 35 2.1 Introduction............................................... 35 2.2 Deployment Matrix........................................... 37 2.3 Deployment topologies.......................................... 39 2.4 Download................................................. 42 2.5 Running on Windows.......................................... 43 2.6 Deploy to single server instance..................................... 43 2.7 Deploy to distributed deployment.................................... 46 2.8 Deployment on Search Heads running in SH Pooling mode...................... 55 2.9 Deploying Nmon Performance Monitor in SH Clusters......................... 55 2.10 Deploy to Splunk Cloud......................................... 55 2.11 Managing Nmon Central Repositories.................................. 59 2.12 rsyslog / nmon-logger deployment.................................... 61 2.13 syslog-ng / nmon-logger
    [Show full text]
  • Practical Linux Performance and Application Troubleshooting by Tanel Poder |
    Practical Linux Performance and Application Troubleshooting by Tanel Poder | https://blog.tanelpoder.com/seminar Table of Contents The training sessions of this class are split into two separate weeks: • Part 1 - Application Troubleshooting on Linux (intermediate) • Part 2 - Linux OS Troubleshooting and Performance Tuning (advanced) The Part 1 starts at higher level and aims to stay mostly at application troubleshooting and OS fundamentals level, assuming that the system is not overloaded and the kernel & lower levels of hardware/OS stack work just fine. The Part 2 then dives deeper, revisiting some of the topics at much more detailed level (including OS kernel issues) and addressing new areas too. Part 1 – Application Troubleshooting on Linux 1. Introduction: Application and OS touchpoint • How do applications interact with the OS and hardware? • How do system calls work? • Tracing process activity • Process virtual memory • Private memory allocation basics • Executable loading and memory mapping • Do we have a memory shortage? 2. Measuring Process Activity • Processes, threads, tasks • Process creation, cleanup and zombies • CPU scheduler and thread states • What does the Linux system load really mean? (It’s different from classic Unix) • Sampling & profiling any OS process activity • Application CPU usage & CPU profiling (Java, C/C++, Python etc) 3. File access and disk I/O • Everything is a file • File descriptors • Where are my log files? • Filesystems & caching • Block devices and disk I/O • Using iostat for IO subsystem performance summary © Tanel Poder 2009-2019 https://blog.tanelpoder.com 4. Process Memory usage • Process heaps, data segments • Java applications’ memory analysis (JVM) • PageCache and buffers • How much memory is really free? • Who’s using the most of physical RAM? • Who is causing swapping? • Configuring Swap space and memory overcommitting • When should I change Kernel “swappiness”? • Static HugePages, Transaprent HugePages and page size considerations 5.
    [Show full text]
  • Seebeyond ICAN Suite Installation Guide
    eInsight Enterprise Service Bus Installation Guide Release 5.0.2 SeeBeyond Proprietary and Confidential The information contained in this document is subject to change and is updated periodically to reflect changes to the applicable software. Although every effort has been made to ensure the accuracy of this document, SeeBeyond Technology Corporation (SeeBeyond) assumes no responsibility for any errors that may appear herein. The software described in this document is furnished under a License Agreement and may be used or copied only in accordance with the terms of such License Agreement. Printing, copying, or reproducing this document in any fashion is prohibited except in accordance with the License Agreement. The contents of this document are designated as being confidential and proprietary; are considered to be trade secrets of SeeBeyond; and may be used only in accordance with the License Agreement, as protected and enforceable by law. SeeBeyond assumes no responsibility for the use or reliability of its software on platforms that are not supported by SeeBeyond. SeeBeyond, e*Gate, and e*Way are the registered trademarks of SeeBeyond Technology Corporation in the United States and select foreign countries; the SeeBeyond logo, e*Insight, and e*Xchange are trademarks of SeeBeyond Technology Corporation. The absence of a trademark from this list does not constitute a waiver of SeeBeyond Technology Corporation's intellectual property rights concerning that trademark. This document may contain references to other company, brand, and product names. These company, brand, and product names are used herein for identification purposes only and may be the trademarks of their respective owners. © 2003 by SeeBeyond Technology Corporation.
    [Show full text]
  • Advanced Administration of the Gnulinux Operating System, February 2010
    Configuration, tuning and optimisation Remo Suppi Boldrito PID_00148473 GNUFDL • PID_00148473 Configuration, tuning and optimisation Copyright © 2009, FUOC. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License" GNUFDL • PID_00148473 Configuration, tuning and optimisation Index Introduction............................................................................................... 5 1. Basic aspects........................................................................................ 7 1.1. Monitoring on a UNIX System V ............................................... 8 1.2. Optimising the system ................................................................ 15 1.3. General optimisations ................................................................. 19 1.4. Additional configurations ........................................................... 20 1.5. Monitoring .................................................................................. 24 Activities...................................................................................................... 33 Bibliography............................................................................................... 34 GNUFDL • PID_00148473 5 Configuration, tuning and optimisation
    [Show full text]