4.3. 管理进程

4.3.1. 系统管理员的工作

虽然管理系统资源(包括进程)是本地系统管理员的任务,但普通用户了解一些这方面的知识也无妨,尤其是在涉及到他们自己的进程及其最佳执行时。

我们将在理论层面上稍微解释一下系统性能,但不会深入到硬件优化和其他高级程序。相反,我们将研究普通用户每天遇到的问题,以及用户可以采取哪些措施来最佳地利用可用资源。正如我们在下一节中学到的,这主要是在行动之前先思考的问题。

图 4-2. 你就不能再快点吗?

4.3.2. 需要多长时间?

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 页面以获取所有信息。

4.3.3. 性能

对于用户来说,性能意味着命令的快速执行。另一方面,对于系统管理员来说,性能意味着更多:系统管理员必须为整个系统(包括用户、所有程序和守护进程)优化系统性能。系统性能可能取决于数千个细微之处,而这些细微之处无法通过 time 命令来衡量。

4.3.4. 负载

简而言之:负载取决于系统的正常水平。我那台运行防火墙、SSH 服务器、文件服务器、路由守护进程、sendmail 服务器、代理服务器和其他一些服务的旧 P133,在连接了 7 个用户的情况下也没有抱怨;平均负载仍然为 0。我见过一些(多 CPU)系统在负载为 67 时也运行良好。只有一种方法可以找出什么是正常的——如果您想知道什么是正常的,请定期检查负载。如果您不这样做,您将只能通过命令行响应时间来衡量系统负载,这是一种非常粗略的衡量标准,因为速度会受到数百个其他因素的影响。

请记住,不同的系统在相同的平均负载下表现会有所不同。例如,具有支持硬件加速的显卡的系统在渲染 3D 图像时不会有问题,而相同的系统使用廉价的 VGA 卡在渲染时会大大减速。当我启动 X 服务器时,我的旧 P133 会变得非常不舒服,但在现代系统上,您几乎注意不到系统负载的差异。

4.3.5. 作为用户,我可以做些什么?

庞大的环境会拖慢你的速度。如果您设置了大量的环境变量(而不是 shell 变量)、未优化的长搜索路径(设置路径环境变量时出错)以及更多通常 "临时" 完成的设置,系统将需要更多时间来搜索和读取数据。

在 X 窗口系统中,窗口管理器和桌面环境可能是真正的 CPU 杀手。即使您可以免费下载,一个非常花哨的桌面也是有代价的,因为大多数桌面都无限地提供附加组件。如果您不每年都购买新电脑,适度是一种美德。

4.3.5.1. 优先级

作业的优先级或重要性由其 nice 值定义。 nice 值较高的程序对其他程序、其他用户和系统是友好的;它不是一个重要的作业。 nice 值越低,作业越重要,它将占用更多资源而不会共享它们。

通过增加 nice 值来使作业更“nice”仅对使用大量 CPU 时间的进程(编译器、数学应用程序等)有用。始终使用大量 I/O 时间的进程会自动获得系统奖励并被赋予更高的优先级(更低的 nice 值),例如,键盘输入始终在系统上获得最高优先级。

程序的优先级通过 nice 命令定义。

大多数系统还提供 BSD renice 命令,它允许您更改正在运行的命令的 niceness 值。同样,请阅读 man page 以获取特定于您系统的信息。

Caution交互式程序
 

对交互式程序或在前台运行的作业使用 nicerenice 命令不是一个好主意。

这些命令的使用通常是系统管理员的任务。阅读 man page 以获取有关系统管理员可用的额外功能的更多信息。

4.3.5.2. CPU 资源

在每个 Linux 系统上,即使您是系统上唯一的用户,许多程序也希望同时使用 CPU。每个程序都需要一定数量的 CPU 周期才能运行。有时可能会因为 CPU 太忙而没有足够的周期。 uptime 命令非常不准确(它只显示平均值,您必须知道什么是正常的),但远非无用。如果您认为您的系统响应迟钝是 CPU 的问题,您可以采取一些措施。

  • 在负载较低时运行大型程序。在您的系统上,晚上可能是这种情况。有关调度,请参见下一节。

  • 阻止系统执行不必要的工作:停止您不使用的守护进程和程序,使用 locate 而不是开销大的 find,...

  • 以低优先级运行大型作业

如果这些解决方案在您的特定情况下都不可行,您可能需要升级您的 CPU。在 UNIX 机器上,这是系统管理员的工作。

4.3.5.3. 内存资源

