Linux 性能监控和优化介绍

linux 系统管理员应该精通 Linux 性能监控和优化。本文对我们应该如何在 Linux 中进行性能监控和调整，以及需要监控的各种子系统（和性能指标）进行了高级概述。

要识别系统瓶颈并提出解决方案，您应该了解 Linux 的各种组件是如何工作的。例如，内核如何使用 nice 值优先于一个 Linux 进程，如何处理 I/O 中断，内存管理如何工作，Linux 文件系统如何工作，网络层如何在 Linux 中实现等等。 ,

请注意，了解各种组件（或子系统）的工作原理与了解执行什么命令以获得特定输出不同。例如，您可能知道“uptime”或“top”命令给出了“load average”。但是，如果您不知道它的含义以及 CPU（或进程）子系统如何工作，您可能无法正确理解它。了解子系统是一项持续的任务，您将一直不断地学习。

在非常高的层次上，以下是需要监控的四个子系统。

CPU

Memory

I/O

Network

1. CPU

您应该了解 CPU 的四个关键性能指标——上下文切换、运行队列、cpu 利用率和平均负载。

当 CPU 从一个进程（或线程）切换到另一个时，称为上下文切换。

当进程切换发生时，内核将 CPU（进程或线程）的当前状态存储在内存中。

内核还从内存中检索先前存储的（进程或线程的）状态并将其放入 CPU 中。

上下文切换对于 CPU 的多任务处理非常重要。

但是，更高级别的上下文切换可能会导致性能问题。

运行队列表示当前 CPU 队列中的活动进程总数。

当 CPU 准备好执行一个进程时，它会根据进程的优先级从运行队列中选择它。

请注意，处于睡眠状态或 i/o 等待状态的进程不在运行队列中。

因此，运行队列中更多的进程可能会导致性能问题。

这表明当前使用了多少 CPU。

这相当简单，您可以从top 命令查看 CPU 利用率。

100% CPU 利用率意味着系统已满载。

因此，较高的 CPU 利用率百分比将导致性能问题。

这表示特定时间段内的平均 CPU 负载。

在 Linux 上，显示最后 1 分钟、5 分钟和 15 分钟的平均负载。这有助于查看系统上的整体负载是上升还是下降。

例如，平均负载为“0.75 1.70 2.10”表示系统负载正在下降。0.75 是最后 1 分钟的平均负载。1.70 是最近 5 分钟的平均负载。2.10 是过去 15 分钟的平均负载。

请注意，此负载平均值是通过结合队列中的进程总数和处于不可中断任务状态的进程总数来计算的。

2. Network

在分析任何网络问题时，对 TCP/IP 概念的良好理解是有帮助的。我们将在以后的文章中对此进行更多讨论。

对于网络接口，您应该监控通过接口接收/发送的数据包（和字节）总数、丢弃的数据包数等，

3. I/O

I/O 等待是 CPU 等待 I/O 的时间。如果您在系统上看到持续的高 i/o 等待，则表明磁盘子系统存在问题。

您还应该监控读取/秒和写入/秒。这是以块为单位测量的。即每秒读/写的块数。这些也被称为 bi 和 bo（阻挡和阻挡）。

tps 表示每秒总事务数，它是 rtps（每秒读取事务数）和 wtps（每秒写入事务数）之和。

4. Memory

如您所知，RAM 是您的物理内存。如果您的系统上安装了 4GB RAM，那么您就有 4GB 物理内存。

虚拟内存 = 磁盘上可用的交换空间 + 物理内存。虚拟内存包含用户空间和内核空间。

使用 32 位或 64 位系统在确定进程可以使用多少内存方面有很大的不同。

在 32 位系统上，一个进程最多只能访问 4GB 的虚拟内存。在 64 位系统上没有这样的限制。

未使用的 RAM 将被内核用作文件系统缓存。

Linux 系统会在需要更多内存时进行交换。即当它需要比物理内存更多的内存时。当它交换时，它将物理内存中使用最少的内存页面写入磁盘上的交换空间。

大量交换可能会导致性能问题，因为磁盘比物理内存慢得多，并且将内存页面从 RAM 交换到磁盘需要时间。

以上 4 个子系统都是相互关联的。仅仅因为您看到较高的读取/秒、写入/秒或 I/O 等待并不意味着 I/O 子系统存在问题。它还取决于应用程序在做什么。在大多数情况下，性能问题可能是由 Linux 系统上运行的应用程序引起的。

记住 80/20 法则——80% 的性能改进来自于调整应用程序，其余 20% 来自于调整基础架构组件。

有多种工具可用于监控 Linux 系统性能。例如：top、free、ps、iostat、vmstat、mpstat、sar、tcpump、netstat、iozone 等，我们将在本系列的后续文章中详细讨论这些工具以及如何使用它们。

以下是识别和解决性能问题的 4 步方法。

第 1 步——理解（并重现）问题：当你清楚地理解问题是什么时，问题就解决了一半。在尝试解决性能问题之前，首先要明确定义问题。你花在理解和定义问题上的时间越多，你就会有足够的细节来在正确的地方寻找答案。如果可能，请尝试重现问题，或至少模拟您认为与问题非常相似的情况。这将在稍后帮助您验证您提出的解决性能问题的解决方案。

第 2 步 - 监控和收集数据：明确定义问题后，监控系统并尝试尽可能多地收集各个子系统的数据。根据这些数据，列出潜在问题。

第 3 步 – 消除和缩小问题范围：列出潜在问题后，深入研究每个问题并消除任何非问题。进一步缩小范围以查看它是应用程序问题还是基础架构问题。进一步向下钻取并将其缩小到特定组件。例如，如果是基础架构问题，请缩小范围并确定导致问题的子系统。如果是 I/O 子系统问题，请将其缩小到特定分区、RAID 组、LUN 或磁盘。基本上，继续深入研究，直到找到问题的根本原因。

第 4 步 – 一次一项更改：一旦您缩小到一小部分潜在问题，不要尝试一次进行多项更改。如果您进行多项更改，您将不知道哪一项解决了原始问题。一次进行多项更改也可能会导致新的问题，而您将追逐这些新问题，而不是修复原始问题。所以，一次做一个改变，看看它是否能解决原来的问题。

Linux 任务调度

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。