«Срывается» загрузка страницы

Question

[dima_horror]

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

Есть сервер (Ubuntu 13.04, 3.8.0-29-generic), на нем стоит Apache/2.2.22 и PHP 5.4.9-4ubuntu2.3.

При переходе по страницам, каждая 10я (иногда чаще) «срывается».
Под «срывается» я имею введу что загружается только часть страницы. При этом браузер дальше показывает полосу загрузки страницы. Но ничего не происходит.

Если перезагрузить страницу — то все нормально.

Т.е. это проявляется с некоторой периодичностью на совершенно разных страницах, совершенно разных сайтах (виртуальных хостах апача).

Ранее такой проблемы не было. Что стало причиной появления — сказать трудно (если бы знал, не задавал бы вопрос).

Проблема явно не в файлах PHP, а в настройке самого апача.

Спасибо.

UPD 1:
В срочном порядке дважды перезапустил Apache и mysql, и пока все работает без сбоев.
Я так полагаю проблема связана с каким то буфером, или хранилищем, которое очищается при перезагрузке апача.

Тогда такой вопрос, возможно необходимы регламентные перезагрузки апача? Допустим в 4:00?

UPD 2:
В логах никаких ошибок и предупреждений нет.

UPD 3:
Ресурсов, в принципе, хватает.
Долго пытался заставить выплыть опять эту ошибку. Помог ab, сделал параллельно 300 запросов, сервер и скрючился…

Результаты по главной странице:

**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 54088 "-" "ApacheBench/2.3"
.... 52 раза одно и тоже.....
**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 54088 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 54088 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
.... 174 раза одно и тоже.....
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"

Как видно, размер уменьшился с 54088 до 8688 байт.

UPD 4:
3 раза провел тест. Апач перестает корректно отвечать (сбрасывает все последующие запросы) при ~34 запросах одновременно (Нагрузка на процессоры 100%). И приходит в себя через 2-5 секунд.

Но это немного не то. Т.к. в худшем случае на сервер (с его посещаемостью) в среднем одновременно 1 — максимум 3 запроса.

Пока выход вижу один — перезагружать апач хотя бы раз в день…

Comments

[rozhik]

В error_log что-то есть?

[dima_horror]

Ни ошибок, ни предупреждений нет.

Answer 1

[Александр Борисович]

Можете в момент срыва открыть фаер баг и посмотреть какие файлы браузер ожидает бесконечно? Каждый раз новые?
Ошибок в php нет? Похоже что с инетом что-то, типа yota когда пакеты теряются часто.

Comments

[dima_horror]

Даже код страницы грузится не до конца. Страницы всегда разные. Ошибок в логах нет. Да, очень похоже на то, что часть пакетов теряется. Как бороться?

UPD:
Хотя все таки грехи не на провайдере.
При частом возникновении таких «срывов» перезагрузка apache помогает. Срывы случаются реже.

[Александр Борисович]

Одна служба поддержки рекомендовала сделать пинг сервера и параллельно тестировать сайт. Если в момент падения в браузере пинг тоже заикнулся — проблема в сервере.
Вы описываете только свой опыт? Другие не ругаются?

[dima_horror]

Другие тоже ругаются. Проблема на стороне сервера.

Проверить пинг вместе с падением сайта уже не могу (Причина в UPD текста вопроса).

[dima_horror]

Проверил, пинг идет во время «срыва» загрузки.

[Александр Борисович]

А вот другие? Это какое количество человек, друг друга они не знают, интернет у них разный?

[dima_horror]

Человек 5, все в разных точках страны, у всех интернет разный. Проблема в сервере…

Answer 2

[1x1]

Большие статичные файлы отдаются нормально?
Ресурсов хватает? Исправление перезагрузкой апача смахивает на утечки памяти.
В access.log при частичной загрузке размер полный или частичный показывается?

Comments

[dima_horror]

С большими файлами пока не могу попробовать…
Ресурсов, в принципе, хватает.
Долго пытался заставить выплыть опять эту ошибку. Помог ab, сделал параллельно 300 запросов, сервер и скрючился…

Результаты по главной странице:

**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 54088 "-" "ApacheBench/2.3"
.... 52 раза одно и тоже.....
**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 54088 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 54088 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:22 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
.... 174 раза одно и тоже.....
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"
**.**.**.** - - [30/Oct/2013:14:19:23 +0200] "GET / HTTP/1.0" 200 8688 "-" "ApacheBench/2.3"

Как видно, размер уменьшился с 54088 до 8688 байт.
Что это может означать? Утечки памяти?

[1x1]

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

[dima_horror]

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

Answer 3

[Николай Васильчук]

Запустите jmeter или, хотя бы ab, чтобы руками не мучиться.
Запустите пинг сервера.
Дальше уже смотрите логи — системы, апача.

Comments

[dima_horror]

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

1000 последовательных запросов сервер нормально отработал. Но, когда я попытался параллельно отправить 300 запросов, ab мне ответил

apr_socket_recv: Connection reset by peer (104) Total of 47 requests completed

В UPD 3 я привел пример логов, когда страница «сбрасывается».
Что может быть причиной такого поведения?

[Николай Васильчук]

Теперь ставьте mod_status и смотрите что происходит с апачем в то время, когда он тупит.

[dima_horror]

Установил.
Честно говоря, смотрю в книгу — вижу фигу. За какими именно показателями следить?

3 раза провел тест. Апач перестает корректно отвечать (сбрасывает все последующие запросы) при ~34 запросах одновременно (Нагрузка на процессоры 100%). И приходит в себя через 2-5 секунд.

