如何调查服务器负载：第 2 部分

介绍

在关于服务器负载的第二篇教程中，我们概述了在调查服务器负载的来源以及可能导致服务器过载的原因时应采取的步骤。如第 1 部分所述在我们的系列中，过度使用任何应用程序或服务通常会导致负载问题。以下是四个主要关注领域：

中央处理器
内存（包括交换）
磁盘 I/O
联网

历史负载

通常，在对服务器负载进行故障排除时，我们会收到有关高负载错误的通知或收到一封电子邮件，通知我们有关已经过去的事件。除非一个 admin 可以在负载发生时登录，试图确定负载的来源是困难的。话虽如此，我们可以使用多种工具来确定负载发生期间发生的时间范围和负载平均值。第一步使用 sar -q 命令来定位负载发生的时间范围。

搜救指挥部

使用萨尔具体来说，我们可以查看过去的负载历史记录，以确定它何时经历了升高的服务器负载。如果我们看到高负载时间的模式，例如在每月 22 日凌晨 1:00 和凌晨 2:00 之间，我们可以继续前进并使用 sar 命令查看记录的时间之间的负载。下面是 example 使用 sar 命令的输出 -q 旗帜。

root@host [~]# sar -q -f /var/log/sa/sa22
Linux 3.10.0-1127.19.1.el7.x86_64 (host.mylwinfo.com) 01/22/2021 _x86_64_  (4 CPU)

12:00:01 AM runq-sz  plist-sz ldavg-1   ldavg-5  ldavg-15   blocked
12:10:01 AM  5        567      0.06      0.11      0.12         0
12:20:01 AM  9        567      0.03      0.04      0.08         0
12:30:01 AM   4       576      0.24      0.14      0.11         8
12:40:01 AM   7       576      0.04      0.07      0.11         0
12:50:01 AM   7       570      0.08      0.06      0.09         0
01:00:02 AM   8       578      0.03      0.07      0.08         0
01:10:01 AM   5       570      0.00      0.04      0.05         0
01:20:01 AM   7       577      0.00      0.02      0.05         1
01:30:02 AM   3       573      0.06      0.03      0.05         0
01:40:01 AM   6       566      0.06      0.05      0.05         0
01:50:01 AM   6       563      0.07      0.08      0.05         0
02:00:01 AM   16      589      0.14      0.06      0.06         2
02:10:02 AM   1       577      1.10      1.16      0.69         4
02:20:01 AM   10      581      1.87      1.76      1.27         2
02:30:01 AM   6       571      0.04      0.40      0.81         1
02:40:01 AM   4       567      0.03      0.10      0.46         2
02:50:01 AM   8       568      0.10      0.08      0.27         1
03:00:01 AM   10      647      0.14      0.11      0.20         0
03:10:01 AM   4       638      0.04      0.09      0.16         0
03:20:01 AM   8       640      0.06      0.09      0.13         0
03:30:01 AM   9       651      0.04      0.25      0.22         0
03:40:01 AM   8       629      0.10      0.16      0.20         1

该命令的完整输出显示为 1 月 22 日上午 12:00:01 到晚上 11:50:01。应该注意的是，sar 日志每月轮换一次，并覆盖一个月前的日志。这萨尔命令还可以使用各种标志查看 CPU、内存、交换和 I/O 数据。

当前负载

如果 admin 可以立即登录，下面提到的几个工具在推断高服务器负载方面非常出色。

HTOP

此命令是交互式进程查看器、进程管理器和系统监视器，旨在替代最佳命令。要安装它，我们使用以下命令。

root@host [~]# yum install htop

要查看当前统计信息，只需运行 htop 命令。

使用该菜单，我们可以对按多种因素（包括 PID、用户、优先级、状态、时间以及 CPU 和内存使用百分比）细分的信息进行排序、过滤和搜索。假设负载不太高，这是一个很好的工具，我们可以使用它来定位和停止轨道中的高负载。

PCP/Dstat

在之前的知识库文章中，我们回顾了 PCP 或性能副驾驶. 五氯苯酚是一种评估和评估工具，以前称为 Dstat。这是用于在检查当前和以前的操作数据时收集广泛的服务器指标。作为旁注，数据统计 RedHat 接管后更名为 PCP。 Dstat 是以下 Linux 工具集的通用替代品：

