Назад | Перейти на главную страницу

Некоторые запросы Apache выполняются медленно, большинство из них выполняется мгновенно

У меня есть два веб-сервера Dell R410 (2 четырехъядерных процессора Xeon E5520 с оперативной памятью 8 ГБ), на которых работает стабильный Debian 5. Их исправление какое-то время игнорировалось, поэтому недавно мы провели запуск исправлений, чтобы обновить все, но без выхода новой версии приложения, которое оно запускает, для которого требуется PHP 5.3.6. Ядро не было обновлено, поскольку оно было получено из репозитория резервных копий Debian (установленная версия - 2.6.30-bpo.1-amd64).

После установки исправления пользователи жаловались, что веб-сайт работает медленно. Большинство запросов обслуживаются мгновенно, но время от времени он «застревает» на запросе. Похоже, что в застрявших запросах нет какой-либо заметной закономерности.

Эти серверы находятся за балансировщиком нагрузки, они были обновлены одновременно, и у обоих появилась эта проблема во время запуска исправления. Они не были перезагружены в то время, но с тех пор безрезультатно.

Я настраиваю скрипт на самих серверах, чтобы перебрать time curl localhost:80/alive, в котором есть простой файл 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>

Мне это кажется разумным для сервера с 8 ГБ оперативной памяти. На практике количество рабочих редко превышает 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

Любая помощь очень ценится!

Уже неделю бью себя об стену, и мой босс починил.

Посмотрев на время отклика Apache в журналах, мы увидели, что он отвечает быстро - задержки происходили еще до того, как запрос достиг Apache. Таким образом, он посмотрел на настройки стека tcp, сравнив их с другим сервером, на котором работает Red Hat 5.6.

Короче говоря, включение файлов cookie tcp syn (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.

Я еще покопаюсь.