我的伺服器出了什麼問題?高負載、大量空閒 CPU 時間、低磁碟使用率

我的伺服器出了什麼問題?高負載、大量空閒 CPU 時間、低磁碟使用率

我經營一個網站,並向訂閱者發送合法的選擇加入的每日電子郵件通訊。網頁寄存和電子郵件發送都是在同一台機器上完成的。

我有大約 100,000 名訂閱者選擇接收我的每日電子郵件通訊。直到最近,我的 PHP 腳本在向所有這些人發送郵件方面做得相當不錯,但隨著清單的增長,我無法跟上。

當我運行 top 時,我的負載非常高——通常至少 6 或 7,有時高達 15——即使我只有兩個 CPU。然而,當我運行 sar 時,我的 CPU 平均有大約 30% 的時間處於空閒狀態。所以,看來我不受CPU限制。當我運行 iostat 時,似乎我沒有受到磁碟限制,因為每個設備的 %util 非常低(不超過 5%)。

鑑於我似乎不受 CPU 限製或磁碟限制,為什麼 top 報告負載這麼高?

另外,由於我似乎不受 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/log/exim_mainlog
/var/log/exim_paniclog
/var/log/exim_rejectlog

此外,當我查看 /etc/syslog.conf 時,我看到以下內容:

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

我不知道開頭的“-”是什麼意思,-/var/log/maillog但是當我查看該文件時,很明顯那裡記錄了很多內容。

此外,該文件中還記錄了許多內容:

/var/log/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 資源的情況下,處理這些郵件傳送到 root 的最佳方法是什麼?

答案1

如上所述,平均負載與運行佇列中等待進程的數量有關。如果每個進程只需執行很少的工作並快速釋放處理器,那麼您可以處理比常見的每個 CPU 1 個負載平均負載更大的負載平均負載。

郵件幾乎就是一個完美的例子,每個進程都需要 CPU 來傳送訊息,但非常非常少。我見過運行 sendmail 的郵件系統的平均負載在 25 到 35 範圍內,並且該系統仍然具有交互性並且工作正常。

標記

答案2

系統指標(負載、CPU、I/O)通常是大多數人所掌握的系統效能的唯一指標,但實際的事務效能卻截然不同。這些指標可以提供有關如何限制效能的指導,但實際上,了解事務實際花費的時間會更有用。

為什麼我的電子郵件發送腳本無法跟上?

這是否意味著您遇到了郵件佇列未清理的問題?還是腳本執行的時間長度?或者您根據高負載推斷存在問題?

正如 mfarver 所說,高負載在電子郵件系統上並不罕見,特別是隨著郵件伺服器為避免垃圾郵件而進行的同步檢查數量不斷增加。

就我個人而言,我並不是 exim 的忠實粉絲 - 我對 sendmail 和 postfix 有更好的體驗,儘管我承認我已經好幾年沒有對 MTA 進行過認真的測試了。當然,您正在進入需要對電子郵件處理更加複雜的階段。

與其關閉日誌記錄,不如暫時為根帳戶添加轉發,以準確查看所有未送達的電子郵件的內容。

我猜測 MTA 已配置為將郵件直接發送給收件人。如果您確實遇到效能問題,那麼您可能會考慮使用智慧中繼來更快地從伺服器卸載訊息。但嘗試將 Exim 切換到佇列,看看這是否首先解決了負載(更重要的是任何效能)問題。另外,檢查一下您的 DNS 緩存,看看是否可以改進。

如果您已經在使用智慧中繼,請檢查其配置是否正確- IME,使用基於sendmail 的設置,如果MTA 不能,則php mail() 呼叫會阻塞很長一段時間(但不知怎的訊息仍然可以傳遞? )連接智慧主機。

許多電子郵件提供者現在將限製作為垃圾郵件封鎖的一種方法 - 雖然按網域對電子郵件清單進行排序將有助於減少 DNS 查找,但您最終可能會遇到遠端系統限製或封鎖郵件的問題。請確保您採取一切實際措施以避免看起來像垃圾郵件發送者(例如 SPF、DKIM) - IIRC Exim 不直接支援 milters - 有很多有用的 milters 可用 - 特別是 milter-limit。

答案3

high loadrun queue是- 例如想要在 cpu 上運行的進程的平均大小。看起來你的腳本做了很多 cpu 工作。因此,您必須對其進行概要分析並在此處發布其來源。你如何寄信?

答案4

您的郵件日誌條目被標記為不刷新每個條目。這應該有助於減少寫入此日誌的 CPU 開銷。但是,當您使用 Exim 時,預設情況下不使用此日誌。檢查您的設定以確保您尚未啟用系統日誌的使用。

若要減少記錄的內容,請log_selector在您的配置中新增規格。 Exim 規格(可能是第 49 章)中詳細介紹了可能的值。不過,這可能不是您的問題。

嘗試運行exiwhat以查看正在嘗試哪些交付。mailq不應有大量訊息等待傳遞並已在隊列中等待一個小時或更長時間。佇列中已存在一段時間的一長串郵件表示您正在嘗試投遞,但可能會被退回。

Exim 無法很好地處理同時運行的大量交付流程。您應該查看可能有幫助的配置變更。

  • 嘗試增加重試之間的時間,並減少因未送達而退回郵件之前的時間。這將減少退回無法送達郵件所需的嘗試次數。
  • 停用立即交付嘗試,以便從佇列中運行交付。您可能想要有條件queue_only_load地執行此操作。
  • 設定queue_run_max以限制佇列運行程式進程的數量。

若要解決嘗試傳遞路由的問題,您可以使用傳輸或別名。我將 root 作為我的電子郵件地址的別名。 Ubuntu 使用此路由器來阻止以 root 身分執行交付。

郵件根目錄:
  debug_print = "R: $local_part@$domain 的 mail4root"
  驅動程式 = 重定向
  域 = +本地域
  數據 = /var/mail/mail
  文件傳輸 = 地址文件
  local_parts = 根
  用戶=郵件
  群組=郵件

相關內容