vmstat
静压器
网络统计
ifstat

RedHat 还添加了额外的功能，例如更多的计数器和比那些旧工具更高的灵活性。要安装 PCP，请访问 PCP主页工具. dstat 的另一个功能是能够运行 dstat 的 cron 命令以每 X 秒/分钟拍摄一次服务器进程的快照。然后，它允许我们将该信息记录为 .csv 格式，我们可以稍后将其下载并导入到 excel 或 google 表格中以供查看。

解决高负载问题

一旦我们确定负载的来源，我们就可以分解高服务器负载问题。

中央处理器

通常，围绕高 CPU 负载的问题表明我们需要额外的内核来处理系统的额外工作负载。我们可以解决的另一个原因是使用应用程序来优化或减少应用程序的使用或水平扩展应用程序。如第 1 部分所述，CPU 使用率增加的一些常见原因如下：

PHP 脚本
多后台进程
畸形 MySQL 查询
Apache 流程

这是我们可以用来收集有关 CPU 进程和队列使用情况的信息的命令。

root@host [~]# resize; clear; date; echo "Top 10 Processes";echo "";ps -eo user,%cpu,%mem,
rsz,args|sort -rnk2|awk 'BEGIN {printf "%st%st%st%st%sn","USER","%CPU",
"%MEM","RSZ","COMMAND"}{printf "%st%g'%'t%g'%'t%d MBt%-10sn",$1,$2,$3,
$4/1024,$5}'|head -n10;echo "";sar -u 2 5;echo "";sar -q 2 5

该命令提供这样的输出。

Wed Jan 27 14:26:50 EST 2021
Top 10 Processes

USER    %CPU    %MEM    RSZ     COMMAND
mysql   0.3%    3.9%    146 MB  /usr/sbin/mysqld
cpanelc+        0.2%    0%      2 MB    /usr/local/cpanel/3rdparty/sbin/p0f
wp-tool+        0%      0.1%    5 MB    /usr/bin/sw-engine
wp-tool+        0%      0.1%    4 MB    /usr/bin/sw-engine
USER    0%      0%      0 MB    COMMAND
systuser        0%      0.5%    20 MB   Sonar

Linux 3.10.0-1127.19.1.el7.x86_64 (host.mylwinfo.com)   01/27/2021      _x86_64_        (4 CPU)

02:26:50 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
02:26:52 PM     all      0.12      0.00      0.12      0.00      0.37     99.38
02:26:54 PM     all      0.00      0.00      0.00      0.00      0.25     99.75
02:26:56 PM     all      0.00      0.00      0.12      0.00      0.50     99.38
02:26:58 PM     all      0.00      0.00      0.00      0.00      0.37     99.63
02:27:00 PM     all      0.37      0.00      0.25      0.00      1.36     98.01
Average:        all      0.10      0.00      0.10      0.00      0.57     99.23

PHP

如果一个 PHP 脚本被过度使用或编码不好，它会患病的导致 CPU 负载过大。该脚本应由 Web 开发人员审查和优化。通常，这些脚本在网站上执行特定功能，例如文件操作、内容管理、处理多媒体职责或用于提高网站可用性或功能的其他实用程序角色。

Apache/后台进程

后台进程，如恶意软件扫描或增加 Apache 流程会对可用资源产生严重影响。如果同时发生足够多的这些进程，则会消耗可用的 RAM，并且服务器开始遇到交换问题。为了解决这个问题，用户应该使用这样的命令来识别与增加的负载相关的特定进程来查找 Apache的最高要求。

root@host [~]# cut -d' ' -f7 /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20
2886972 /
   1107 /.env
   1016 /robots.txt
    688 /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
    582 /index.php
    470 /favicon.ico
    453 /TP/public/index.php
    449 /config/getuser?index=0
    427 /manager/html
    424 /TP/index.php
    411 /thinkphp/html/public/index.php
    410 /public/index.php
    398 /html/public/index.php
root@host [~]#

接下来，我们还可以检查网站是否被来自 IP 地址的请求过多。

root@host [~]# cut -d' ' -f1 /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -25 | column -t

