介绍
在这个由两部分组成的系列中,我们概述了在调查服务器负载的来源或导致服务器过载时要采取的步骤。 在运行托管多个网站的服务器时,经常会出现高负载问题。 要了解发生这种情况的方式和原因,请继续阅读。
什么是服务器负载?
服务器负载是服务器正在经历的工作量度。 负载平均值表示一段时间内的平均系统负载。 服务器将负载平均值计算为负载数的指数衰减/加权移动平均值。 负载平均值的三个值是指系统运行的过去一分钟、五分钟和十五分钟。 如果您有一个 CPU,则平均负载是特定时间段内系统利用率的百分比。 如果您有多个 CPU,则必须除以处理器数量以获得可比较的百分比。 要查找服务器上的处理器数量,请运行以下命令。
root@host [~]# grep processor /proc/cpuinfo | wc -l
4
root@host [~]#
解决负载问题
解决服务器上任何负载问题的第一步是为服务器确定其静止性能的基准。 虽然这似乎是尝试运行基准测试的不合适时机,但我们需要建立一个基线以了解我们的调整效果如何。 我们经常看到使用适当的配置和缓存来提高性能。 我们建议在服务器最不忙的时候运行这个基准测试。 用于基准测试的主要命令如下所示。
root@host:~ # 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 命令查看一分钟、五分钟和十五分钟的平均负载。
root@host [~]# w
17:17:40 up 6 days, 8:13, 0 users, load average: 0.00, 0.03, 0.07
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root@host [~]#
root@host [~]# 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
负载类型
通常,服务器负载是由一项或多项服务或其相关应用程序引起的。 以下是通常会导致服务器过载的四种主要资源:
- 中央处理器
- 内存
- 磁盘 I/O
- 联网
中央处理器
使用几个命令之一可以找到服务器经历的负载类型。 在评估服务器负载时,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
下表定义了上面的标识符。
查看表
任务标签 | 任务描述 |
---|---|
我们, 用户 | 运行用户进程的时间 |
sy, 系统 | 运行内核进程的时间 |
你, 好的 | 运行 niced 用户进程的时间 |
ID, 闲 | 在内核空闲处理程序中花费的时间 |
哇, IO等待 | 等待 I/O 完成的时间 |
你好 | 服务硬件中断所花费的时间 |
西 | 服务软件中断所花费的时间 |
英石 | 虚拟机管理程序从 VM 中窃取的时间 |
CPU 资源的数量以 CPU 用于处理实际工作负载的时间百分比来衡量。 如果最大的 CPU 百分比时间花费在用户进程或系统进程上,这表明服务器的任务是过多的资源密集型进程。 以下是一些导致服务器上 CPU 过载的进程示例:
- PHP 脚本
- 多个后台进程
- 格式错误的 MySQL 查询
- Apache 流程
- 恶意软件扫描
内存
RAM,也称为随机存取存储器,是在服务器级别使用 free -m 命令测量的。 此命令向我们显示总内存、已用内存、可用内存、共享内存、缓冲区/高速缓存内存,最后是可用内存。
root@host [~]# free -m
totalusedfreesharedbuff/cacheavailableMem: 3678 1415 403 125 1859 1869
Swap: 1999 1271 728
root@host [~]#
已用内存占所有正在运行的进程(包括内核)使用的内存,并包括缓冲区/高速缓存内存。 可用内存估计有多少内存可用于在不交换的情况下启动新进程。
使用 ps 命令查看进程的内存使用情况。 这 %内存 列是进程的驻留集大小与机器物理内存的百分比或比率。 驻留集大小(或 RSS)是物理 RAM 占用的进程使用的内存量。 换一种方式, %内存 是进程使用的物理 RAM 的百分比。
一些例子是可以最大化服务器 RAM 的东西:
- php/Apache – 如果 PHP (memory_limit * PHP-FPM 的 Max_children) 或 FCGI 的 (FCGIdMaxProcesses) 请求超过服务器上的 RAM 量,则可能由于内存耗尽而崩溃。
- MySQL – 如果 MySQL 的最大配置内存限制超过服务器上可用的 RAM 量,则可能由于内存耗尽而崩溃。
磁盘 I/O
磁盘 I/O 是指物理磁盘上的数据与目标之间的操作传输。 如果我们从磁盘上的文件中读取数据,CPU 需要时间来读取文件。 这同样适用于写作。 磁盘 I/O 可以通过多种方式增加负载。 以下是一些可能超出服务器磁盘 I/O 的示例:
- 内存不足并将内存交换到磁盘。
- MySQL 查询将临时表写入磁盘。
- 大量电子邮件从服务器发送。
- 长时间运行的大型备份。
使用 iotop 命令可以显示正在使用的磁盘 I/O 的实际数量。
root@host [~]# 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 之类的命令行工具可以全面了解网络使用情况。
root@host [~]# 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 技术人员和才华横溢的系统管理员组成,他们对多种网络托管技术有着深入的了解,尤其是本文中讨论的技术。 如果您对此信息有任何疑问,我们随时可以回答与本文相关的任何问题。