[ad_1]
介绍
在这个由两部分组成的系列中，我们概述了在调查服务器负载源自何处或导致服务器过载时要采取的步骤。 在运行托管多个网站的服务器时，经常会出现高负载问题。 要了解发生这种情况的方式和原因，请继续阅读。
什么是服务器负载？
服务器负载是衡量服务器正在经历的工作。 平均负载表示一段时间内的平均系统负载。 服务器将负载平均值计算为负载数字的指数阻尼/加权移动平均值。 平均负载的三个值是指系统运行的过去一分钟、五分钟和十五分钟。 如果您只有一个 CPU，则平均负载是特定时间段内系统利用率的百分比。 如果您有多个 CPU，则必须除以处理器数量以获得可比较的百分比。 要查找服务器上的处理器数量，请运行以下命令。
[email protected] [~]# grep processor /proc/cpuinfo | wc -l
4
[email protected] [~]#解决负载问题
解决服务器上任何负载问题的第一步是为服务器设置一个基准，以确定其静止性能。 虽然这似乎是尝试运行基准测试的不合适时机，但我们需要建立一个基线，看看我们的调整效果如何。 我们经常看到使用适当的配置和缓存来提高性能。 我们建议在服务器处于最不忙的时候运行这个基准测试。 用于基准测试的主要命令如下所示。
[email protected]:~ # ab -lt 10 -c3 -H "Accept-Encoding: gzip,deflate,br" "https://www.domain.com/"这里使用 apachebench（或 ab）命令来提供我们可以用来判断性能的标准。
平均负载
现在我们已经完成了我们的基准测试，我们要查看的下一项是有多少进程正在等待 CPU 资源。 该测量值表示为一段时间内的平均值。 top 命令随着时间的推移以增量方式测量负载。 术语“高负载”是相对于 CPU 可用资源量而言的。
一个有经验的 Linux admin 不得不说。
“服务器负载不应高于服务器拥有的内核总数。 如果服务器有 8 个内核，并且它以 8 个负载运行，则所有 8 个内核都以 100% 的速度运行。”
一分钟平均负载为 8 且使用八核处理器的专用服务器不一定具有所谓的“高负载”。 但是，一分钟平均负载为 8.0 且使用四核处理器的 VPS 服务器 是 可能会遇到“高负载”，因为所有 CPU 内核都以 200% 的容量运行。
我们还必须考虑服务器的响应能力。 如果其中一个托管 Cloud 双核服务器的一分钟平均负载为 4.0，跟上传入的请求，并且响应迅速，服务器很可能不会遇到“高负载”。
注意：调查服务器负载的最佳时间是它发生时，因为您可以最清楚地了解问题。
我们可以使用 w 命令或 top 命令查看一分钟、五分钟和十五分钟的平均负载。
[email protected] [~]# w
17:17:40 up 6 days, 8:13, 0 users, load average: 0.00, 0.03, 0.07
USER TTY FROM [email protected] IDLE JCPU PCPU WHAT
[email protected] [~]#[email protected] [~]# top
top - 17:18:30 up 6 days, 8:13, 0 users, load average: 0.00, 0.02, 0.06
Tasks: 159 total, 1 running, 157 sleeping, 0 stopped, 1 zombie
%Cpu(s): 0.2 us, 0.1 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.4 st
KiB Mem : 3766984 total, 195752 free, 1307504 used, 2263728 buff/cache
KiB Swap: 2047996 total, 763476 free, 1284520 used. 2004704 avail Mem负载类型
通常，服务器负载是由一项或多项服务或其相关应用程序引起的。 以下是通常导致服务器过载的四种主要资源：
- 中央处理器
- 内存
- 磁盘输入/输出
- 联网
中央处理器
使用多个命令之一可以找到服务器所经历的负载类型。 在评估服务器负载时，top 命令应该是我们的首选，因为它使用三个平均负载、系统任务统计、系统 CPU 统计、系统 RAM 统计和系统交换统计打印系统摘要。
当 top 命令运行时，我们可以按“1”键，它会显示系统上每个 CPU 内核的 CPU 统计信息。 这些统计数据分为 8 个百分比，被视为每个 CPU 处理任务的时间百分比。
top - 17:21:36 up 6 days, 8:16, 0 users, load average: 0.09, 0.08, 0.08
Tasks: 158 total, 1 running, 156 sleeping, 0 stopped, 1 zombie
%Cpu0 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st%Cpu1 : 0.3 us, 0.0 sy, 0.0 ni, 99.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.7 st
%Cpu2 : 0.0 us, 0.0 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.7 st
%Cpu3 : 0.3 us, 0.0 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
KiB Mem : 3766984 total, 346856 free, 1283940 used, 2136188 buff/cache
KiB Swap: 2047996 total, 761516 free, 1286480 used. 2028524 avail Mem下表定义了上述标识符。
查看表
| 任务标签 | 任务描述 |
|---|---|
| 我们, 用户 | 运行用户进程的时间 |
| 他的, 系统 | 运行内核进程的时间 |
| 你, 好的 | 运行 niced 用户进程的时间 |
| ID, 闲置的 | 在内核空闲处理程序中花费的时间 |
| 哇, IO等待 | 等待 I/O 完成的时间 |
| 你好 | 服务硬件中断所花费的时间 |
| 和 | 服务软件中断所花费的时间 |
| 英石 | 管理程序从 VM 中窃取的时间 |
CPU 资源的数量通过 CPU 用于处理实际工作负载的时间百分比来衡量。 如果最大的 CPU 百分比时间花在用户进程或系统进程上，这表明服务器被分配了太多资源密集型进程。 以下是导致服务器上 CPU 过载的几个进程示例：
- PHP 脚本
- 多个后台进程
- 格式错误的 MySQL 查询
- Apache 流程
- 恶意软件扫描
内存
RAM，也称为随机存取存储器，是使用 free -m 命令在服务器级别测量的。 此命令向我们显示总内存、已用内存、可用内存、共享内存、缓冲区/缓存内存，最后是可用内存。
[email protected] [~]# free -m
totalusedfreesharedbuff/cacheavailableMem: 3678 1415 403 125 1859 1869
Swap: 1999 1271 728
[email protected] [~]#已用内存占所有正在运行的进程（包括内核）使用的内存，并包括缓冲区/缓存内存。 可用内存估计有多少内存可用于在不交换的情况下启动新进程。
使用 ps 命令查看进程的内存使用情况。 这 %内存 列是进程的驻留集大小与机器物理内存相比的百分比或比率。 驻留集大小（或 RSS）是进程使用的物理 RAM 占用的内存量。 换一种方式， %内存 是进程使用的物理 RAM 的百分比。
一些例子是可以最大化服务器 RAM 的事情：
- PHP/Apache – 如果 PHP (memory_limit * PHP-FPM’s Max_children) 或 FCGI (FCGIdMaxProcesses) 请求超过服务器上的 RAM 量，则可能会因内存耗尽而崩溃。
- MySQL – 如果 MySQL 的最大配置内存限制超过服务器上可用的 RAM 量，则可能由于内存耗尽而崩溃。
磁盘输入/输出
磁盘 I/O 是指物理磁盘上的数据与目标之间的操作传输。 如果我们从磁盘上的文件中读取数据，CPU 需要时间来读取文件。 这同样适用于写作。 磁盘 I/O 可以通过多种方式增加负载。 以下是一些可能超过服务器的磁盘 I/O 的示例：
- RAM 用完并将内存交换到磁盘。
- MySQL 查询将临时表写入磁盘。
- 大量电子邮件从服务器发送。
- 长时间运行的大型备份。
使用 iotop 命令可以显示实际使用的磁盘 I/O 量。
[email protected] [~]# iotop
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd --switched-root --system --deserialize 22
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
4 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
6 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
7 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
8 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_bh]
9 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_sched]
10 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [lru-add-drain]
11 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0]
12 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/1]联网
以太网性能会影响服务器的整体负载。 如果接收到大量流量，则可能会出现网络瓶颈。 通常，当设备之间的通信缺乏快速完成任务所需的带宽或处理能力时，就会发生这种情况。 在高流量时期、DDOS 攻击或慢速loris 攻击期间，满足对服务器的请求所需的网络吞吐量可能会超过容量或锁打开。 发生这种情况时，服务器负载会增加。 优化的网站通常不会遇到这种类型的负载。
使用 iftop 之类的命令行工具可以全面了解网络使用情况。
[email protected] [~]# iftop
interface: eth0
IP address is: 68.228.87.126
MAC address is: 52:54:00:91:87:6f
12.5Kb 25.0Kb 37.5Kb 50.0Kb 62.5Kb
└──────────────────────┴────────────────────┴───────────────────┴───────────────────┴────────────────────────────────────
host.domain.com => 430461.cloudwaysapps.com 40.1Kb 15.1Kb 12.5K <= 7.12Kb 1.99Kb 1.65Kb
host.domain.com => dc2-176.vpn.domain.com 1.39Kb 6.24Kb 5.46Kb <= 160b 1.49Kb 1.29Kb
host.domain.com => 151.139.128.11 0b 1.14Kb 973b <= 0b 5.34Kb 4.45Kb
host.domain.com => lvps87-230-15-219.dedicated.hosteurope.de 0b 1.23Kb 1.02Kb <= 0b 3.77Kb 3.14Kb
host.domain.com => 10.10.10.10 0b 1.50Kb 1.33Kb. <= 0b 2.78Kb 2.44Kb
host.domain.com => 10.30.9.124 0b 1.40Kb 1.17Kb <= 0b 920b 767b
host.domain.com => 10.30.9.125 0b 1.40Kb 1.16Kb <= 0b 920b 767b
host.domain.com => 10.30.9.122 2.91Kb 640b 656b <= 1.50Kb 353b 473b
host.domain.com => 10.30.9.138 0b 468b 427b. <= 0b 310b 295b
───────────────────────────────────────────────────────────────────────────────────────────
TX: cum: 48.8KB peak: 46.7Kb rates: 46.7Kb 30.3Kb 32.5Kb
RX: 24.6KB 56.6Kb 11.3Kb 18.8Kb 16.4Kb
TOTAL: 73.3KB 81.9Kb 结论
这结束了我们关于调查服务器负载的两部分文章系列的第一部分。 服务器负载是服务器经历的工作量度。 当 CPU 使用率、RAM 不足、磁盘 I/O 增加或网络拥塞出现问题时，负载问题就会显现出来。 在本系列的第二部分中，我们将探索定位和解决服务器负载问题的手段和方法。
我们以成为 Hosting™ 中最有帮助的人而自豪！
我们的支持团队由经验丰富的 Linux 技术人员和才华横溢的系统管理员组成，他们对多种网络托管技术（尤其是本文中讨论的技术）有着深入的了解。 如果您对此信息有任何疑问，我们随时可以回答与本文相关的任何问题。
[ad_2]