LINUX.ORG.RU
ФорумAdmin

Периодически засыпающий Apache 2.4

 , , , ,


0

2

Господа, выручайте. Третий день не сплю, не ем - не могу никак найти причину странного (не побоюсь этого слова) поведения Apache. Началось всё довольно стандартно: необходимо было перенести среднего размера сайт на пару новых виртуалок под Xen'ом (два узла, нагрузка распределяется Netscaler'ом, база на третьей). В качестве ОСы используется не сильно любимая мною Ubuntu 14.04 (я больше по RHEL'ам уношусь), но и с ней я до этого находил язык. Что касаемо веб-серверов, то и здесь всё довольно привычно - nginx в качестве фронтенда, apache 2.4 - бэкенда, PHP 5.5.9 как mod_php у апача (ну и prefork, соответственно).

Для начала - о среде «песочницы». Код сайта лежит на shared-разделе, форматированном в ocfs2 со следующими параметрами (это может быть важно): mkfs.ocfs2 /dev/sdb1 -N 2 -b 4K -C 4K -T mail --fs-features=discontig-bg --fs-feature-level=max-features

В качестве фреймворка сайта используется Yii. Для кеша используется memcached, а также встроенный в PHP OpCache. Среди модулей PHP нет каких-либо необычных, собранных из сорцов или установленных через pear.

Конфиг апача (более чем стандартный, но все приведенные ниже параметры я пробовал менять):

<IfModule mpm_prefork_module>
        StartServers                     1
        MinSpareServers           1
        MaxSpareServers          2
        MaxRequestWorkers         10
        MaxConnectionsPerChild   0
</IfModule>
<VirtualHost *:8080>
    RPAFenable On
    RPAFsethostname On
    RPAFproxy_ips 127.0.0.1
    RPAFheader X-Real-IP
    ServerName site.com
    ServerAlias www.site.com
    CustomLog /var/log/apache2/access.log combined
    ErrorLog /var/log/apache2/error.log
    AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
    AddType application/x-httpd-php-source .phps
    DocumentRoot /srv/www/site
    <Directory "/srv/www/site">
        Options -Indexes +FollowSymLinks +Includes -MultiViews
        AllowOverride all
        Require all granted
    </Directory>
    DirectoryIndex /index.html /index.php /index.cgi
</VirtualHost>

Так вот. Проблема в том, что периодически Апач перестаёт отвечать на вопросы и просто чего-то ждёт. Ждёт секунд 30, может минуту, бывает - полторы, а потом всё начинает работает и отдаваться браузеру за 1-2 секунды (причём страницы есть достаточно тяжёлые).

Сначала я думал, что проблема в кэше и эта задержка как-то связана с медленной скоростью чтения с ocfs2-раздела (задержка очень часто проявлялась после рестарта Апача и мне казалось, что нужно какое-то время, чтобы контент закешировался, после чего уже будет отдаваться мгновенно). Но несколько раз после рестарта апача, задержек не было - значит, дело не в кеше. Разумеется я пробовал отключать и Memcached, и OpCache, и даже ставил apcu - всегда результат был одинаковым.

Было предположение, что виной всему база (чаще всего проблемы в ней). Так нет же! Я проверял одновременно на двух, идентично настроенных узлах и один может работать и отдавать контент, в то время как на втором в этот же самый момент апач чего-то ждёт. Значит, дело не в базе.

Думаю, так может дело в PHP - тоже нет. В момент ожидания чего-то апачем, простые файлы вроде test.php с phpinfo(); или html в той же директории сайта отдаются мгновенно. Получается, апач ждёт чего-то именно от приложения, но как понять чего?

Прибегнул к помощи любимого strace: strace -o trace.txt -f -s4096 -r -t -p 21319 (в качестве pid'а взят, разумеется, мастер-процесс). Но ничего познавательного в моменты ожиданий я так и не нашёл.

21319      0.000000 select(0, NULL, NULL, NULL, {0, 854712}) = 0 (Timeout)
21319      0.855951 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000104 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001253 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000082 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001259 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000084 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001249 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000082 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001267 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000082 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001265 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000085 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001258 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000082 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001263 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000084 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001272 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000088 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001322 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000086 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001897 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000099 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001250 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000082 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001261 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000084 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001259 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000085 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
21319      1.001269 wait4(-1, 0x7ffff35f8f64, WNOHANG|WSTOPPED, NULL) = 0
21319      0.000083 select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)

Просто, спустя какое-то время, когда Апач перестаёт ждать, в strace уже можно видеть, как читаются htaccess'ы, другие файлы и всё работает якобы нормально. В логах, разумеется, пусто - никаких ошибок или даже ворнингов. lsof каких-то необычных файлов не показывает - ну да, модули всякие, да логи. Глазу зацепиться не за что. Думал, может проблема в htaccess'е - у него много правил для ресайза изображений на лету, но тогда почему всё это периодически возникает, а не постоянно.

Честное слово: я проделывал всё это (перенос/ установку/ настройку) множество раз и никогда подобных проблем не возникало.

Я правда в тупике и уже не знаю в какую сторону ковырять. Перегуглил всё что можно, прочитал все эти суперчитабельные mail-листинги, да вообще всё что можно.

Надеюсь на вашу помощь и любые советы в диагностике. Я понимаю, что причина где-то есть - я просто не знаю как её найти. Мои методы иссякли.

Заранее премного благодарен.


Ответ на: комментарий от goingUp

Примерно следующее. Посты 111222 и 222111 - это две вкладки, которые я открыл. 208 - мой ай-пи.

Server Version: Apache/2.4.7 (Ubuntu) PHP/5.5.9-1ubuntu4.9
Server MPM: prefork
Server Built: Mar 10 2015 13:05:59

Current Time: Tuesday, 09-Jun-2015 21:28:29 ALMT
Restart Time: Tuesday, 09-Jun-2015 21:19:54 ALMT
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 8 minutes 35 seconds
Server load: 0.00 0.02 0.05
Total accesses: 47 - Total Traffic: 210 kB
CPU Usage: u.46 s.08 cu0 cs0 - .105% CPU load
.0913 requests/sec - 417 B/second - 4575 B/request
5 requests currently being processed, 1 idle workers

WW_.WWW...

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

Srv	PID	Acc	M	CPU 	SS	Req	Conn	Child	Slot	Client	VHost	Request
0-0	24827	0/4/4	W 	0.04	21	0	0.0	0.01	0.01 	192.168.88.208	site.com:8080	GET /ru/news/post/111222/ HTTP/1.0
1-0	24832	0/11/11	W 	0.43	49	0	0.0	0.10	0.10 	192.168.88.208	site.com:8080	GET /ru/news/post/222111/ HTTP/1.0
2-0	25166	0/9/18	_ 	0.01	1	1	0.0	0.02	0.08 	192.168.88.208	site.com:8080	NULL
3-0	-	0/0/2	. 	0.03	49	0	0.0	0.00	0.00 	127.0.0.1	site.com:8080	OPTIONS * HTTP/1.0
4-0	25131	0/2/2	W 	0.00	55	0	0.0	0.01	0.01 	192.168.88.208	site.com:8080	GET /ru/ HTTP/1.0
5-0	25132	0/0/0	W 	0.00	54	0	0.0	0.00	0.00 	192.168.88.208	site.com:8080	GET /ru/media/menu_top/preload.png HTTP/1.0
6-0	25133	1/6/6	W 	0.00	0	0	2.1	0.01	0.01 	192.168.88.208	site.com:8080	GET /server-status HTTP/1.1
7-0	-	0/0/2	. 	0.03	52	0	0.0	0.00	0.00 	127.0.0.1	site.com:8080	OPTIONS * HTTP/1.0
8-0	-	0/0/2	. 	0.00	50	0	0.0	0.00	0.00 	127.0.0.1	site.com:8080	OPTIONS * HTTP/1.0
Korben
() автор топика

PHP обычно блокирует сессию, поэтому если у тебя сессия на сайте, остальные страницы не будут открываться, пока не подгрузится первая. По-моему нет никаких причин считать, что с апачем что-то не то, скорее всего дело в приложении. По идее в strace, который ты показал, все нормально, он просто ждет, пока приложение ему ответит.

goingUp ★★★★★
()

простые файлы вроде test.php с phpinfo(); или html в той же директории сайта отдаются мгновенно

Ну дык если еще и БД не подозревать, то остается только приложение. Видимо, что-то синхронно выполняющееся, что обычно не требует временных затрат, внезапно начинает тупить. Может, какая-то сетевая активность: подключение к какому-нибудь smtp, разрешение имени, запрос к внешнему веб-сервису..?

thesis ★★★★★
()
Ответ на: комментарий от goingUp

Да я собственно и не спорю. Я и сам вижу, что апач чего-то ждёт. Я просто хочу понять чего и ликвидировать эту причину.

Если это PHP, то как понять почему, зачем и где он блокирует сессию? А также почему это происходит не постоянно, а периодически.

Korben
() автор топика
Ответ на: комментарий от Korben

почему, зачем и где он блокирует сессию?

Ты открываешь страницу, стартуется сессия. Пока не закончится генерация страницы, сессия заблокирована. Это чтобы параллельно выполняющиеся скрипты не перезаписывали сессию неправильно.

goingUp ★★★★★
()
Ответ на: комментарий от thesis

Никаких задач из крона я ещё не переносил, кроме меня к хосту никто не обращается, т.е. нагрузки никакой. Резолв или подключение... ну, возможно, но почему тогда при обращении к одному и тому же коду с разных узлов, это не происходит синхронно?

И как я могу узнать где приложение затыкается?

Korben
() автор топика
Ответ на: комментарий от Korben

Да я так, пальцем в небо. Попытка угадать природу паузы, когда затык есть, а пожирания ресурсов не видно. Фиг знает, нужно, видимо, цепляться стрейсом к приложению и смотреть действия перед началом паузы.

thesis ★★★★★
()
Ответ на: комментарий от Korben

К бегущему пхп. Вообще я бы сменил запуск на fcgid, например, и посмотрел, исчезнет баг или нет. Он часто проявляется вообще?

thesis ★★★★★
()
Ответ на: комментарий от thesis

К сожалению, постоянно. Из-за этого я не могу запустить сайт в продакшн. FastCGI, это, конечно, вариант (хотя бы для проверки), но не уверен, что это поможет.

Korben
() автор топика
Ответ на: комментарий от Korben

не уверен, что это поможет.

Ну трассировщиком к нему подцепиться тогда и ждать начала затыка.

thesis ★★★★★
()
Ответ на: комментарий от Korben

FastCGI, это, конечно, вариант (хотя бы для проверки), но не уверен, что это поможет.

По крайней мере его дебажить будет проще чем монстрообразный апач.

iron ★★★★★
()

всё сообщение прочитать я не осилил :-)

