我的服务器出了什么问题?负载高,大量空闲 CPU 时间,磁盘利用率低

我的服务器出了什么问题?负载高,大量空闲 CPU 时间,磁盘利用率低

我经营一家网站,并向订阅者发送合法的每日电子邮件简讯。网站托管和电子邮件发送均由同一台机器完成。

我有大约 100,000 名订阅者订阅我的每日电子邮件简报。直到最近,我的 PHP 脚本在向所有订阅者发送邮件方面表现都相当出色,但随着订阅者名单的增加,我无法跟上他们的步伐。

当我运行 top 时,负载非常高——通常至少 6 或 7,有时甚至高达 15——尽管我只有两个 CPU。但是,当我运行 sar 时,我的 CPU 平均有大约 30% 的时间处于空闲状态。因此,似乎我没有受到 CPU 限制。当我运行 iostat 时,似乎我没有受到磁盘限制,因为每个设备的 %util 都非常低(不超过 5%)。

鉴于我似乎不受 CPU 或磁盘限制,为什么顶级报告的负载如此之高?

此外,由于我似乎不受 CPU 或磁盘限制,为什么我的电子邮件发送脚本无法跟上?


这是我运行 top 时看到的内容:

top - 11:33:28 up 74 days, 18:49,  2 users,  load average: 7.65, 8.79, 8.28
Tasks: 168 total,   5 running, 162 sleeping,   0 stopped,   1 zombie
Cpu(s): 38.9%us, 58.6%sy,  0.8%ni,  0.0%id,  0.7%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   3083012k total,  2144436k used,   938576k free,   281136k buffers
Swap:  2048248k total,    39164k used,  2009084k free,  1470412k cached

这是我运行 iostat -mx 时看到的内容:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          34.80    1.20   55.24    0.37    0.00    8.38

Device:         rrqm/s   wrqm/s   r/s   w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.19    71.70  1.59 29.45     0.02     0.07     5.90     0.55   17.82   1.16   3.59
sda1              0.00     0.00  0.00  0.00     0.00     0.00     7.10     0.00   13.80  13.72   0.00
sda2              0.05    50.45  1.13 24.57     0.01     0.29    24.25     0.35   13.43   1.15   2.97
sda3              0.05    10.17  0.20  2.33     0.01     0.05    43.75     0.05   20.96   2.45   0.62
sda4              0.00     0.00  0.00  0.00     0.00     0.00     2.00     0.00   70.50  70.50   0.00
sda5              0.07     0.22  0.03  0.07     0.00     0.00    32.84     0.08  856.19   8.03   0.08
sda6              0.02     5.45  0.03  0.72     0.00     0.02    67.55     0.02   26.72   5.26   0.39
sda7              0.00     1.56  0.00  0.42     0.00     0.01    38.04     0.00    8.88   5.84   0.24
sda8              0.01     3.84  0.20  1.35     0.00     0.02    28.55     0.05   31.90   4.08   0.63

这是我运行 sar 时看到的内容:

09:40:02 AM       CPU     %user     %nice   %system   %iowait    %steal     %idle
09:50:01 AM       all     30.59      1.01     49.80      0.23      0.00     18.37
10:00:08 AM       all     31.73      0.92     51.66      0.13      0.00     15.55
10:10:06 AM       all     30.43      0.99     48.94      0.26      0.00     19.38
10:20:01 AM       all     29.58      1.00     47.76      0.25      0.00     21.42
10:30:01 AM       all     29.37      1.02     47.30      0.18      0.00     22.13
10:40:06 AM       all     32.50      1.01     52.94      0.16      0.00     13.39
10:50:01 AM       all     30.49      1.00     49.59      0.15      0.00     18.77
11:00:01 AM       all     29.43      0.99     47.71      0.17      0.00     21.71
11:10:07 AM       all     30.26      0.93     49.48      0.83      0.00     18.50
11:20:02 AM       all     29.83      0.81     48.51      1.32      0.00     19.52
11:30:06 AM       all     31.18      0.88     51.33      1.15      0.00     15.47
Average:          all     26.21      1.15     42.62      0.48      0.00     29.54

以下是我在特定时间运行所列出的最重要的几个进程top -c

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                                                      
 8180 mysql     16   0 57448  19m 2948 S 26.6  0.7   4702:26 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/bristno.pid --skip-external-locking                          
26956 brristno  17   0     0    0    0 Z  8.0  0.0   0:00.24 [php] <defunct>                                                                                                                                                               
26958 brristno  17   0 94408  43m  37m R  5.0  1.4   0:00.15 /usr/bin/php /home/brristno/public_html/dbv.php                                                                                                                               
22852 nobody    16   0  9628 2900 1524 S  0.7  0.1   0:00.17 /usr/local/apache/bin/httpd -k start -DSSL                                                                                                                                    
 8591 brristno  34  19 96896  13m 6652 S  0.3  0.4   0:29.82 /usr/local/bin/php /home/brristno/bin/mailer.php 1qwqyb6 i0gbor                                                                                                               
24469 nobody    16   0  9628 2880 1508 S  0.3  0.1   0:00.08 /usr/local/apache/bin/httpd -k start -DSSL                                                                                                                                    
25495 nobody    15   0  9628 2876 1500 S  0.3  0.1   0:00.06 /usr/local/apache/bin/httpd -k start -DSSL                                                                                                                                    
26149 nobody    15   0  9628 2864 1504 S  0.3  0.1   0:00.04 /usr/local/apache/bin/httpd -k start -DSSL      

谢谢你,德米特里!

1)我已经有一个脚本,可以取消订阅过去一个月内至少被退回五次的电子邮件地址,因此希望这可以将我的列表相对限制为活跃的电子邮件地址。

