调整 Tux,第 2 部分

作者:Marcel Gagné

既然我已经从休假状态恢复过来,让我们回到手头的一些正事上来,即为了乐趣、性能以及更好地了解您的 Linux 系统的内部结构而调整老旧的 Tux。在上一期中,我为您提供了一些在 /proc 文件系统中调整网络参数的想法。对于许多 /proc 调整,只需在相应的文件中写入适当的值,就会发生奇妙的事情。作为回顾,以下是我们所做的通过 /proc 而不是在启动时或通过其他菜单来启用 IP 转发的操作。

   echo "1" > /proc/sys/net/ipv4/ip_forward

为了确保这些参数生效,我们会将此行添加到我们的 rc.local 启动脚本中并完成。这引出了我在休假期间收到读者的一些问题。有人发邮件告诉我他们在 Debian 系统上找不到 rc.local。对此表示歉意。虽然我尽量使我的专栏不特定于发行版,但我有时会陷入“我正在运行此系统”的陷阱。为了让您了解 rc.local,我需要向您介绍运行级别以及每次系统启动时运行的一些脚本。启动时执行的内容部分由位于 rc#.d 文件中的符号链接定义。“#”代表与运行级别相对应的数字。

什么是运行级别?在您的 /etc/inittab 文件中,您会找到一个类似于这样的条目。

    id:3:initdefault:

请注意行首的“3”。这告诉我,当系统启动时,默认情况下,它将切换到运行级别 3(这是完全多用户模式,带有命令行登录)。如果您的系统显示“5”,这告诉我您正在直接启动到图形桌面。每个运行级别启动的内容都将在随附的 /etc/rc#.d 目录中找到,在我的情况下,是 rc3.d。是的,这是真的。我仍然是一个命令行爱好者,使用 startx 命令启动我的 X 桌面。

无论如何,回到这个 rc.local 文件。在 Red Hat(或 Mandrake)系统上,您会在 /etc/init.d 下找到它。我听到后面有人喊,“等一下,停在那里!您刚才不是说它会在 rc3.d 目录中吗?” 确实是,或多或少是这样。

如果您将目录更改为 /etc/rc3.d,您会看到许多以“S”或“K”开头的脚本文件。执行 ls -l,您会注意到它们都是指向其他地方目录的符号链接。在 SuSE 系统上,rc#.d 目录位于 /sbin/init.d 下,但您仍然会找到那些“S”或“K”文件,它们指向 /sbin/init.d。在我的 Red Hat 系统的情况下,它们指向回 /etc/rc.d/init.d 目录。

    lrwxrwxrwx   1 root  root  11 Jul 12 16:09 /etc/rc.d/rc5.d/S99local -> ../rc.local

在 Debian 系统上,这些脚本指向回 /etc/init.d,我将在那里创建我的 rc.local 文件。在我的系统上,事实证明 rc.local 是通过调用 S99local 执行的。例如,在 Debian 系统上,在适当的运行级别目录下查找(或创建)一个 S99local 文件。我(或 Red Hat)对 S99local 的使用(在某种程度上)是一种约定,但是,如果您愿意,您可以更随意一些。名称的第一部分“S”表示“启动”(“K”表示“kill”),而 99 只是一个足够大的数字,它很可能是您的系统在启动时执行的最后一件事。“local”部分只是对我来说有意义的名称。您可以将其称为“rclocal”或“systemlocal”或“iceberg”。因此,如果我想在 Debian 系统上的运行级别 3 中启动此文件,我将创建一个如下所示的符号链接。

    ln -s /etc/init.d/rc.local /etc/rc3.d/S99local

确保(当然)脚本是可执行的。现在,让我们回到其中一些调整。

上次我给您介绍的都是网络调整。这次,我想向您展示一些文件系统技巧。在过去(使用其他 UNIX 系统)的日子里,我管理的系统运行着复杂的数据库,通常有数百个用户。我喜欢以下调整,因为它们代表了如果您发现自己开始资源不足时需要重建内核的参数。您做出了最好的猜测,但不可避免地,很快就会到内核重建的时候了。使用 Linux,这些参数是简单的 /proc 调整。如果您正在运行一个繁忙的数据库系统,并且有大量用户,那么您可能会遇到这种情况。“file-max”参数定义了您的系统在任何给定时间可以打开的最大文件数。对于大多数人来说,默认的“4096”已经足够了。对于更繁忙的系统,您可能需要稍微提高这个限制。例如,让我们将这个数字加倍。

    echo "8192" > /proc/sys/fs/file-max

