自修补以来,用户抱怨网站速度很慢.大多数请求都是即时提供的,但是现在又一次会被请求“卡住”.在被卡住的请求中似乎没有任何可辨别的模式.
这些服务器位于负载均衡器后面,它们同时更新,并且在修补运行时都开始显示此问题.他们当时没有重新启动,但一直没有效果.
我在服务器上设置了一个脚本来循环时间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左右
内核是一个旧的backport,所以我尝试将它更新到lenny的最新backport(2.6.32-bpo.5-amd64),但它在启动时惊慌失措,我不得不让我们的主机用旧的重启它,所以在我们尝试更新其biose并使用Debian 6格式化之前,我想探索其他选项.
Apache似乎是一个可能的罪魁祸首,所以下一步是更新到最新的apache backport,但是版本从2.2.9-10 lenny4到2.2.9-10 lenny9相当小,所以我没想到任何重大变化.
从dotdeb安装PHP版本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(/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.
我会做更多的挖掘.