LINUX.ORG.RU

Определить, что текёт в апаче


0

2

Здравствуйте. Небольшая проблема с апачем на впс. Где-то текёт память в апаче 2.2. После старта апача за 4 часа 512 метров памяти «сьедается» им. При том, что всего 12 виртуалхостов и суммарная посещаемость врядли привысит 2к в день. Почти все сайты джумловские, некоторые очень тяжелые. Грешу на эту чертову джумлу.

Спустя полтора часа работы апача

#ps aux | grep httpd
root      9231  0.0  0.1   6024   600 pts/3    S+   09:59   0:00 grep httpd
apache    9542  1.5 13.7 371820 72160 ?        S    09:01   0:55 /usr/sbin/httpd
apache    9930  1.9 15.0 377944 78760 ?        S    09:01   1:06 /usr/sbin/httpd
apache   14025  1.5 13.4 370024 70628 ?        S    09:14   0:40 /usr/sbin/httpd
apache   17737  1.5 15.2 380276 79732 ?        S    09:04   0:52 /usr/sbin/httpd
root     30003  0.0  2.4 301496 13096 ?        Ss   08:04   0:00 /usr/sbin/httpd

Если посмотреть pmap, то там все как обычно:

17737:   /usr/sbin/httpd
00002aef5e000000    308K r-x--  /usr/sbin/httpd
00002aef5e04d000      4K r----  /usr/lib/locale/ru_RU.utf8/LC_TIME
00002aef5e04e000   1024K rw---    [ anon ]
00002aef5e24d000     16K rw---  /usr/sbin/httpd
00002aef5e251000     12K rw---    [ anon ]
00002aef5e254000    112K r-x--  /lib64/ld-2.5.so
00002aef5e270000      4K rw---    [ anon ]
00002aef5e280000   1028K rw---    [ anon ]
00002aef5e46f000      4K r----  /lib64/ld-2.5.so
00002aef5e470000      4K rw---  /lib64/ld-2.5.so
00002aef5e471000    520K r-x--  /lib64/libm-2.5.so
00002aef5e4f3000   2044K -----  /lib64/libm-2.5.so

<-- ПРОПУЩЕНО -->
00002aef7041c000      4K rw---  /usr/lib64/libexslt.so.0.8.13
00002aef7041d000    208K r-x--  /usr/lib64/libxslt.so.1.1.17
00002aef70451000   2044K -----  /usr/lib64/libxslt.so.1.1.17
00002aef70650000      8K rw---  /usr/lib64/libxslt.so.1.1.17
00002aef70652000     68K r-x--  /usr/lib64/php/modules/zip.so
00002aef70663000   2044K -----  /usr/lib64/php/modules/zip.so
00002aef70862000      8K rw---  /usr/lib64/php/modules/zip.so
00002aef708bd000   1024K rw---    [ anon ]
00002aef709bd000     20K rw-s-    [ anon ]
00002aef709c2000    444K r-x--  /usr/lib64/libgcrypt.so.11.5.2
00002aef70a31000   2044K -----  /usr/lib64/libgcrypt.so.11.5.2
00002aef70c30000     16K rw---  /usr/lib64/libgcrypt.so.11.5.2
00002aef70c34000     12K r-x--  /usr/lib64/libgpg-error.so.0.3.0
00002aef70c37000   2044K -----  /usr/lib64/libgpg-error.so.0.3.0
00002aef70e36000      4K rw---  /usr/lib64/libgpg-error.so.0.3.0
00002aef70e37000  10240K rw---    [ anon ]
00002aef718b8000   9216K rw---    [ anon ]
00002aef721b8000      4K r-x--  /usr/lib64/gconv/ISO8859-1.so
00002aef721b9000   2048K -----  /usr/lib64/gconv/ISO8859-1.so
00002aef723b9000      8K rw---  /usr/lib64/gconv/ISO8859-1.so
00002aef723bb000  14600K rw---    [ anon ]
00002aef7320c000     16K r-x--  /lib64/libnss_dns-2.5.so
00002aef73210000   2044K -----  /lib64/libnss_dns-2.5.so
00002aef7340f000      4K r----  /lib64/libnss_dns-2.5.so
00002aef73410000      4K rw---  /lib64/libnss_dns-2.5.so
00002aef73411000  57392K rw---    [ anon ]    <<<<<--------- Здесь
00002aef75895000      4K r----  /usr/lib/locale/en_US/LC_NUMERIC
00007fff1e443000    176K rw---    [ stack ]
ffffffffff600000   8192K -----    [ anon ]

