web-dev-qa-db-ja.com

サーバーはどうなっているのですか?高負荷、多くのアイドルCPU時間、低ディスク使用率

私はWebサイトを運営しており、正規のオプトインの毎日の電子メールニュースレターを購読者に送信しています。ウェブホスティングとメール送信の両方が同じマシンで行われます。

私の毎日の電子メールニュースレターにオプトインしている約100,000人の購読者がいます。私のPHPスクリプトは、ごく最近まで、それらすべてにメールを送信するのにかなり良い仕事をしましたが、リストが大きくなるにつれて、私は追いつくことができません。

CPUが2つしかないにもかかわらず、トップを実行すると、負荷が非常に高くなります(通常、少なくとも6または7、場合によっては15にもなります)。ただし、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)過去1か月に少なくとも5回バウンスしたメールアドレスの登録を解除するスクリプトがすでにあるので、リストがアクティブなメールアドレスに比較的限定されていることを願っています。

2)exim4.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へのこれらのメール配信を処理するための最良の方法は何ですか?

4
Jonathan

前述のように、負荷平均は、実行キューで待機しているプロセスの数に関連しています。これらの各プロセスで実行する作業がほとんどなく、プロセッサをすばやく解放する場合は、CPUごとの一般的な経験則よりもはるかに大きな負荷平均を処理できます。

メールはこれのほぼ完璧な例です。各プロセスはメッセージを送信するためにCPUを必要としますが、ごくわずかです。 25から35の範囲の平均負荷でsendmailを実行しているメールシステムを見てきましたが、システムはまだインタラクティブで正常に動作しています。

マーク

3
mfarver

多くの場合、システムメトリック(負荷、CPU、I/O)は、ほとんどの人がシステムのパフォーマンスを示す唯一の指標ですが、実際のトランザクションパフォーマンスはまったく異なります。これらのメトリックは、パフォーマンスがどのように制約されているかについてのガイダンスを提供できますが、実際には、トランザクションに実際にかかる時間を調べる方がはるかに役立ちます。

メール送信スクリプトが追いつかないのはなぜですか?

これは、メールキューがクリアされないという問題が発生していることを意味しますか?それとも、スクリプトの実行にかかる時間の長さですか?それとも、高負荷に基づいてテレが問題であると推測していますか?

Mfarverが言うように、特にスパムを回避するためにメールサーバーによって実行される同期チェックの数が増えるにつれて、電子メールシステムで高負荷が発生することは珍しくありません。

個人的には、私はeximの大ファンではありません。MTAで本格的なテストを行ってから数年が経過したことは認めますが、sendmailとpostfixの使用経験ははるかに優れています。確かに、あなたは電子メール処理についてもっと洗練されている必要がある球場に入っています。

ロギングをオフにするのではなく、rootアカウントの転送を一時的に追加して、配信されていないすべての電子メールが何であるかを正確に確認することをお勧めします。

MTAは、受信者に直接メールを送信するように構成されていると思います。パフォーマンスに問題がある場合は、スマートリレーを使用してサーバーからメッセージをより速くオフロードすることを検討してください。ただし、Eximをキューに切り替えてみて、最初に負荷(さらに重要なのはパフォーマンス)の問題が解決するかどうかを確認してください。また、DNSキャッシングを調べて、改善できるかどうかを確認してください。

すでにスマートリレーを使用している場合は、正しく構成されていることを確認してください-IME、sendmailベースの設定では、MTAができない場合、php mail()は長い間ブロックを呼び出します(しかし、どういうわけかメッセージはまだ配信されますか?)スマートホストに接続します。

多くの電子メールプロバイダーは現在、スパムブロックの方法としてスロットリングを実装しています-ドメインで電子メールリストを並べ替えるとDNSルックアップを減らすのに役立ちますが、リモートシステムがメールをスロットリングまたはブロックする問題が発生する可能性があります。スパマー(SPF、DKIMなど)のように見えないように、実用的なすべてのことを行っていることを確認してください-IIRC Eximはミルターを直接サポートしていません-利用可能な便利なミルターがたくさんあります-特にミルター制限。

