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

Apache завис? / server-status показывает более 240 запросов, таких как «ОПЦИИ * HTTP / 1.0» 200 - «-» «Apache (внутреннее фиктивное соединение)»

Некоторые детали:

Я включил mod_status с «ExtendedStatus On». Когда я просматриваю / server-status, я вижу несколько регулярных запросов. Я также вижу более 240 таких запросов от «localhost». 

37-0    -   0/0/1   .   0.00    1510    0   0.0 0.00    0.00    127.0.0.2   www.example.gov OPTIONS * HTTP/1.0
38-0    -   0/0/1   .   0.00    1509    0   0.0 0.00    0.00    127.0.0.2   www.example.gov OPTIONS * HTTP/1.0
39-0    -   0/0/3   .   0.00    1482    0   0.0 0.00    0.00    127.0.0.2   www.example.gov OPTIONS * HTTP/1.0
40-0    -   0/0/6   .   0.00    1445    0   0.0 0.00    0.00    127.0.0.2   www.example.gov OPTIONS * HTTP/1.0

Я также вижу вчера около 2417 запросов с локального хоста, например:

Apr 14 11:16:40 192.168.16.127 httpd[431]: www.example.gov 127.0.0.2 - - [15/Apr/2010:11:16:40 -0700] "OPTIONS * HTTP/1.0" 200 - "-" "Apache (internal dummy connection)"

Страница по адресу http://wiki.apache.org/httpd/InternalDummyConnection говорит: «Эти запросы совершенно нормальны, и вам, как правило, не нужно о них беспокоиться», но я не уверен.

Почему их более 230? Это активные связи? Если у меня есть «MaxClients 256» и более 230 из этих подключений, кажется, что мой веб-сервер находится в опасной близости от того, чтобы исчерпать доступные подключения. Также кажется, что Apache нужно всего лишь несколько этих «внутренних фиктивных соединений».

Прошлой ночью у нас было два необъяснимых сбоя, и мне интересно, не привело ли это «внутреннее фиктивное соединение» к тому, что у нас закончились доступные соединения.

ОБНОВЛЕНИЕ 2010/04/16

Спустя 8 часов. Страница / server-status все еще показывает, что есть 243 строки, в которых написано «www.example.gov OPTION *». Я считаю, что эти связи неактивны. Сервер в основном простаивает (1 запрос в настоящее время обрабатывается, 9 простаивают). На хосте Unix всего 18 активных процессов httpd.

Если эти соединения неактивны, почему они отображаются в / server-status? Я ожидал, что срок их действия истечет через несколько минут после инициализации.

Apache обращается с громовым стадом немного иначе, чем вы можете себе представить. Когда вы получаете всплеск входящего трафика, он порождает несколько дочерних процессов, если он определяет, что ему нужно больше, он порождает в два раза больше в следующем интервале, пока, наконец, у него не будет достаточно процессов для обслуживания запросов или совпадений с maxclients.

Если вы видите это, это означает, что apache просто проверяет дочерние элементы, и что бы ни вызвало форк apache, многие процессы, вероятно, ушли. Да, они принимают клиентские соединения, но какое бы событие ни вызвало сбои, вероятно, уже нет.

Первое, что я бы проверил в ваших журналах, - это 302 секунды до мероприятия.

Если бы у вас было что-то вроде 

<?php include("http://www.oursite.com/header.php");?>

где header.php отсутствовал и

ErrorDocument 404 /404.php

где 404.php включает header.php, вы получите рекурсивный цикл, и попадание на эту страницу немедленно заставит apache использовать все доступные соединения.

Я понимаю, что, учитывая, что это связи от родительского к дочернему процессу, они просто Apache, отслеживающий, что делают потомки. Имейте в виду, что:

  • после обработки запроса дети могут оставаться там довольно долго.
  • внутренние фиктивные соединения происходят регулярно
  • если дочерний элемент ничего не сделал (потому что сервер в основном простаивает), фиктивное соединение будет самым последним обработанным им.

Насколько я знаю, фиктивные связи не «истощают» детей. Apache проверяет статус своих потомков, а не тренирует их, чтобы проверить, работают они или нет.

Вам нужно найти, какие процессы подключены к вашему порту Apache (я предполагаю, что это 80).

У меня нет системы FreeBSD, поэтому я могу подтвердить команды, но, по крайней мере, на Mac это должно дать вам подсказку:

$ lsof -i

Будет показано что-то вроде:

COMMAND     PID  USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
BadGuy    26655 yvesj   24u  IPv4 0x3f32270      0t0  TCP localhost:56696->localhost:56695 (ESTABLISHED)
GoodGuy 26656 yvesj   15u  IPv4 0x5b7666c      0t0  TCP localhost:56695 (LISTEN)
GoodGuy 26656 yvesj   16u  IPv4 0x72a9e64      0t0  TCP localhost:56695->localhost:56696 (ESTABLISHED)

Из этого вы можете заметить, что процесс с PID 26656 слушая на порт 56695 и процесс 26655 соединение в этот порт. Таким образом вы сможете определить, кто является плохим парнем (только не путайте с третьей строкой, которая показывает обратную сторону соединения (goodguy => badguy).

Когда вы примените это к своему случаю, вы обнаружите, какие другие процессы в вашей системе поддерживают эти соединения с вашим экземпляром Apache.

Удачи!

Ив

Если память не используется, это тестовые соединения, генерируемые легковесными прокси (такими как Lighttpd), которые устанавливаются перед более тяжелыми серверами, такими как Apache.

Учитывая, что вы находитесь в тюрьме, возможно, хост-сервер проксирует запросы на (частный) IP-адрес тюрьмы через lighttpd?

Что ж, это был неожиданный ответ. Это было вызвано проблемой файловой системы, когда мы делали снимки файловой системы UFS в полночь.

Похоже, это вызвано ошибкой FreeBSD UFS. Мы используем FreeBSD Jails на хосте FreeBSD с файловой системой UFS по умолчанию. Файловая система UFS большая - 1,8 ТБ.

Раз за ночь мы запускаем резервную копию с помощью dump (8). dump (8) создавал моментальный снимок файловой системы перед ее резервным копированием, и это заморозило файловую систему. Дамп должен работать с файловыми системами менее 2 ТБ, но в нашем случае это не удалось. У этого парня была такая же проблема.

(Я переместил свой ответ из раздела вопросов сюда в раздел ответов. Stefan, 20100608)