вот эта цифра «00002aef73411000 67392K rw--- [ anon ]» беспокоит. Именно она растет. Копал в сети, говорят, мол, дело в скриптах - вечная рекурсия, течь памяти и т.п. Так видимо и есть, с учетом соразмерности этих джумло-сайтов.. В итоге, 4 часа работы память вся забита не понять чем. До сих пор лечу это рестартом апача кроном...

Вопрос такой. Есть дело в скриптах корявых, то как найти в каких именно, где «слабое звено»? Спасибо за ваши подсказки.

в похапэ есть профайлер им и ищи %) нудно, хардкорно...

ключевые слова - phpdbg, xdebug и иже с ними.

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

baverman дело говорит - откажись от mod_apache. Геморроя c fastcgi возможно тоже словишь, но зато локализовать текучесть проще

Pinkbyte ★★★★★ ()

Сами пхп скрипты не текут, даже если в них специально косячить с памятью (они ведь с нуля на каждый запрос отрабатывают, ну нечему там течь)

Течет либо сам апач либо какой-нибудь его модуль. Обнови софт.

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

Ну так я и думаю, что текет php_module. Все модули выделяют память из под пула апача, так что выяснить «кто конкретно» ее выделяет и по какой причине - задача номер 1. Я думал, что это eaccelerator. Когда выключил его, течь памяти так и осталось. Народ в сети, говорю же, отписывался. Скрипты херово отрабатывался (мэйлер какой-нибудь встремный), мусор в httpd навсегда оставался.. Народ говорил, что нашли косяки в скриптах, поправили и все хорошо. Из pmap видно:

00002aef73411000  57392K rw---    [ anon ]  
Кто кушает 57 метров? Как узнать.. А джумлу ковырять.. Тем более с кучей установленных там Commynity Builder и прочих тяжелых компонентов под нее.. Это как иголку в стоге сена.

Народ, дело то не в переустановке/обновление/смене конфигурации, а в определении причины косяка. В лог еррор ошибок особо нет, только надписи о рестарте апача в основном.

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

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

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

Вот именно, что префорк стоит, а MaxRequestsPerChild вообще в 10 ставил, но по какой-то причине потребление памяти это не убрало (хотя рутовый httpd не много ест).

dblokhin ()
Ответ на: комментарий от Komintern

Ребят, да грешу я на это чертову джумлу. Чую =). Там есть порталы, с кучей говнокомпонентов... Там среди прочего видать где-то скрипты плохо отрабатывают.

dblokhin ()
Ответ на: комментарий от redixin

ну нечему там течь)

Ололо, ну ты отжег. Интерпретатор php на сишечьке написан, да еще и кривыми руками. А так конечно, течь там нечему.

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

у меня апач с mpm-itk+xcache+mod_php кушал мозги со скоростью пару гигов в день, и на сервере с 16 гигами рамы через недели полторы начинал забиваться своп. оказалось что это баги работы xcache с mpm-itk на freebsd. еще очень часто грешит неадекватным мозгоедством Zend Optimizer.

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

> Интерпретатор php на сишечьке написан

Пост перечитай, да?

Сами пхп скрипты не текут

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

Причем тут сишечка?

Течет либо сам апач либо какой-нибудь его модуль.

Намекну что mod_php тоже относится к «какой-нибудь его модуль»

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

Постой, ты серьезно не знаешь как оставить подвешенную ссылку в пхп, которая потом никак не соберется? Да ты пороху то и не нюхал вообще.

Каждый раз выполняется заново

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

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

> ты серьезно не знаешь как оставить подвешенную ссылку в пхп, которая потом никак не соберется?

Нет, не знаю, но интересно. Продемонстрируй пжлст.

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

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

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

dblokhin ()
Ответ на: комментарий от baverman

А ничё что это немного не то о чем мы говорим? После завершения скрипта в mpd_php никаких мемликов не будет.

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

Поставил апач, mod_php, попытался сделать лик. Сдаюсь. С момента первого релиза 5.3 разрабы подчистили детские баги и сейчас gc сносно работает на примитивных тестовых кейзах. То есть, при аккуртном использовании unset, можно вполне жить.

baverman ★★★ ()

Нашел в чем проблема. Уже когда все перепробывал, подумал, что бага все таки в модуле... Версия php 5.2.17 вроде была, на 64х разрядной системе (ЦентОС) он сам по себе тёк. Решение простое - обновить пхп на новую версию, и убедится, что все сайты работают нормально.

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