985      77.229.244.46
978      189.236.73.159
963      125.25.205.227
963      103.229.183.192
950      115.75.104.128
903      185.239.242.215
840      193.239.147.178
724      193.239.147.186
691      76.74.148.29
641      94.102.50.143
583      195.54.160.21
548      123.206.50.168
530      5.101.0.209
474      91.241.19.84
408      59.127.45.109
389      103.95.8.190
378      114.35.68.107
363      103.92.25.78
357      92.126.211.33
355      41.175.155.78
347      45.134.82.253
332      195.54.160.135
root@host [~]#

太多的连接可能表明机器人、网络爬虫或某人经常访问该网站。

最后，这是一个命令，它向我们展示了前 10 个内存利用率进程（包含子聚合）。

root@host [~]# ps axo rss,comm,pid | awk '{ proc_list[$2]++; proc_list[$2 "," 1] += $1; } END { for (proc in proc_list) { printf("%dt%sn", proc_list[proc "," 1],proc); }}' | sort -n | tail -n 10
13796   dockerd
21520   SonarPush
25512   lfd
39888   python3
44220   php-fpm
51128   cpsrvd
56232   php
106356  httpd
156492  mysqld
523904  clamd
root@host [~]#

MySQL

格式错误的 MySQL 查询也会对负载产生重大影响。如果用户正在与试图从现有数据库中提取特定信息的网站进行交互，则备份的 MySQL 进程将延迟该数据的返回。如果足够多的这些进程同时运行，它将迫使负载更高。使用 mysqladmin 进程列表命令将有助于识别 MySQL 的当前工作负载。

root@host [~]# mysqladmin processlist
+--------+
| Id  | User | Host | db | Command | Time | State | Info | Progress |
+--------+
| 1   | system user |    | Daemon  | InnoDB purge worker      | 0.000    |
| 2   | system user |    | Daemon  | InnoDB purge coordinator | 0.000    |
| 4   | system user |    | Daemon  | InnoDB purge worker      | 0.000    |
| 3   | system user |    | Daemon  | InnoDB purge worker      | 0.000    |
| 5   | system user |    | Daemon  | InnoDB shutdown handler  | 0.000    |

另一个用于识别来自 MySQL 的负载的工具是 Mytop。 Mytop 是一个开源的命令行工具，用于监控 MySQL 的性能。它是最佳命令并具有基于终端的界面来监控 MySQL 的整体性能。使用这种方法，我们可以看到来自数据库的查询是如何执行的。

一旦找到格式错误的查询，我们就可以让开发人员调整它们以更有效地运行。否则，如果它们是负载的主要原因，则应重写或删除它们。

记忆

如果没有适当的工具和信息，可能很难找到与内存或 RAM 消耗相关的高负载的原因。幸运的是，我们可以使用这样的命令来使用终端识别内存使用情况概览。

此命令的输出如下所示。

Wed Jan 27 14:43:31 EST 2021
awk: cmd. line:1: BEGIN {FS=" "}{printf "nAvailtActivetTotaltPercent Availn%sMBt%sMBt%sMBt%snn",$4+$5,$6,$4+$5+$6,($4+$5)/($4+$5+$6)*100}
awk: cmd. line:1:                       ^ backslash not last character on line
awk: cmd. line:1: BEGIN {FS=" "}{printf "nAvailtActivetTotaltPercent Availn%sMBt%sMBt%sMBt%snn",$4+$5,$6,$4+$5+$6,($4+$5)/($4+$5+$6)*100}
awk: cmd. line:1:                       ^ syntax error    USER   %CPU   %MEM      RSZ COMMAND
    root    0.0   15.1   555.68 MB /usr/local/cpanel/3rdparty/bin/clamd
   mysql    0.3    3.9  146.953 MB /usr/sbin/mysqld
g33kinfo    9.7    2.1  77.5586 MB php-fpm:
g33kinfo    4.6    1.5  58.4375 MB php-fpm:
    root    1.0    1.4  54.9141 MB /opt/alt/php74-imunify/usr/bin/php
    root    2.4    1.0  39.1133 MB /opt/alt/python35/bin/python3
    root    1.7    0.9  36.0352 MB /opt/alt/python35/bin/python3
    root    0.0    0.7   26.918 MB cpsrvd
    root    0.0    0.6  25.3125 MB lfd