2) 我使用的是 exim 4.69。我的配置文件位于

/etc/exim.conf

我的日志文件位于:

/var/日志/exim_mainlog
/var/日志/exim_paniclog
/var/日志/exim_rejectlog

此外,当我查看 /etc/syslog.conf 时,我看到以下内容:

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

我不知道开头的“-”是什么意思,-/var/log/maillog但是当我查看该文件时,很明显那里记录了很多内容。

此外,此文件中还记录了大量内容:

/var/日志/exim_mainlog

我从那时起在 /etc/exim.conf 中添加了以下行:

no_message_logs

我认为这将禁用邮件日志记录(我确实重新启动了 exim),但是当我查看 /var/log/maillog 和 /var/log/exim_mainlog 时,两个文件仍在接收新的日志条目。

问题:我如何禁用大多数/所有 exim 日志记录?

3)当我查看 /var/log/exim_paniclog 时,我看到大量类似这样的条目:

2010-12-19 04:03:32 1PUFB1-0006xZ-GF User 0 set for local_delivery transport is on the never_users list

经过一段时间的查看后,似乎这意味着 exim 正在尝试向根电子邮件地址发送邮件。在尽可能少地使用 CPU 资源的情况下,处理这些邮件传递给根的最佳方法是什么?

答案1

如上所述,平均负载与运行队列中等待的进程数有关。如果每个进程的工作量都很少,并且能够快速释放处理器,那么您可以处理比常见的每 CPU 1 个负载大得多的平均负载。

邮件就是一个完美的例子,每个进程都需要 CPU 来发送消息,但占用的资源非常少。我见过邮件系统在平均负载在 25 到 35 范围内运行 sendmail,而系统仍然具有交互性并且运行良好。

标记

答案2

系统指标(负载、CPU、I/O)通常是大多数人衡量系统性能的唯一指标 - 但实际事务性能则完全不同。这些指标可以指导性能如何受到限制,但实际上,查看事务实际需要多长时间更有用。

为什么我的电子邮件发送脚本无法跟上?

这是否意味着您遇到了邮件队列无法清除的问题?还是脚本执行时间过长?或者您是根据高负载推断出存在问题?

正如 mfarver 所说,电子邮件系统高负载的情况并不少见,尤其是当邮件服务器为了避免垃圾邮件而进行的同步检查次数不断增加时。

就我个人而言,我不太喜欢 exim - 我使用 sendmail 和 postfix 的体验要好得多,尽管我承认我已经好几年没有对 MTA 进行过任何认真的测试了。当然,你正在进入一个需要对电子邮件处理有更深入了解的阶段。

不要关闭日志记录,最好暂时为根帐户添加转发功能,以准确查看所有未送达的电子邮件的内容。

我猜 MTA 被配置为直接向收件人发送邮件。如果您确实存在性能问题,那么您可以考虑使用智能中继来更快地从服务器卸载消息。但请先尝试将 Exim 切换到仅队列,看看这是否能解决负载(更重要的是任何性能)问题。此外,请查看您的 DNS 缓存,看看是否可以改进。

如果您已经在使用智能中继,请检查其配置是否正确 - IME,使用基于 sendmail 的设置,如果 MTA 无法连接到智能主机,php mail() 调用会长时间阻塞(但消息仍会被传递?)。

现在,许多电子邮件提供商都实施限制作为垃圾邮件拦截的一种方法 - 虽然按域对电子邮件列表进行排序有助于减少 DNS 查找,但您最终可能会遇到远程系统限制或拦截邮件的问题。请确保您采取一切切实可行的措施,避免看起来像垃圾邮件发送者(例如 SPF、DKIM)- IIRC Exim 不直接支持过滤程序 - 有很多有用的过滤程序可用 - 尤其是过滤程序限制。

答案3

high load是平均大小run queue- 例如要在 CPU 上运行的进程。看起来您的脚本执行了大量 CPU 工作。因此,您必须对其进行分析并在此处发布其来源。您如何发送信件?

答案4

您的邮件日志条目被标记为不在每个条目上刷新。这应该有助于减少写入此日志的 CPU 开销。但是,由于您使用的是 Exim,因此默认情况下不使用此日志。检查您的配置以确保您没有启用 syslog 的使用。

要减少记录的内容,请log_selector在配置中添加规范。Exim 规范(可能是第 49 章)中详细说明了可能的值。不过,这可能不是您的问题。

尝试运行exiwhat以查看正在尝试哪些投递。mailq不应有大量等待投递的消息,这些消息已经在队列中等待了一个小时或更长时间。如果有大量消息已经在队列中等待了一段时间,则表明您正在尝试投递,但这些消息可能会被退回。

Exim 无法很好地处理同时运行的大量交付流程。您应该查看配置更改,这可能会有所帮助。

  • 尝试增加重试次数,并减少将邮件退回为未送达邮件之前的时间。这将减少退回无法送达邮件所需的尝试次数。
  • 禁用立即投递尝试,以便从队列中运行投递。您可能希望有条件queue_only_load地执行此操作。
  • 设置queue_run_max限制队列运行器进程的数量。

要解决尝试传送到路由的问题,您可以使用传输或别名。我将 root 别名为我的电子邮件地址。Ubuntu 使用此路由器来阻止以 root 身份运行的传送。

mail4root:
  debug_print = "R: $local_part@$domain 的 mail4root"
  驱动程序 = 重定向
  域 = +本地域
  数据 = /var/mail/mail
  文件传输 = 地址文件
  local_parts = root
  用户=邮件
  群组 = 邮件

相关内容