1
symcbean

high loadrun queueの平均サイズです-例: CPUで実行したいプロセス。スクリプトは多くのCPU作業を実行しているようです。したがって、プロファイルを作成して、そのソースをここに投稿する必要があります。どうやって手紙を送るの?

0
osgx

まず第一に、あなたの負荷はそれほど高くはありません。 2 CPUで8の負荷は、CPUあたり4の負荷を意味します。また、最近のCPUは通常デュアルコアであるため、1つに2つのCPUがあるようになり、負荷は実際にはCPUごとに2つになります。

電子メールの処理に関する限り、負荷を減らすためにできることは2つあります。1)電子メールアドレスを「バウンス」としてマークして送信しないように、バウンスされた電子メールを処理するスクリプトがあることを確認します。もうアドレス。大規模なメーリングリストの通常の直帰率は、オプトインリストでも約20%です。サーバーは、他の人には見えない電子メールを送信するだけでなく、バ​​ウンスされた電子メールを受信して​​処理する必要があるため、バウンスはサーバーを実際にバグダウンさせます。

2)メールログへのロギングを無効にします。大量のメーリングリストでは、送信されるすべての電子メールと、受信されるすべてのバウンス電子メールのメールログにエントリが追加されます。メールログへの書き込みは、ディスクへの書き込みを伴うため、非常にリソースを消費します。メールログを無効にするだけで、システムの負荷を「大幅に」減らすことができます。使用しているメールサーバーがわからない場合もありますが、Linuxでは通常/etc/syslog.confを確認します。

メールのエントリをコメントアウトしてから、syslogサービスを再起動するだけです。

もう一度言いますが、バウンスされた電子メールは通常、rootアカウントに返されます。システムがrootアカウントのメールボックス制限(通常は100MB)に達することは非常に一般的です。制限に達すると、バウンスされた電子メールを受け入れることさえできない別の問題が発生しているため、システムが独自のバウンスメッセージを送信してさらに負荷をかけている可能性があります。

結論:バウンスを監視し、リストをクリーンに保ちます-バウンスアカウントをマークし、それらにメールを送信しなくなります。

0
Dmitri

メールログエントリは、各エントリでフラッシュしないようにマークされています。これにより、このログへのCPUオーバーヘッドの書き込みを減らすことができます。ただし、Eximを使用しているため、このログはデフォルトでは使用されません。構成をチェックして、syslogの使用が有効になっていないことを確認してください。

ログに記録される内容を減らすには、構成にlog_selector仕様を追加します。可能な値については、Exim仕様(おそらく第49章)に詳しく説明されています。ただし、これはおそらく問題ではありません。

exiwhatを実行して、試行されている配信を確認してください。 mailqには、1時間以上キューにある配信と配信を待機しているメッセージがたくさんあるべきではありません。しばらくキューにあるメッセージの長いリストは、バウンスする可能性のある配信を試みていることを示しています。

Eximは、同時に実行される多くの配信プロセスを適切に処理しません。役立つ可能性のある構成の変更を確認する必要があります。

  • 再試行の間隔を増やし、メッセージが未配信として返送されるまでの時間を短縮してみてください。これにより、配信不能メッセージのバウンスに必要な試行回数が減ります。
  • 即時配信の試行を無効にして、配信がキューから実行されるようにします。これを条件付きで行うには、queue_only_loadを使用することをお勧めします。
  • queue_run_maxを設定して、キューランナープロセスの数を制限します。

試行された配信を解決してルーティングするには、トランスポートまたはエイリアスを使用できます。 rootを自分のメールアドレスにエイリアスします。 Ubuntuはこのルーターを使用して、rootとして実行される配信を防ぎます。

 mail4root:
 debug_print = "R:mail4root for $ local_part @ $ domain" 
 driver = redirect 
 domains = + local_domains 
 data =/var/mail/mail 
 file_transport = address_file 
 local_parts = root 
 user = mail 
 group = mail
0
BillThor