Linux 3.10.0-1127.19.1.el7.x86_64 (host.mylwinfo.com)   01/27/2021      _x86_64_        (4 CPU)

02:43:31 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
02:43:33 PM    309532   3457452     91.78    215880   1616540   5070160     87.19   1404328   1709384       344
02:43:35 PM    390092   3376892     89.64    215880   1620340   4951008     85.14   1362512   1669656       412
02:43:37 PM    388080   3378904     89.70    215880   1621152   4973132     85.52   1364784   1670468       420
^C
02:43:38 PM    361204   3405780     90.41    215892   1622888   4999824     85.98   1390580   1672156       484
Average:       362227   3404757     90.38    215883   1620230   4998531     85.96   1380551   1680416       415

Linux 3.10.0-1127.19.1.el7.x86_64 (host.mylwinfo.com)   01/27/2021      _x86_64_        (4 CPU)

02:43:38 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
02:43:40 PM     all      1.13      0.00      0.13     24.69      0.63     73.43
02:43:42 PM     all      3.99      0.00      2.58     23.07      2.32     68.04
02:43:44 PM     all      5.06      0.00      1.17     22.70      1.82     69.26
02:43:46 PM     all      0.12      0.00      0.25     24.72      0.50     74.41
02:43:48 PM     all      3.82      0.00      0.51     25.19      0.89     69.59
Average:        all      2.80      0.00      0.92     24.08      1.22     70.98

可以在此处查看显示内存使用情况的更详尽的命令。

格式良好的输出如下。

== Server Time: ==
2021-01-27 02:50:06 PM

== Memory Utilization Information: ==
Total Memory    Active Memory   Percentage Used
3678M           0M              0.00%

== Current Swap Usage: ==
DEVICE               USED              TOTAL    PERCENT USED
/dev/vda2  1499.74M  2000.00M  74.99%
== Top 10 Processes by Memory Usage: ==
USER    PID    %MEM  RSZ     COMMANDroot    2215   14.9  563148  /usr/local/cpanel/3rdparty/bin/clamdmysql   1191   3.9   150480  /usr/sbin/mysqldroot    15187  1.4   56232   /opt/alt/php74-imunify/usr/bin/phproot    12576  1.0   40084   /opt/alt/python35/bin/python3root    13002  0.7   27564   cpsrvdroot    47801  0.6   25920   lfdnobody  99176  0.6   25212   /usr/sbin/httpdnobody  99324  0.6   25080   /usr/sbin/httpdnobody  40054  0.6   24152   /usr/sbin/httpd
root    15420  0.6   23912   /usr/local/cpanel/3rdparty/bin/perl

== Top 10 Processes By Swap Usage: ==
PID    PROCESS     SWAP
2215   clamd       633.36M
1364   named       292.50M
977    rsyslogd    149.05M
1191   mysqld      109.23M
52159  php-fpm     72.66M
1360   dockerd     35.03M
52164  php-fpm     28.88M
1025   containerd  28.64M
939    tuned       12.85M
1056   run-script  12.51M

== Top 10 Kernel Slab Caches: ==
SIZE     NAME
106.41M  ext4_inode_cache
51.34M   radix_tree_node
21.59M   kmalloc-2048
14.27M   dentry
12.16M   inode_cache
9.45M    buffer_head
9.06M    kmalloc-512
6.25M    kmalloc-192
5.88M    kmalloc-256
3.84M    kmalloc-1024

== Last 30 Minutes Memory Usage: ==
02:10:01 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
02:20:01 PM    394892   3372092     89.52    186972   1791996   4502996     77.44   1702664   1330604       140
02:30:01 PM    278952   3488032     92.59    182660   1844708   4583800     78.83   1763660   1382000      1072
02:40:01 PM    478732   3288252     87.29    211216   1584016   4980100     85.64   1468992   1467576       144
02:50:01 PM    516000   3250984     86.30    260268   1414912   5030872     86.52   1259140   1617076       828
Average:       417144   3349840     88.93    210279   1658908   4774442     82.11   1548614   1449314       546

