📄 00000000.htm
字号:
<HTML><HEAD> <TITLE>BBS水木清华站∶精华区</TITLE></HEAD><BODY><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER>发信人: althea (痛并快乐着), 信区: Linux <BR>标 题: Linux Performance Turing -- Linux Turing Basics <BR>发信站: BBS 水木清华站 (Tue Nov 9 01:52:11 1999) <BR> <BR> Linux Tuning Basics <BR> Before reading anything else, make sure you have done this <BR> <BR> <BR>1. Introduction <BR> <BR>This site is focussed around performing tuning on a Linux box. <BR>That means attempting to wring the maximum performance possible <BR>from the hardware and software. <BR> <BR>There is no such thing as a typical linux box. What we are <BR>attempting to show is the items to look at when making <BR>optimisations to your system. As such, we have to assume a <BR>general base level of knowledge and system setup. The idea of <BR>this document is to provide that. At the same time, it is a bit <BR>of a prep into how hardware and software relate together (so that <BR>you understand why all the rest of the stuff at this site works). <BR> <BR>If you are using you system for typical home use, many of the <BR>suggestions here might be a bit of "overkill". If you are <BR>attempting to run a web server, mail server, database server, <BR>file server, etc. you will want to make sure your system follows <BR>the guidelines presented here. If you don't, many of the <BR>suggestion presented thought the rest of the site may not have <BR>the effect that is expected. In other words, before you push your <BR>system pass the limits, make sure you are reaching the limits <BR>first! <BR> <BR>1.1 What is covered <BR> <BR>This document is structured around three basic areas for that all <BR>tuning attempts to make the most of: Disk, Networking, Memory. <BR>Without these working to their maximum extent your CPU will be <BR>wasting clock cycles. No point having a Pentium IX/6GHz if you <BR>only have a 14k4 modem and an IDE disk. <BR> <BR>1.2 Further Information <BR> <BR>Also, the following links might be a good way to get started <BR>before you read the rest of this: <BR> <BR> Benchmarking HOWTO (a bit dated) <BR> <A HREF="http://metalab.unc.edu/LDP/HOWTO/Benchmarking-HOWTO.html">http://metalab.unc.edu/LDP/HOWTO/Benchmarking-HOWTO.html</A> <BR> Configuration HOWTO <BR> <A HREF="http://metalab.unc.edu/LDP/HOWTO/Config-HOWTO.html">http://metalab.unc.edu/LDP/HOWTO/Config-HOWTO.html</A> <BR> Installation HOWTO <BR> <A HREF="http://metalab.unc.edu/LDP/HOWTO/Installation-HOWTO.html">http://metalab.unc.edu/LDP/HOWTO/Installation-HOWTO.html</A> <BR> <BR>2. Disk <BR> <BR>Disks come in many forms, from the old MFM/RLL drives to today's <BR>SCSI screamers. Optimising for this can be difficult. Luckily, <BR>hard drives are a constant that you know about in the box you are <BR>working on. Disks keep a permanent record of everything that <BR>occurs so that you can switch the power off and restart the box <BR>in pretty much the same state as it was before. Therefore, almost <BR>every form of service ends up needing to use a disk somewhere. <BR> <BR>2.1 Simple Disk I/O <BR> <BR>Today there are two basic mainstream standards for talking to a <BR>disk - IDE and SCSI. A third standard - FibreChannel is available <BR>to the really, really expensive systems. <BR> <BR>The two standards are more or less the same age, give or take a <BR>year or two(SCSI being the slightly older). Both have been <BR>stretched well beyond their original specs. No matter what we say <BR>about the current best transfer rates, they will be out of date <BR>within the next few months anyway. So, we'll concentrate on the <BR>basic philosophical differences. <BR> <BR>SCSI started at the high end and worked its way down. IDE started <BR>at the bottom and worked its way up. For a given machine, a <BR>single SCSI controller can handle more devices (15) than IDE (4). <BR>Both can handle hard disks, removable media like CDs and tape, <BR>and floppy drives. Where they differ is how they approach the <BR>real low level stuff like controlling the access to the device. <BR>SCSI devices have a controller chip that is used to process most <BR>of the information during the transfers. IDE does not have a <BR>controller. Therefore most of the control must be done by the <BR>CPU. So, instantly, on a heavily loaded system, you can see that <BR>a SCSI device will not load the system up as much as an IDE <BR>device. If your system needs a lot of CPU grunt for processing <BR>databases or dynamic web pages you will see that otherwise <BR>identical systems will producer a faster system with SCSI drives. <BR> <BR>If you are going for performance on a system, you need SCSI. <BR>While you can do it with UDMA/IDE, anything that is high disk i/o <BR>needs to move the disk processing from the main CPU to a SCSI <BR>controller. This is the basic approach of many computer tasks. <BR>Want faster 3D graphics, move the task to a dedicated video chip. <BR>Better sound - get a dedicated sound card. <BR> <BR>2.2 Single v's Multiple Disks <BR> <BR>Hard drives are cheap. Rarely these days do you find a box <BR>running around with only a single drive in it. There is a huge <BR>difference between having two disks in your machine and a RAID <BR>system. However, any of the tricks of RAID can be applied to your <BR>humble desktop. <BR> <BR>Put simply, if you have more than one disk in you machine, make <BR>use of it. Even with IDE, you can make some very significant <BR>performance gains by using both disks in parallel. <BR> <BR>With the speed of the modern bus, a single disk is not capable of <BR>consuming all of the available bandwidth. A well tuned system <BR>seeks to use as much bandwidth as possible. Having two or more <BR>drives operating in parallel means much higher bandwidth <BR>utilisation. For example, say you have the typical / and /usr <BR>setup on two different partitions. If there are on the same disk, <BR>it will run slower than having one on each disk. <BR> <BR>2.3 Organise the hardware <BR> <BR>If there is any chance in your system to make things run in <BR>parallel - do so. All modern systems come with dual IDE channels <BR>in them. Run one disk on each if you have two disks. This applies <BR>to any device connected to the IDE controller: including CDROMs <BR>and floppies. <BR> <BR>With SCSI, this decision can be a bit tough. If you have two <BR>controllers and two disks, should you go this parallel route? <BR>Probably not (discounting the RAID controller and standard <BR>controller pairings). If you need to do a lot of disk to disk <BR>copying then keeping two SCSI disks on the same bus actually is <BR>much quicker than having them on separate ones (the need to pass <BR>the data over the internal system bus is usually much slower). If <BR>there is minimal disk to disk transfer then parallelling may be a <BR>good option. <BR> <BR>SCSI also provides another challenge: The SCSI bus runs at the <BR>speed of the slowest device on it. Get an old SCSI I drive and <BR>connect it to the an Ultra Wide controller and another UW disk <BR>and everything runs like wet cement. Keep them on separate <BR>controllers if at all possible. This problem does not seem to <BR>effect IDE drives as much. Obviously, from this, you should try <BR>to keep devices of the same speed connected together. If you have <BR>SCSI hard drives, instead of slaping a SCSI CDROM on with them, <BR>get an IDE cdrom unless you happen to have a Ultra SCSI II cdrom <BR>to put with your ULTRA II Hard Drives <BR> <BR>2.4 Organise your data <BR> <BR>The simplest rule - the thing that requires the most data should <BR>go on the fastest drive you've got. <BR> <BR>With RAID, it has the highest capable bandwidth of the lot. That <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -