虽然管理系统资源(包括进程)是本地系统管理员的任务,但普通用户了解一些这方面的知识也无妨,尤其是在涉及到他们自己的进程及其最佳执行时。
我们将在理论层面上稍微解释一下系统性能,但不会深入到硬件优化和其他高级程序。相反,我们将研究普通用户每天遇到的问题,以及用户可以采取哪些措施来最佳地利用可用资源。正如我们在下一节中学到的,这主要是在行动之前先思考的问题。
Bash 提供了一个内置的 time 命令,用于显示命令执行所需的时间。计时非常精确,可以用于任何命令。在下面的示例中,制作这本书大约需要一分半钟。
tilly:~/xml/src> time make Output written on abook.pdf (222 pages, 1619861 bytes). Transcript written on abook.log. real 1m41.056s user 1m31.190s sys 0m1.880s |
GNU time 命令位于/usr/bin(与 shell 内置版本相反)显示更多信息,这些信息可以用不同的方式格式化。它还显示命令的退出状态和总经过时间。与上面相同的命令,使用独立的 time 命令,会给出以下输出。
tilly:~/xml/src> /usr/bin/time make Output written on abook.pdf (222 pages, 1595027 bytes). Transcript written on abook.log. Command exited with non-zero status 2 88.87user 1.74system 1:36.21elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (2192major+30002minor)pagefaults 0swaps |
再次参考 Info 页面以获取所有信息。
对于用户来说,性能意味着命令的快速执行。另一方面,对于系统管理员来说,性能意味着更多:系统管理员必须为整个系统(包括用户、所有程序和守护进程)优化系统性能。系统性能可能取决于数千个细微之处,而这些细微之处无法通过 time 命令来衡量。
执行的程序编写不良或没有适当地使用计算机
访问磁盘、控制器、显示器、各种接口等。
远程系统的可达性(网络性能)
系统上的用户数量,实际同时工作的用户数量
一天中的时间
...
简而言之:负载取决于系统的正常水平。我那台运行防火墙、SSH 服务器、文件服务器、路由守护进程、sendmail 服务器、代理服务器和其他一些服务的旧 P133,在连接了 7 个用户的情况下也没有抱怨;平均负载仍然为 0。我见过一些(多 CPU)系统在负载为 67 时也运行良好。只有一种方法可以找出什么是正常的——如果您想知道什么是正常的,请定期检查负载。如果您不这样做,您将只能通过命令行响应时间来衡量系统负载,这是一种非常粗略的衡量标准,因为速度会受到数百个其他因素的影响。
请记住,不同的系统在相同的平均负载下表现会有所不同。例如,具有支持硬件加速的显卡的系统在渲染 3D 图像时不会有问题,而相同的系统使用廉价的 VGA 卡在渲染时会大大减速。当我启动 X 服务器时,我的旧 P133 会变得非常不舒服,但在现代系统上,您几乎注意不到系统负载的差异。
庞大的环境会拖慢你的速度。如果您设置了大量的环境变量(而不是 shell 变量)、未优化的长搜索路径(设置路径环境变量时出错)以及更多通常 "临时" 完成的设置,系统将需要更多时间来搜索和读取数据。
在 X 窗口系统中,窗口管理器和桌面环境可能是真正的 CPU 杀手。即使您可以免费下载,一个非常花哨的桌面也是有代价的,因为大多数桌面都无限地提供附加组件。如果您不每年都购买新电脑,适度是一种美德。
作业的优先级或重要性由其 nice 值定义。 nice 值较高的程序对其他程序、其他用户和系统是友好的;它不是一个重要的作业。 nice 值越低,作业越重要,它将占用更多资源而不会共享它们。
通过增加 nice 值来使作业更“nice”仅对使用大量 CPU 时间的进程(编译器、数学应用程序等)有用。始终使用大量 I/O 时间的进程会自动获得系统奖励并被赋予更高的优先级(更低的 nice 值),例如,键盘输入始终在系统上获得最高优先级。
程序的优先级通过 nice 命令定义。
大多数系统还提供 BSD renice 命令,它允许您更改正在运行的命令的 niceness 值。同样,请阅读 man page 以获取特定于您系统的信息。
![]() | 交互式程序 |
---|---|
对交互式程序或在前台运行的作业使用 nice 或 renice 命令不是一个好主意。 |
这些命令的使用通常是系统管理员的任务。阅读 man page 以获取有关系统管理员可用的额外功能的更多信息。
在每个 Linux 系统上,即使您是系统上唯一的用户,许多程序也希望同时使用 CPU。每个程序都需要一定数量的 CPU 周期才能运行。有时可能会因为 CPU 太忙而没有足够的周期。 uptime 命令非常不准确(它只显示平均值,您必须知道什么是正常的),但远非无用。如果您认为您的系统响应迟钝是 CPU 的问题,您可以采取一些措施。
在负载较低时运行大型程序。在您的系统上,晚上可能是这种情况。有关调度,请参见下一节。
阻止系统执行不必要的工作:停止您不使用的守护进程和程序,使用 locate 而不是开销大的 find,...
以低优先级运行大型作业
如果这些解决方案在您的特定情况下都不可行,您可能需要升级您的 CPU。在 UNIX 机器上,这是系统管理员的工作。
当当前运行的进程需要的内存超过系统物理可用内存时,Linux 系统不会崩溃;它会开始分页或 *交换*,这意味着进程使用磁盘或交换空间上的内存,将物理内存的内容(正在运行的程序片段或交换情况下的整个程序)移动到磁盘,从而回收物理内存以处理更多进程。这会极大地减慢系统速度,因为访问磁盘比访问内存慢得多。 top 命令可用于显示内存和交换空间的使用情况。使用 glibc 的系统提供 memusage 和 memusagestat 命令来可视化内存使用情况。
如果您发现正在使用大量内存和交换空间,您可以尝试
终止、停止或降低那些占用大量内存的程序的优先级
向系统添加更多内存(在某些情况下添加更多交换空间)。
调整系统性能,这超出了本文档的范围。有关更多信息,请参阅 附录 A 中的阅读列表。
虽然 I/O 限制是系统管理员压力的主要来源,但 Linux 系统提供的用于衡量 I/O 性能的实用程序相当有限。 ps、vmstat 和 top 工具可以指示有多少程序正在等待 I/O; netstat 显示网络接口统计信息,但实际上没有工具可以衡量 I/O 对系统负载的响应,而 iostat 命令提供了通用 I/O 使用情况的简要概述。存在各种图形前端,可以将这些命令的输出转换为人类可理解的形式。
每个设备都有自己的问题,但网络接口的可用带宽和磁盘的可用带宽是 I/O 性能瓶颈的两个主要原因。
网络 I/O 问题
网络过载
通过网络传输的数据量大于网络的容量,导致所有用户的每个网络相关任务执行缓慢。这些问题可以通过清理网络(主要包括禁用您不需要的协议和服务)或重新配置网络(例如使用子网、用交换机替换集线器、升级接口和设备)来解决。
网络完整性问题
当数据传输不正确时发生。解决此类问题只能通过隔离故障元素并更换它来完成。
磁盘 I/O 问题
每个进程的传输速率过低
单个进程的读取或写入速度不足。
总传输速率过低
系统可以为所有运行的程序提供的最大总带宽不足。
这种问题更难检测,如果过载的硬件是问题的原因,通常需要额外的硬件才能在总线、控制器和磁盘上重新分配数据流。解决此问题的一种方法是使用针对输入和输出操作优化的 RAID 阵列配置。这样,您可以保留相同的硬件。升级到更快的总线、控制器和磁盘通常是另一种选择。
如果过载不是原因,可能是您的硬件逐渐出现故障,或者与系统的连接不良。首先检查触点、连接器和插头。
用户可以根据其资源使用行为分为几类
运行(大量)小型作业的用户:例如,您,Linux 初学者用户。
运行相对较少但大型作业的用户:运行模拟、计算、模拟器或其他占用大量内存的程序的用户,并且这些用户通常有随附的大型数据文件。
运行少量作业但使用大量 CPU 时间的用户(开发人员等)。
您可以看到,对于每类用户,系统要求可能会有所不同,并且很难满足所有人。如果您在多用户系统上,了解其他用户和系统的习惯很有用(也很有趣),以便为您的特定目的充分利用它。
对于图形环境,有很多可用的监控工具。下面是 Gnome 系统监视器 的屏幕截图,它具有显示和搜索进程信息以及监视系统资源的功能。
还有一些方便的图标可以安装在任务栏中,例如磁盘、内存和负载监视器。 xload 是另一个用于监视系统负载的小型 X 应用程序。找到您最喜欢的!
作为非特权用户,您只能影响自己的进程。我们已经了解了如何显示进程并过滤掉属于特定用户的进程,以及可能发生的限制。当您看到您的某个进程正在消耗过多的系统资源时,您可以做两件事:
使进程在不中断它的情况下使用更少的资源;
完全停止进程。
如果您希望进程继续运行,但也想给系统上的其他进程一个机会,您可以 renice 该进程。除了使用 nice 或 renice 命令之外,top 也是一种简单的方法,可以找到有问题的进程并降低其优先级。
在 "NI" 列中识别进程,它很可能具有**较高的 nice 值**,意味着较低的优先级。键入 r 并输入您要 renice 的进程的进程 ID。然后输入 nice 值,例如 "20"。这意味着从现在开始,此进程最多将占用 1/5 的 CPU 周期。
您希望保持运行的进程示例包括模拟器、虚拟机、编译器等等。
如果您想停止进程,因为它挂起或在 I/O 消耗、文件创建或系统资源使用方面完全失控,请使用 kill 命令。如果有机会,首先尝试软性终止进程,向其发送 SIGTERM 信号。这是一个根据程序代码中描述的过程终止其正在执行的操作的指令。
joe:~> ps -ef | grep mozilla joe 25822 1 0 Mar11 ? 00:34:04 /usr/lib/mozilla-1.4.1/mozilla- joe:~> kill -15 25822 |
在上面的示例中,用户 joe 停止了他的 Mozilla 浏览器,因为它挂起了。
有些进程比较难摆脱。如果您有时间,您可能想向它们发送 SIGINT 信号来中断它们。如果这也不起作用,请使用最强烈的信号 SIGKILL。在下面的示例中,joe 停止了一个冻结的 Mozilla。
joe:~> ps -ef | grep mozilla joe 25915 1 0 Mar11 ? 00:15:06 /usr/lib/mozilla-1.4.1/mozilla- joe:~> kill -9 25915 joe:~> ps -ef | grep 25915 joe 2634 32273 0 18:09 pts/4 00:00:00 grep 25915 |
在这种情况下,您可能需要检查进程是否真的已终止,再次对 PID 使用 grep 过滤器。如果这只返回 grep 进程,您可以确定您已成功停止该进程。
难以终止的进程之一是您的 shell。这是一件好事:如果它们很容易被终止,您每次在命令行意外键入 Ctrl-C 时都会丢失您的 shell,因为这相当于发送 SIGINT。
![]() | 没有管道的 UNIX 几乎是不可想象的。 |
---|---|
管道 (|) 的用法,即将一个命令的输出用作另一个命令的输入,将在下一章 第 5 章 中解释。 |
在图形环境中,xkill 程序非常易于使用。只需键入命令名称,然后按 Enter,并选择您要停止的应用程序的窗口。它相当危险,因为它默认发送 SIGKILL,所以仅在应用程序挂起时使用它。