Но это немного не то. Т.к. в худшем случае на сервер (с его посещаемостью) в среднем одновременно 1 — максимум 3 запроса.

Пока выход вижу один — перезагружать апач хотя бы раз в день…

[Николай Васильчук]

Перезагрузка не выход.
Смотрите на количество процессов апача и их статус, возможно упираетесь в MaxClients, возможно в MaxRequestsPerChild.
Можно попробовать установить KeepAlive в off.

[dima_horror]

Спасибо… Попробуем так:
MaxClients увеличил со 150 до 300.
MaxRequestsPerChild установил значение 1000 (было 0)

[Николай Васильчук]

Если это поможет — значит где-то течет память, дальше копать в код и используемые модули апача.

[dima_horror]

Вроде KeepAlive в off помог. Но судить рано, необходимо что бы пару дней поработало (обычно проблемы начинаются начинаются на 6-8 день после перезагрузки апача).

[Николай Васильчук]

Попинайте его ab. Тут от времени ничего не зависит. Если проблема в буфере, то он забьется быстро под нагрузкой.

[dima_horror]

Попинал… Собственно к никаким выводам это не привело. При 100% загрузке апач начинает себя некорректно вести. Но на данном этапе это ничего страшного, т.к. обычно нагрузка на процессор не выше 1-5%.

Вопрос был в том, что даже без нагрузки он с некоторой периодичностью «урезал» страницу.
С такими параметрами:
MaxClients 300
MaxRequestsPerChild 1000
KeepAlive off

мне теперь вручную привести сервер в нерабочее состояние практически невозможно. (ранее на каждой 10й странице было «сбрасывание»).

Будем надеяться вопрос исчерпан

Answer 4

[demimurych]

запустите не просто пинг сервера. А пинг с размером пакета равным мту вашего сервера.
Часто случаются проблемы с мту на каком нибудь из хопов.
И просто пинг в 32 байта проходит отлично, а вот уже пинги больших размеров пропадают.

Comments

[dima_horror]

Пробовал изменить размер пакета, как ни странно для меня, пакеты, с размером выше 1470 вообще отказываются идти.(100% потерь).
ping **.**.**.** -s 1470

[demimurych]

ради опыта уменьшите на серверном интерфейсе мту до безобразно малого значения. например 1000
и посмотрите не пропадут ли проблемы

Answer 5

[96467840]

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

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

Comments

[dima_horror]

У меня есть подозрения на этот участок кода:

$filename = '../wp-content/uploads/'. $filename;
if (file_exists($filename)) {
     $f=fopen($filename, 'r');
     while(!feof($f)) {
          echo fread($f, 1024);
          flush();
     }
     fclose($f);
} else {
    header($_SERVER["SERVER_PROTOCOL"] . ' 404 Not Found');
    header('Status: 404 Not Found');
    echo $filename. ' NOT FOUND 404';
}

Возможно ли что проблема здесь?

[Николай Васильчук]

Ну вообще это говнокод. Файлы так не надо отдавать.
И да, здесь может быть проблема, но она не будет связана с буфером )

[dima_horror]

Я урезал большую часть кода ( в том числе после условий, внутри цикла и т.п.), что бы отобразить только процесс вывода.
Но это уже не относится к сути данного вопроса :)

[96467840]

flush не есть полная замена ob_flush

flush() may not be able to override the buffering scheme of your web server and it has no effect on any client-side buffering in the browser. It also doesn't affect PHP's userspace output buffering mechanism. This means you will have to call both ob_flush()

[dima_horror]

Не силен в PHP (я — .netовец).
Спасибо за наводку, добавил вконец ob_flush(). Хуже не станет :)

А так, ряд мер для устранения проблемы приняли, подействуют они или нет, время покажет…

Answer 6

[ValdikSS]

clamp-mss-to-pmtu? Уж очень схожие симптомы. Ну или просто MTU на интерфейсе (клиента) уменьшите.

Comments

[dima_horror]

Не уверен, что проблема на сетевом уровне, тем более что туда никто и не лез. Подчеркну, что ранее все нормально работало.

Answer 7

[Masterme]

а ошибки точно в лог пишутся? error_reporting какой? и в тот ли лог? а то пых может писать как в свой лог, так и в лог апача
сделайте фейл какой-нибудь, например, деление на ноль, и проверьте, отобразится ли это в логе

Comments

[dima_horror]

Ошибки точно в лог пишутся. И они, по данному вопросу, отсутствуют. (в смысле там появляются другие ошибки, например 404е)

[Masterme]

значит OOM либо фатал апача. вариант я вижу только один — максимально локализовать сбой, то есть выяснить при каких действиях и каких скриптах он происходит, после этого либо проставлять принты после каждой десятой строки либо подключить xdebug и выполнить трейс.

скорее всего валится какое-нибудь экзотическое расширение, зависящее от окружения

[Masterme]

ещё вы можете не видеть ошибки при включенном в php ob_get_content + gzip-сжатии (в самом php же). то есть текст ошибки попадает в буфер, но из-за фатала буфер сбрасывается и не выводится

Answer 8

[96467840]

кстати иногда помогает убить не используемые модули апача (особенно те что связаны с прокси) у меня на продакшен сервере бывали из-за них проблемы, но симптомы были не те (подозреваю кто то пытался через них конектиться и в статистике сети висело очень много левых процессов, сразу говорю в администрировании не силен и потому просто убил в апаче все что связано с прокси — мне помогло).