..но хочу во что казать!

Конфиг апача (более чем стандартный, но все приведенные ниже параметры я пробовал менять):

Апач версии 2.4 поумолчанию использует НЕ «prefork» а «event»

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

Да, но к сожалению, я не могу пока отказаться от htaccess'ов - там до меня такого наворотили, что вот так взяться и переписать все эти адские правила я не возьмусь. Я как-то думал, что привести в чувство апач и пхп будет проще, чем переписать все регулярки.

Korben
() автор топика
Ответ на: комментарий от thesis

ясно!

теперь понял!

спасиб!

а — mod_fcgid — в этой теме уже советовали?

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

Не советовали, но что-то я с ним ни разу дела не имел и не особо хочется. Если уж и отказываться от mod_php, то, на мой взгляд, ради nginx + php5_fpm, а не mod_fcgid. Я считаю, что будь у него хоть какой-то выигрыш и преимущества, на него бы все перешли.

А mod_php не так уж и плох на самом деле. Они сравнимы с php-fpm, как мне кажется. По крайней мере, я хлебал говна и с тем, и с другим и там, где один заводился с коловорота и работал через кое-что, другой вёл себя стабильно и быстро. В общем, дело не в этом.

А в том, что же такое может на пустом месте мешать работать приложению! Очень не хочется дебажить чужой код. Очень. Может есть какие-то ещё средства?

