Вопросы Теги

Apache останавливается?/server-status шоу более чем 240 запросов как “ОПЦИИ * HTTP/1.0” 200 - “-” “Apache (внутреннее фиктивное соединение)”

Когда я сделал это, это был простой вопрос входа в Усовершенствованные Полномочия сайта, выбор Нового выпадающего, выбора Add User и введения имени пользователей в формате DOMAIN\username в поле и выборе полномочий дать им.

5
задан 5 June 2015 в 18:26
5 ответов

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

Это, кажется, вызывается FreeBSD ошибка UFS. Мы используем Тюрьмы FreeBSD на Хосте FreeBSD с файловой системой UFS по умолчанию. Файловая система UFS является большой - 1.8 ТБ.

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

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

0
ответ дан 3 December 2019 в 01:16

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

Если Вы видите их, это означает, что апач просто проверяет дочерние элементы, и безотносительно вызванного апача для разветвления этого, многих процессов, вероятно, не стало. Да они действительно занимаются соединениями клиента, но, независимо от того, что событие вызвало вещи буферизовать, вероятно, не стал.

Первой вещью я зарегистрировался бы в Ваших журналах, будет набор 302 с до события.

Если у Вас было что-то как 

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

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

ErrorDocument 404 /404.php

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

5
ответ дан 3 December 2019 в 01:16
  • 1
    Громоподобное стадо может объяснить наши проблемы. К сожалению, I' m, не видя скачок в запросах в то время. Однако, возможно, кто-то хлопает плохо кодированной страницей. Почему Вы ожидали бы видеть набор 302 с до события? –  Stefan Lasiewski 16 April 2010 в 02:18
  • 2
    302 с были бы знаком рекурсивных 404 (и я вижу, что редактор заменил пустым местом мой код, I' ll переиздают), который заставил бы апача расти без реального увеличения соединений от внешнего мира. –   16 April 2010 в 04:29
  • 3
    Я отредактировал свое сообщение для включения другого важного примечания. У нас было другое отключение электричества вчера вечером. It' s 8 часов спустя, и/server-status все еще показывает эти строки. –  Stefan Lasiewski 16 April 2010 в 20:02

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

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

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

2
ответ дан 3 December 2019 в 01:16

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

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

1
ответ дан 3 December 2019 в 01:16
  • 1
    На этом хосте нет никакого сервера прокси или Lighttpd. Существуют Аппаратные средства Loadbalancer, но это - отдельная часть аппаратных средств с it' s владеют IP. Эти соединения прибывают из ' 127.0.0.2' который является хостом localhost для этой тюрьмы. –  Stefan Lasiewski 20 April 2010 в 20:41

Необходимо найти, какие процессы подключены к порту 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.

Удачи!

Yves

1
ответ дан 3 December 2019 в 01:16
  • 1
    Кроме того, Вам не может так посчастливилось видеть живые соединения, если они являются недолгими. В этом случае существуют другие опции: 1) выполните tcpdump для наблюдения, когда соединения открыты, затем найдите PID клиентского процесса с помощью процесса выше. Снова, Вы не можете делать это достаточно быстро. 2) Добавьте, что брандмауэр постановляет, что доступ журналов к тому определенному порту на localhost и печатает PID обработки вызовов (dunno, если это легко сделать в системе FreeBSD), –  Yves Junqueira 20 April 2010 в 02:42

Теги

Похожие вопросы