我有两台运行Debian 5稳定版的戴尔R410networking服务器（2x四核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的工作人员configuration如下：
<IfModule mpm_prefork_module> StartServers 50 MinSpareServers 10 MaxSpareServers 150 ServerLimit 500 MaxClients 500 MaxRequestsPerChild 5000 </IfModule>
对我来说8GB内存的服务器似乎是明智的。 实际上工人人数很less超过170人，所以我们没有达到这个极限，而且有足够的自由记忆。 平均负荷低，他们徘徊在0.5-1.5左右
内核是一个旧的backport，所以我试着将它更新到lenny（2.6.32-bpo.5-amd64）的最新backport，但是它在启动时感到恐慌，我必须让我们的主机重新启动它与旧的我想在尝试更新他们的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 cookies（/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 ，绝大多数连接处于TIME_WAIT状态，而不是SYN_RECV（也许-l选项不显示半开连接）。
但是我们现在经常在dmesg中看到这个：
possible SYN flooding on port 80. Sending cookies.
我会做更多的挖掘。