当当前运行的进程需要的内存超过系统物理可用内存时,Linux 系统不会崩溃;它会开始分页或 *交换*,这意味着进程使用磁盘或交换空间上的内存,将物理内存的内容(正在运行的程序片段或交换情况下的整个程序)移动到磁盘,从而回收物理内存以处理更多进程。这会极大地减慢系统速度,因为访问磁盘比访问内存慢得多。 top 命令可用于显示内存和交换空间的使用情况。使用 glibc 的系统提供 memusagememusagestat 命令来可视化内存使用情况。

如果您发现正在使用大量内存和交换空间,您可以尝试

  • 终止、停止或降低那些占用大量内存的程序的优先级

  • 向系统添加更多内存(在某些情况下添加更多交换空间)。

  • 调整系统性能,这超出了本文档的范围。有关更多信息,请参阅 附录 A 中的阅读列表。

4.3.5.4. I/O 资源

虽然 I/O 限制是系统管理员压力的主要来源,但 Linux 系统提供的用于衡量 I/O 性能的实用程序相当有限。 psvmstattop 工具可以指示有多少程序正在等待 I/O; netstat 显示网络接口统计信息,但实际上没有工具可以衡量 I/O 对系统负载的响应,而 iostat 命令提供了通用 I/O 使用情况的简要概述。存在各种图形前端,可以将这些命令的输出转换为人类可理解的形式。

每个设备都有自己的问题,但网络接口的可用带宽和磁盘的可用带宽是 I/O 性能瓶颈的两个主要原因。

网络 I/O 问题

  • 网络过载

    通过网络传输的数据量大于网络的容量,导致所有用户的每个网络相关任务执行缓慢。这些问题可以通过清理网络(主要包括禁用您不需要的协议和服务)或重新配置网络(例如使用子网、用交换机替换集线器、升级接口和设备)来解决。

  • 网络完整性问题

    当数据传输不正确时发生。解决此类问题只能通过隔离故障元素并更换它来完成。

磁盘 I/O 问题

  • 每个进程的传输速率过低

    单个进程的读取或写入速度不足。

  • 总传输速率过低

    系统可以为所有运行的程序提供的最大总带宽不足。

这种问题更难检测,如果过载的硬件是问题的原因,通常需要额外的硬件才能在总线、控制器和磁盘上重新分配数据流。解决此问题的一种方法是使用针对输入和输出操作优化的 RAID 阵列配置。这样,您可以保留相同的硬件。升级到更快的总线、控制器和磁盘通常是另一种选择。

如果过载不是原因,可能是您的硬件逐渐出现故障,或者与系统的连接不良。首先检查触点、连接器和插头。

4.3.5.5. 用户

用户可以根据其资源使用行为分为几类

  • 运行(大量)小型作业的用户:例如,您,Linux 初学者用户。

  • 运行相对较少但大型作业的用户:运行模拟、计算、模拟器或其他占用大量内存的程序的用户,并且这些用户通常有随附的大型数据文件。

  • 运行少量作业但使用大量 CPU 时间的用户(开发人员等)。

您可以看到,对于每类用户,系统要求可能会有所不同,并且很难满足所有人。如果您在多用户系统上,了解其他用户和系统的习惯很有用(也很有趣),以便为您的特定目的充分利用它。

4.3.5.6. 图形工具

对于图形环境,有很多可用的监控工具。下面是 Gnome 系统监视器 的屏幕截图,它具有显示和搜索进程信息以及监视系统资源的功能。

图 4-3. Gnome 系统监视器

还有一些方便的图标可以安装在任务栏中,例如磁盘、内存和负载监视器。 xload 是另一个用于监视系统负载的小型 X 应用程序。找到您最喜欢的!

4.3.5.7. 中断您的进程

作为非特权用户,您只能影响自己的进程。我们已经了解了如何显示进程并过滤掉属于特定用户的进程,以及可能发生的限制。当您看到您的某个进程正在消耗过多的系统资源时,您可以做两件事:

  1. 使进程在不中断它的情况下使用更少的资源;

  2. 完全停止进程。

如果您希望进程继续运行,但也想给系统上的其他进程一个机会,您可以 renice 该进程。除了使用 nicerenice 命令之外,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。

Note没有管道的 UNIX 几乎是不可想象的。
 

管道 (|) 的用法,即将一个命令的输出用作另一个命令的输入,将在下一章 第 5 章 中解释。

在图形环境中,xkill 程序非常易于使用。只需键入命令名称,然后按 Enter,并选择您要停止的应用程序的窗口。它相当危险,因为它默认发送 SIGKILL,所以仅在应用程序挂起时使用它。