== Last 30 Minutes Paging/Swap Statistics: ==
02:10:01 PM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
02:20:01 PM    293.67     82.92   5881.40      4.30   3205.94     50.32      0.00     48.36     96.09
02:30:01 PM    183.14     60.00   4211.40      3.46   2441.86     27.97      0.00     27.47     98.21
02:40:01 PM    886.77    109.05   4756.09      1.31   3219.39     54.63      0.00     51.24     93.79
02:50:01 PM   1987.77    146.82   9831.37      5.97   7140.46    173.18     48.66    218.12     98.33
Average:       838.22     99.71   6171.33      3.76   4002.99     76.56     12.18     86.34     97.30

== Current 1 Second Memory Usage Statistics (10 Count): ==
02:50:10 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
02:50:11 PM    561296   3205688     85.10    260344   1436072   4820100     82.89   1210256   1630628       396
02:50:12 PM    581888   3185096     84.55    260356   1444944   4769172     82.02   1180624   1639364       644
02:50:13 PM    578084   3188900     84.65    260356   1449008   4769176     82.02   1180404   1643412       828
02:50:14 PM    577960   3189024     84.66    260356   1449164   4769176     82.02   1180404   1643504       848
02:50:15 PM    573992   3192992     84.76    260356   1453148   4769176     82.02   1180412   1647512       872
02:50:16 PM    550716   3216268     85.38    260356   1453304   4813672     82.78   1204252   1647616       892
02:50:17 PM    569768   3197216     84.87    260356   1457372   4769168     82.02   1180928   1651716       916
02:50:18 PM    569752   3197232     84.88    260364   1457448   4769168     82.02   1180448   1651752       940
02:50:19 PM    567892   3199092     84.92    260364   1459156   4769168     82.02   1180456   1653500       960
02:50:20 PM    567892   3199092     84.92    260364   1459272   4769168     82.02   1180492   1653556       984
Average:       569924   3197060     84.87    260357   1451889   4778714     82.18   1185868   1646256       828

== Current 1 Second Paging/Swap Statistics (10 Count): ==
02:50:10 PM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
02:50:11 PM   4096.00      0.00  11152.00      0.00    372.00      0.00      0.00      0.00      0.00
02:50:12 PM   8852.00    476.00  18888.00      3.00  19614.00      0.00      0.00      0.00      0.00
02:50:13 PM   4096.00      0.00   1823.00      0.00   1055.00      0.00      0.00      0.00      0.00
02:50:14 PM      0.00      0.00     34.00      0.00     49.00      0.00      0.00      0.00      0.00
02:50:15 PM   4096.00      0.00     38.00      0.00     54.00      0.00      0.00      0.00      0.00
02:50:16 PM      0.00      0.00  11140.59      0.00   1865.35      0.00      0.00      0.00      0.00
02:50:17 PM   4096.00      0.00  15499.00      0.00  16205.00      0.00      0.00      0.00      0.00
02:50:18 PM      0.00     60.00     34.00      0.00     49.00      0.00      0.00      0.00      0.00
02:50:19 PM   1780.00      0.00     34.00      0.00     50.00      0.00      0.00      0.00      0.00
02:50:20 PM      0.00      0.00     40.00      0.00     66.00      0.00      0.00      0.00      0.00
Average:      2698.90     53.55   5873.53      0.30   3935.86      0.00      0.00      0.00      0.00
root@host [~]#

诚然，这是大量的输出数据，但拥有这样的工具只会增强我们的整体内存使用情况。

磁盘 I/O

在搜索由磁盘 I/O 引起的负载问题时，访问时间是驱动因素。磁盘 I/O 是物理磁盘驱动器上的输入/输出操作。如果服务器从磁盘文件读取或写入数据，处理器将等待文件被写入或读取。由于较旧的硬盘驱动器往往是机械的，因此服务器等待将磁盘旋转到所需的磁盘扇区。

通常，观察高磁盘 I/O 吞吐量的最简单方法是使用 iotop 命令。运行它提供了一个简单的读数，显示磁盘 I/O 的来源。

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]
    13 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/1]

另一个可以显示磁盘 I/O 的命令行工具是在顶上. 命令在顶上提供更全面的硬件视图。

如果查看 DSK 行，我们可以看到以下信息。

DSK |  vda |  busy 0% |  read 0 |  write 5 |  KiB/r  0 |  KiB/w  33  | MBr/s 0.0  | MBw/s    0.0  | avq     1.00  | avio 0.20 ms

