php – 一些Apache请求很慢,最完整

前端之家收集整理的这篇文章主要介绍了php – 一些Apache请求很慢,最完整前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有两台运行Debian 5稳定版的Dell R410网络服务器(2x四核Xeon E5520 w / 8gb ram).他们的修补程序已经被忽略了一段时间,所以最近我们进行了修补运行以使所有内容都更新 – 它运行的新版本的应用程序需要 PHP 5.3.6.内核没有更新,因为它来自Debian backports存储库(安装的版本是2.6.30-bpo.1-amd64).

自修补以来,用户抱怨网站速度很慢.大多数请求都是即时提供的,但是现在又一次会被请求“卡住”.在被卡住的请求中似乎没有任何可辨别的模式.

这些服务器位于负载均衡器后面,它们同时更新,并且在修补运行时都开始显示此问题.他们当时没有重新启动,但一直没有效果.

我在服务器上设置了一个脚本来循环时间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.

我会做更多的挖掘.

原文链接:https://www.f2er.com/php/139249.html

猜你在找的PHP相关文章