Korben
() автор топика
Ответ на: комментарий от iron

Поставил php5-fpm, вот какой strace

20913      0.000000 clock_gettime(CLOCK_MONOTONIC, {245282, 916284725}) = 0
20913      0.000174 clock_gettime(CLOCK_MONOTONIC, {245282, 916394952}) = 0
20913      0.000080 clock_gettime(CLOCK_MONOTONIC, {245282, 916473130}) = 0
20913      0.000070 epoll_wait(8, {}, 101, 910) = 0
20913      0.911168 clock_gettime(CLOCK_MONOTONIC, {245283, 827713493}) = 0
20913      0.000074 clock_gettime(CLOCK_MONOTONIC, {245283, 827784258}) = 0
20913      0.000062 clock_gettime(CLOCK_MONOTONIC, {245283, 827845919}) = 0
20913      0.000069 getsockopt(7, SOL_TCP, TCP_INFO, "\n\0\0\0\0\0\0\0@B\17\0\0\0\0\0\30\2\0\0\0\0\0\0\0\0\0\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\24(\232\16\0\0\0\0\24(\232\16\24(\232\16\0\0\0\0\0\0\0\0\0\0\0\0\220\320\3\0\377\377\377\177\n\0\0\0\0\0\0\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", [104]) = 0
20913      0.000104 clock_gettime(CLOCK_MONOTONIC, {245283, 828020172}) = 0
20913      0.000130 epoll_wait(8, {}, 101, 1000) = 0

Только с php-fpm через какое-то время выдаётся ошибка 504 (в отличие от апача, который через время всё-таки начинал отдавать контент), но это, скорее всего, потому что я таймауты не настраивал.

Korben
() автор топика

Вопрос идиотский, но - в момент когда всё тупит - попробуй считать что-нибудь большое с OCFS2.

Очень похоже на какой-то трудноуловимый факап в кластерной ФС. Я с Ceph подобное ловил, знаю что сравнение некорректное, но всё же...

Pinkbyte ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.