LINUX.ORG.RU

Apache не освобождает память


0

0

Здравствуйте, прошу помочь разобратся с такой проблемой. Поставил сервак под проект и решил потестить использование памяти и как оказалось видимо не зря . Кароче стоит apache2 + mysql + django (в виде mod_python). Так вот захожу на тестовую страницу апача (та которая It works) все нормально загрузка памяти 50Мб потом захожу в директорию с тестовой страницей джанго. Далее происходит следующее, порождается процесс апач, потребление вырастает до 58, далее обновляю страницу и порождается еще один и потребление вырастает еще на 8 метров и так порождается 4 процесса, которые продолжают висеть. В итоге после того как открыл страничку с одного компа и обновил ее 4 раза потребление памяти вырастает до 100 и выше метров. Помогите понять почему апач не высвобождает память, или может он высвободит ее потом или как, и вообще когда должен завершится открытый процесс апача???

Рекомендую попробовать wsgi и обратить внимание на количество тредов/процессов/выделенной памяти на тред-процесс.

AlexKiriukha ★★★★
()

mod_python очень даже мёртв. Попробуй mod_wsgi, а вообще для джанги надо использовать fastCGI или даже SCGI, например с lighttpd.

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

>Почему? Чем плох WSGI?

Как-бы это разные вещи:)

WSGI - это питоновский стандарт. Приложение, умеющее wsgi может работать как fastcgi-приложение. А может работать через mod_wsgi у апача, или как обычное CGI.

А вообще конкретно fastcgi имеет преимущество - возможность разделения прав, когда само приложение запускается под другим юзером, а вебсервер только статику отдаёт, а все запросы на динамику уже переадресует приложению. В этом случае вебсервер может быть очень простой и лёгкий, а значит быстрый (lighttpd, nginx), и безопасность повыше.

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

> А вообще конкретно fastcgi имеет преимущество - возможность разделения прав, когда само приложение запускается под другим юзером, а вебсервер только статику отдаёт, а все запросы на динамику уже переадресует приложению.

WSGI это тоже может. Просто мы используем везде именно wsgi, но lighttpd его не поддерживает (хотел попробовать перейти на него). Поэтому интересно было бы посмотреть на сравнение wsgi и fastcgi.

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

>Поэтому интересно было бы посмотреть на сравнение wsgi и fastcgi.

Уважаемый, вы таки под словом WSGI понимаете mod_wsgi? WSGI это вообще не сервер и не приложение, это стандарт.

Апач слаб на статике, даже mpm_worker (хотя он и не так ужасен как prefork). В случае fastcgi глубоко пофигу, апач запускает или nginx. А значит смысла в толстом апаче нет - для статики он неудобен. Потому и берут обычно nginx или лайти.

Вот хорошая ссылка кстати:

http://nichol.as/benchmark-of-python-web-servers

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

> Уважаемый, вы таки под словом WSGI понимаете mod_wsgi? WSGI это вообще не сервер и не приложение, это стандарт.

Да, я в курсе. Используем именно mod_wsgi, не думал, что так много реализаций. За ссылку огромное спасибо.

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