速度优化 - linux系统提速手记
linux系统提速手记
2004-04-23 15:18 pm来自：Linux文档
现载：Www.8s8s.coM
地址：无名
我的计算机配备如下∶
处理器∶Intel 赛扬 500 MHz
记忆体∶256 Mb PC100 RAM
硬碟∶80Gb 7200 rpm ATA100
显示卡∶tnt2 AGP
声卡∶sb live!
网络卡∶8139
显示器∶mac 796fd2
操作系统∶安装 Win2k server 与 RH7.3 + suse 8.1
一、开启硬盘 DMA 支持。
系统安装完毕後，硬盘的 DMA 是没有打开的，我的方法是在
/etc/rc.d/rc.local 最後面加上一行 /sbin/hdparm -d1 -c3 -m16 /dev/hda 这样每次开机後，硬盘的 DMA 就会开启，不必每次手动设定。
如果您的硬盘机支持 ATA33 可以加上 -X66 这个参数，ATA66则是 -X68，像我的硬盘是 ATA66 那麽完整参数就是 /sbin/hdparm -d1 -X68 -c3 -m16 /dev/hda 经过我的测试 ，在 DMA 未开启以前，实际读取效率是每秒约 4.10 Mb 左右，开启 DMA 後，每秒实际读取效率跃升为 20 Mb 大约提升 5 倍之多。
§未开启 DMA 时的测试
[root@firefly /root]# hdparm -d0 /dev/hda
/dev/hda:
setting using_dma to 0 (off)
using_dma = 0 (off)
[root@firefly /root]# hdparm -Tt /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 2.75 seconds = 46.55 MB/sec
Timing buffered disk reads: 64 MB in 15.58 seconds = 4.11 MB/sec
§开启 DMA 後的测试结果
[root@firefly /root]# hdparm -d1 -X68 -c3 -m16 /dev/hda
/dev/hda:
setting 32-bit I/O support flag to 3
setting multcount to 16
setting using_dma to 1 (on)
setting xfermode to 69 (UltraDMA mode5)
multcount = 16 (on)
I/O support = 3 (32-bit w/sync)
using_dma = 1 (on)
[root@firefly /root]# hdparm -Tt /dev/hda/dev/hda:
Timing buffer-cache reads: 128 MB in 2.75 seconds = 46.55 MB/sec
Timing buffered disk reads: 64 MB in 3.20 seconds = 20.00 MB/sec
由以上的数据，可以看得出来，硬盘 DMA 是否开启，对读取效率影响很大。
二、关闭多馀的系统服务。
这是老生常谈的题目了，一般我们当作桌上型工作站的时候，只需要激活几个基本的?Service 即可，其他的不但没用，一方面会占用系统资源，另一方面则会有安全上的顾虑，我平常只用来连网、打打文件、听听音乐、看看电影，多半时间只是一个 Client 端，实在没必要激活 Server 端的服务，所以，我在 Setup System Services时，只留下以下几个 Service，其馀的都关闭。
1. crond
2. network
3. syslogd
真的，相信我，只要这四个就足够了！
三、下载 Kernel 重新编程。
因为系统所默认安装的 Kernel 是为了适用大部分的计算机而做的，并未对你的计算机作最优化，所以显得臃肿肥大，因为 Kernel 直接掌控著计算机的一切，所以对系统效率影响当然很大。
我的作法是∶下载最新的 Kernel 重新编程，将我计算机上的硬件直接编程进 Kernel 里面，不要作成 Module ，对於不需要的就不编程，这样，打造出完全面向自己环境的 Kernel ，才能完全发挥计算机的威力。
至於 Kernel 怎样编程？这就不是我的主题了，大家可以到CLDP 自行参考 KERNEL HOW-TO 中译版。
四、减少虚拟终端机的数量。
系统默认是６个，也就是 CTRL+ALT F1～F6 那六个，我关掉其中四个，只留下 CTRL+ALT F1～F2，大约省下 4 Mbytes 的记忆体，但是这样一来，X-Window 会从原来的 CTRL+ALT F7 变成 CTRL+ALT F3 。
修改 /etc/inittab 中，将 mingetty 3 ～6 全部加上 # 字号，然後下指令 #init q
五、调整 X-Windows 环境
我习惯操作 KDE ，对 GNOME 不熟，所以，以下是都是面向 KDE而设，GNOME 的使用者，我想，应该也差不多啦！
１、颜色数设为 16 Bit 就有很好的效果了，24 Bit 除了浪费资源，看不出有何好处。
２、不要使用屏幕保护程序。
３、取消动画窗口功能。
４、尽量使用同一种字型。
５、浏览器用 Mozilla 不要用 Netscape。
６、不要激活音效服务器 artd
Speed Up X by Managing Font Setting 在你抱怨 X 跑得不够快之前，
先检查字型设定， 很可能就是影响效能的一大元凶。
先看一下 /etc/X11/XF86Config-4 档案里的 FontPath 设定值， 如果是
如下∶
Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Mandrake 6.0 and later now use a font server independent of
# the X server to render fonts.
FontPath "unix/:-1"
EndSection
可参考 /etc/X11/fs/config 档案里的字型设定值， 挑选几个喜欢的字型目录(全部比较不会错)
来修改， 例如我直接设定下列几个字型目录∶
Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Mandrake 6.0 and later now use a font server independent of
# the X server to render fonts.
FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/Type1"
FontPath "/usr/X11R6/lib/X11/fonts/mdk:unscaled"
FontPath "/usr/share/fonts/ttf/big5"
EndSection
修改之後， 重新激活 startx 感受看看棉。
原本的 FontPath "unix/:-1" 将字型由 X Font Server 来提供，
一般使用者未蒙其利、先受其害， 可以考虑等熟悉 X Font Server 功能後再使用。
如此就可以关掉xfs了
ps:试用时不要用默认开机直接进x-window，若不行会卡在x-window
ps:引用自http://twopensource.org/~marr/xfont_tip.html
六、调整应用程序优先权。
一般时候，我们使用任何程序时，其 NICE 值都是 0，意思是CPU 的使用权值。如果我们常用程序有较高的优先权的话，自然效率就会比较好，优先权的值从 -20 到 19 ，数字越小优先权就越高，但要注意的是一般使用者只能调低( 0～19)，只有 root 有权调高优先权( -20 ～ 19 )。我们可以用 ps -fel 来观察 NI 那栏就知道。
说了半天，到底如何调整呢？有一个指令 /bin/nice 就是用来作这件事的，用法如下∶nice?-n?程序名称?参数．．．．
n 的值从 -20 到 19，这是手动操作，在 KDE 中，可以用选单编辑器来设定，方法是在你要调整优先权的程序的 [ 命令 ] 那一栏的前面，加上 /bin/nice --n 就可以了。
比方说我常用 Mozilla 来浏览网页，我改成 /bin/nice --10 /usr/local/mozilla/mozilla 这样我的 Mozilla 执行时，就比其他程序有更高的优先权，在实际测试的时候，Mozilla 激活速度以及回应都快了不少，其他一些常用的程序，也可以比照办理。
後记
Linux 真的是一套很棒的操作系统，经过这样调整後，光是开机到登入窗口画面出现，从原来的 48 秒，变成 30 秒，用 top 指令(每秒)观察CPU idle 时间也从 82% 提升到 93%，而窗口程序的反应感觉上与 Win me 差不多了。