一些 Apache 請求很慢，大部分是即時完成的
我有兩台執行 Debian 5 stable 的 Dell R410 Web 伺服器（2 個四核 Xeon E5520 w/8gb ram）。他們的更新檔已經被忽略了一段時間，所以最近我們進行了一次更新檔執行以使所有內容都保持最新狀態——它執行的應用程序的新版本需要 PHP 5.3.6。核心沒有更新，因為它來自 Debian backports 儲存庫（安裝的版本是 2.6.30-bpo.1-amd64）。
自打更新檔以來，使用者抱怨網站執行緩慢。大多數請求都會立即得到處理，但有時它會“卡住”請求。卡住的請求似乎沒有任何明顯的模式。
這些伺服器位於負載均衡器後面，它們同時更新，並且在修補執行時都開始出現此問題。他們當時沒有重新啟動，但從那以後就沒有效果了。
我在伺服器本身上設置了一個腳本來循環
time curl localhost:80/alive，其中有一個簡單的 index.html 文件，其中只包含“OK”。奇怪的是，這些請求仍然會以與實際 php 內容請求相同的頻率和持續時間延遲。常見的時間是 3 秒、9 秒、25 秒、45 秒，有些超過 3 分鐘。45 秒是一個常見的響應時間，但當然瀏覽器在此之前就放棄了，所以它實際上是沒有響應的。apache worker 配置如下：
<IfModule mpm_prefork_module> StartServers 50 MinSpareServers 10 MaxSpareServers 150 ServerLimit 500 MaxClients 500 MaxRequestsPerChild 5000 </IfModule>對於具有 8gb 記憶體的伺服器來說，這對我來說似乎是明智的。在實踐中，工人數很少超過 170，所以我們沒有達到這個限制並且有足夠的可用記憶體。平均負載較低，徘徊在 0.5-1.5 左右
核心是一個舊的反向埠，所以我嘗試將它更新到最新的 lenny 反向埠（2.6.32-bpo.5-amd64），但它在啟動時出現恐慌，我不得不讓我們的主機用舊的重新啟動它，所以在我們嘗試更新他們的 bioses 並使用 Debian 6 格式化它們之前，我想探索其他選項。
Apache 似乎是罪魁禍首，所以下一步是更新到最新的 apache backport，但該版本從 2.2.9-10+lenny4 到 2.2.9-10+lenny9 是一個相當小的提升，所以我不是預計會有任何重大變化。
已安裝 PHP，來自 dotdeb 的版本為 5.3.6。以前的版本是 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非常感謝任何幫助！
一個星期以來一直在牆上撞牆，我的老闆已經修好了。
一旦我們在日誌中查看 Apache 的響應時間，我們就會發現它的響應速度很快——延遲甚至在請求到達 Apache 之前就發生了。因此，他查看了 tcp 堆棧設置，將它們與另一台執行 Red Hat 5.6 的伺服器進行了比較。
長話短說，啟用 tcp syn cookie（
net.ipv4.tcp_syncookies=1在 /etc/sysctl.conf 中）已經解決了這個問題。此設置旨在防止 SYN 氾濫，並且顯然確實允許更快的響應。我們可能會意外（或故意）被淹。更多資訊在此連結中，所描述的症狀正是我們所看到的：http: //baheyeldin.com/technology/linux/detecting-and-preventing-syn-flood-attacks-web-servers-running-linux.html
我正在查看，
netstat -alnt絕大多數連接都處於 TIME_WAIT 狀態，而不是 SYN_RECV（可能 -l 選項不顯示半開連接）。然而，我們現在經常在 dmesg 中看到這一點：
possible SYN flooding on port 80. Sending cookies.我會做更多的探勘。