可以在此处查看指示 I/O 使用情况的最后一个命令。

root@host [~]# dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 2.57465 s, 417 MB/s
root@host [~]#

此命令对磁盘进行实际读/写检查以测量吞吐量。它向磁盘发送/接收 1 GB 的数据，然后计算速度和传输速度。在这种情况下，它移动了 417MB/s。

为了解决由 I/O 等待引起的负载，我们必须减少读/写次数，修改我们使用 I/O 的配置（如 mysql），或者使用更快的磁盘驱动器。现代 SSD 驱动器显着减少了这个问题。更多的先进技术可以使用，但需要开发人员或系统管理员来实施。

联网

通常，只有几个因素定义了由网络问题引起的负载。其中包括网络饱和、网络协议配置不正确和恶意流量。

网络饱和的症状包括但不限于丢包、无法访问的网站和服务器负载增加（试图消化流入的流量）。此外，假设有一个 Web 应用程序防火墙或软件防火墙，并且防火墙规则配置错误（例如试图阻止来自多个国家的大量 IP）。在这种情况下，由于该应用程序的工作负载增加，可能会出现负载。

随着流媒体的兴起，从一个站点运行多个大型视频流也会对出站网络连接造成压力。这种压力可以减少整体流量，大大增加负载。

IPTraf

我们可以用来检查我们收到的流量的工具之一是 IPTraf。

这 iptraf-ng 命令会打开一个图形界面，允许我们选择多个选项来查看网络连接。在菜单中，首先选择 IP流量监控进而所有接口显示 eth0、lo、docker 和其他可用接口上的所有流量。

选择“General interface statistics”时，我们会看到以下信息。

iptraf-ng 1.1.4
┌ Iface ── Total ── IPv4 ── IPv6 ── NonIP ── BadIP ── Activity 
│ lo       68       68      0       0        0        6.98 kbps          
│ eth0     541      507     34      0        0        23.22 kbps         
│ docker0  0        0       0       0        0        0.00 kbps  
────────────
─────────

选择“统计细分”时，我们会看到此信息。

iptraf-ng 1.1.4
┌ Proto/Port ─ Pkts ─ Bytes ─ PktsTo ─ BytesTo ─ PktsFrom ─ BytesFrom
│ TCP/443       528    226088  289     109761     239       116327                                                              
│ UDP/53        6      563     3       204        3         359                                                              │
 TCP/80        22     2475    13      1289       9         1186                                                              
│ UDP/546       6      820     0       0          6         820                                                              
│ UDP/547       6      820     6       820        0         0                                                              
│ TCP/21        18     586     10      488        8         1098                                                              
│ TCP/110       16     904     10      536        6         368

该工具提供了进出服务器的流量的独特视图。它可以帮助我们根据我们在哪个接口和端口上接收的流量来跟踪网络备份。

为了降低由这些问题引起的负载，我们必须降低或限制流量的类型或数量。我们还必须确保我们的网络配置不会导致此问题。

结论

服务器总是会有轻微的负载，这是意料之中的。 Linux 可以控制大多数负载问题，但我们必须在需要时介入以定位和降低高负载问题。上述工具为跟踪下载问题提供了坚实的基础，无论它来自何处。

我们以成为 Hosting™ 中最乐于助人的人而自豪！

我们的技术支持人员全年 365 天、每周 7 天、每天 24 小时随时可以帮助解决与本文相关的任何问题。

我们可以通过我们的票务系统 [email protected]、电话（800-580-4986）或通过在线聊天或您喜欢的任何方法。我们为您努力工作，以便您可以放松。

介绍

历史负载

搜救指挥部

当前负载

HTOP

PCP/Dstat

解决高负载问题

中央处理器

这是我们可以用来收集有关 CPU 进程和队列使用情况的信息的命令。

PHP

Apache/后台进程

MySQL

记忆

磁盘 I/O

联网

IPTraf

结论

Related Posts

使用 OpenSSL 测试 SSL 连接

如何在 CentOS 6 上移除（删除）用户

为什么您的 IP 地址被阻止？

如何刷新本地 DNS 缓存

如何在邮箱上设置电子邮件

如何在 Ubuntu 上创建自签名 SSL 证书