web-dev-qa-db-ja.com

一部のApacheリクエストは遅く、ほとんどが即座に完了します

Debian 5安定版を実行している2台のDell R410 Webサーバー（2xクアッドコアXeon E5520 w/8GB RAM）があります。それらのパッチはしばらくの間無視されていたので、最近、すべてを最新の状態にするパッチ実行を実行しました。これは、PHP 5.3.6。カーネルはDebianバックポートリポジトリからのものであるため更新されませんでした（インストールされているバージョンは2.6.30-bpo.1-AMD64です）。

パッチを適用してから、ユーザーはWebサイトが遅いと不満を漏らしています。リクエストの大部分は即座に処理されますが、時々リクエストで「スタック」します。行き詰まるリクエストに識別可能なパターンはないようです。

これらのサーバーはロードバランサーの背後にあり、同時に更新されており、両方ともパッチ実行時にこの問題を示し始めました。現時点では再起動されていませんが、それ以降何の影響もありません。

ループオーバーするようにサーバー自体にスクリプトを設定しましたtime curl localhost:80/alive、 "OK"のみを含むシンプルなindex.htmlファイルが含まれています。奇妙なことに、これらのリクエストは、実際のphpコンテンツのリクエストと同じ頻度と期間でまだ遅延しています。一般的な時間は3秒、9秒、25秒、45秒で、一部は3分を超えています。 45秒が一般的な応答時間ですが、もちろんブラウザーはこれよりもかなり前に諦めるため、実質的に応答がありません。

Apacheワーカー構成は次のとおりです。

<IfModule mpm_prefork_module>
    StartServers        50
    MinSpareServers     10
    MaxSpareServers     150
    ServerLimit         500
    MaxClients          500
    MaxRequestsPerChild   5000
</IfModule>

8GBのRAMを搭載したサーバーの場合は、私には理にかなっているようです。実際には、ワーカー数が170を超えることはめったにないので、その制限に達しておらず、十分な空きメモリがあります。負荷平均は低く、0.5〜1.5程度で推移します。

カーネルは古いバックポートなので、lennyの最新のバックポート（2.6.32-bpo.5-AMD64）にアップデートしてみましたが、ブート時にパニックになり、ホストに古いもので再起動させる必要があったため、他のオプションを調べてから、それらの生物を更新し、Debian 6でフォーマットする前に調べたいと思います。

Apacheが原因である可能性があるため、次のステップは最新のApacheバックポートに更新することですが、バージョンは2.2.9-10 + lenny4から2.2.9-10 + lenny9へのかなりマイナーなバンプだったので、大きな変化が予想されます。

PHPがインストールされています。バージョン5.3.6はdotdebからです。以前のバージョンは5.3.0カスタムコンパイルでした。さらに、上司から、https経由のリクエストが遅延しないことを通知されましたが、自分で確認していません。

# Apache2 -V
Server version: Apache/2.2.9 (Debian)
Server built:   Dec 11 2010 21:34:00
Server's Module Magic Number: 20051115:15
Server loaded:  APR 1.2.12, APR-Util 1.2.12
Compiled using: APR 1.2.12, APR-Util 1.2.12
Architecture:   64-bit
Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D Apache_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT=""
 -D SUEXEC_BIN="/usr/lib/Apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/Apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/Apache_runtime_status"
 -D DEFAULT_LOCKFILE="/var/run/Apache2/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="/etc/Apache2/mime.types"
 -D SERVER_CONFIG_FILE="/etc/Apache2/Apache2.conf"

# Apache2ctl -t -D DUMP_MODULES
Loaded Modules:
 core_module (static)
 log_config_module (static)
 logio_module (static)
 mpm_prefork_module (static)
 http_module (static)
 so_module (static)
 alias_module (shared)
 auth_basic_module (shared)
 authn_file_module (shared)
 authz_default_module (shared)
 authz_groupfile_module (shared)
 authz_Host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 cgi_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 geoip_module (shared)
 mime_module (shared)
 negotiation_module (shared)
 php5_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 ssl_module (shared)
 status_module (shared)
Syntax OK

どんな援助も大歓迎です！

phplinuxapache-2.2debian-lennypatch
5
Alex Forbes

これで一週間壁にぶつけられて、上司が直してくれた。

ログでApacheの応答時間を確認すると、応答が迅速であることがわかりました。要求がApacheに到達する前に遅延が発生していました。したがって、彼はtcpスタック設定を調べ、Red Hat 5.6を実行している別のサーバーと比較しました。

長い話を簡単に言うと、tcp syn cookie（/etc/sysctl.confのnet.ipv4.tcp_syncookies=1）を有効にすることで問題が修正されました。この設定は、SYNフラッドから保護するように設計されており、明らかにより高速な応答を可能にします。偶然に（または故意に）洪水が発生している可能性があります。

詳細はこのリンクにあり、説明されている症状はまさに私たちが見ていたものです： http://baheyeldin.com/technology/linux/detecting-and-preventing-syn-flood-attacks-web-servers-running -linux.html

私はnetstat -alntを見ていましたが、接続の大部分はSYN_RECVではなくTIME_WAIT状態でした（多分-lオプションはハーフオープン接続を表示しません）。

ただし、これはdmesgで頻繁に見られます。

possible SYN flooding on port 80. Sending cookies.

さらに掘り下げます。

9
Alex Forbes