如果您收到错误提示您正在耗尽文件句柄,那么绝对是时候更改该数字了,但不要等到用户开始抱怨。无需等待错误,您可以查看一下底层,看看何时接近此限制。(预防性维护。多么棒的概念。)如果您在 /proc/sys/fs/file-nr 上执行 cat 命令,您将获得三个数字。第三个将是您的 file-max。第一个和第二个分别是已分配的文件句柄数和实际使用的文件句柄数。为什么有两个数字?当 Linux 内核分配文件句柄时,它不会释放它。如果您确实增加了 file-max 值,那么您也应该增加 inode-max。考虑到每个打开的文件都需要一个 inode 用于 stdin、stdout(以及可能的网络套接字),这需要略高于您的 file-max。取您的 file-max 值,将其乘以三,然后将其写回 inode-max。

    echo "24576" > /proc/sys/fs/inode-max

繁忙的 Web 服务器?新闻服务器?这是另一个针对您的文件的调整,这个调整与 /proc 无关。mount 命令的一个选项是“noatime”。换句话说,不要(甚至不要考虑)更新访问文件的访问时间。每次读取文件时,都会更新访问时间,这可以提供有关文件使用情况的有用信息(例如,使用 find 命令)。您可能不需要该信息。对于每天(每小时?)获得数千次点击的 Web 服务器,这个小小的更改可能会有所作为。从历史上看,此选项是对新闻服务器上目录的建议。今天,我们通常谈论的是 Web 服务器。这是一个反复访问小文件的环境(与传统上文件数量相对较少、文件较大的数据库环境相反)。

要挂载 noatime 文件系统,请使用“-o”标志,如下所示。在本示例中,我们将使用虚拟驱动器“hda5”。

     mount -o noatime /dev/hda5 /data1

如果您希望此操作自动发生,您也可以编辑您的 /etc/fstab 文件,以便您拥有类似于这样的条目。

     /dev/hda5      /data1          ext2    defaults,noatime      1 2

一天的文件调整就到此为止。在结束之前,我想谈谈调整的必要性。另一种看待它的方式是:您如何知道您可能遇到了某种瓶颈?最可靠的方法之一就是通过您的系统已有的各种工具来监控您的系统性能。其中最基本的是一个名为 uptime 的小程序,我们大多数人都用它来让使用 Windows 的朋友们抓狂。“啊,我看到你今天已经重启了两次。让我运行 uptime 看看我得到了什么。

   # uptime
    1:21pm  up 127 days,  6:02,  4 users,  load average: 0.31, 0.29, 0.26

“我的天,我的天,我的天。您看看那个?127 天,6 小时 2 分钟没有重启。”

在我们陷入太多麻烦之前,让我们看看程序还告诉您什么。有四个用户已登录。过去 1 分钟的平均负载为 0.31,过去 5 分钟的平均负载为 0.29,过去 15 分钟的平均负载为 0.26。平均负载大致表示 CPU 运行队列中的进程数;也就是说,处于活动状态或等待执行的进程数。如果这有帮助,您可以将其视为在候诊室等待看医生的患者人数。在这种情况下,我平均有三分之一个进程等待处理。平均负载的数字越高,您的系统就越有可能开始在过载下运行。俗话说,您的里程可能会有所不同,但我倾向于认为任何低于 4 的都是可以接受的。任何高于 4 的都开始感觉缓慢。我见过系统运行在 15 到 20 左右,我告诉你,这很糟糕。

如果这些数字很高,那么下一个问题是“为什么?”。随之而来的是其他问题。是什么阻碍了事情的进展?如果我用完了某些东西,我怎么知道那是什么东西?而这些正是我希望在下次我们在这里会面时考虑的问题。在那之前,给 Tux 做个调整。你们可能都会喜欢它。

加载 Disqus 评论