В предыдущей части мы начали бороться за память на 256 мегабайтном слайсе «на скорую руку». Результат был, но не столь эффектный как тот которого я добился на этот раз.
Я всегда догадывался, что причина всех моих неприятностей — apache. И чем больше я пытался его настраивать, тем больше в этом убеждался. Вывод? Попробовать заменить. Одно но — переход должен быть как можно более плавным, поскольку речь, ясно дело, о продакшене.
Поскольку у меня был опыт общения с nginx, а если быть точным — опыт с проксированием, то был выбран именно этот веб-сервер. К тому же у него хорошие параметры производительности.
Первое что я попытался сделать — собрать nginx с mod_wsgi (не путать с тем же для apache). Собрать-то получилось, а вот заставить работать — нет. Постоянно валялся с ошибкой «невозможно испортировать как модуль...». Но не суть важна, уйти от этого хода стало так же причиной некоторое затухание проекта mod_wsgi… Хотя и то что я выбрал нельзя назвать активно развивающимся и стабильным :)
После долгих копаний и мУченья постояльцев конференции pythonua@conference.jabber.ru, был брошен взор на fapws3. Если коротко, то это веб-сервер, написанный на питоне. Теоретически, его можно использовать просто так, без nginx, но я пока не нашёл способа создания виртуальных хостов по доменам, да и со статикой nginx обращается куда лучше.
Итак, у меня на слайсе archlinux, соответственно всё что ниже справедливо именно для него. pacman — менеджер софта, можете использовать свои apt-get etc. по выбору, разве что названия пакетов могут отличаться.
В установке fapws3 нет ничего сложного. Качаем tarball, разархивируем, выполняем
именно на ней основан fapws.
В архиве вы найдёте папочку examples, а в ней django. Берём run.py и кидаем в свой проект. Лучше сразу же проверить работоспособность запустив его
Тут скорее всего вылезит эксепшн, мол DJANGO_SETTINGS_MODULE не определён… Но это решается просто добавлением
Так же нужно менять порты. Т.е. для каждого сайта свой порт. Я начал нумерацию с 8081 и так далее. Далее это потребуется при настройки nginx. К слову сказать порт настраивается в
Тут тоже ничего сложного:
Всё что требуется от nginx — проксировать динамические запросы на fapws сервера, а статику раздавать самому. Для этого делаем для каждого сайта блок server внутри http в /etc/nginx/conf/nginx.conf:
Здесь важна строчка proxy_pass, в ней нужно указать порт из run.py. В каких местах настроена статика, думаю ясно, не будем вдаваться в подробности, просто исправьте пути на свои.
Поскольку fapws3 для каждого сайта — отдельный демон, нужно как-то управлять всем этим зверьём. Для этого я взял supervisord. Это что-то вроде rc.d, только написано на питоне и куда адекватней… В плане лично мне лень писать rc для каждого сайта, а потом ещё добавлять в rc.conf. С супервизорд нам требуется лишь добавить сам его в rc.d и настроить сайты в его конфигурации (очень просто). Ставится он немного сложней, через aur, но возможно в вашем дистрибутиве он есть как поддерживаемый пакет. Хотя с моим yaourt всё сводится к команде
В rc.conf добавляется так:
Конфигурация очень проста, по виду как win-ini. Для меня было достаточно добавить такой блок:
command — сама команда, не забудьте только сделать run.py исполняемым
process_name — имя процесса
user — от какого пользователя будет запускаться (тот же что и веб-сервер, а nginx у меня под http а не стандартным nginx, поскольку всё заточено именно под http, т.к. апач)
Ну вот и всё. Разумеется такое нужно для каждого сайта. Лично я ещё раскомментировал секцию [inet_http_server], что даёт веб-интерфейс, но лично у меня он криво работает… Только информационную функцию выполняет, перезапустить процесс не получается, только через supervisorctl, и то с эксепшенами (видимо в них дело, но разбираться было лень).
Итого у нас освободилось более 100Мб памяти, сейчас картина выглядит так
После перезагрузки swap должен уйти в mem, но пока не заморочился — пусть uptime тикает :)
В общем и сложном мы получили огромную экономию памяти и увеличение скорости вообще. Субъективно, страницы стали загружаться раз в 5 быстрее, тестером не мерил, меня устраивает :)
Удачи!
Via Retta Inc.
P.S> Плюсики в карму не помешают — всегда есть хорошие люди которым нужен инвайт :)
Я всегда догадывался, что причина всех моих неприятностей — apache. И чем больше я пытался его настраивать, тем больше в этом убеждался. Вывод? Попробовать заменить. Одно но — переход должен быть как можно более плавным, поскольку речь, ясно дело, о продакшене.
Поскольку у меня был опыт общения с nginx, а если быть точным — опыт с проксированием, то был выбран именно этот веб-сервер. К тому же у него хорошие параметры производительности.
Первое что я попытался сделать — собрать nginx с mod_wsgi (не путать с тем же для apache). Собрать-то получилось, а вот заставить работать — нет. Постоянно валялся с ошибкой «невозможно испортировать как модуль...». Но не суть важна, уйти от этого хода стало так же причиной некоторое затухание проекта mod_wsgi… Хотя и то что я выбрал нельзя назвать активно развивающимся и стабильным :)
После долгих копаний и мУченья постояльцев конференции pythonua@conference.jabber.ru, был брошен взор на fapws3. Если коротко, то это веб-сервер, написанный на питоне. Теоретически, его можно использовать просто так, без nginx, но я пока не нашёл способа создания виртуальных хостов по доменам, да и со статикой nginx обращается куда лучше.
Итак, у меня на слайсе archlinux, соответственно всё что ниже справедливо именно для него. pacman — менеджер софта, можете использовать свои apt-get etc. по выбору, разве что названия пакетов могут отличаться.
fapws3
В установке fapws3 нет ничего сложного. Качаем tarball, разархивируем, выполняем
python setup.py install
. Предварительно не забываем установить libev pacman -S libev
именно на ней основан fapws.
В архиве вы найдёте папочку examples, а в ней django. Берём run.py и кидаем в свой проект. Лучше сразу же проверить работоспособность запустив его
python run.py
.Тут скорее всего вылезит эксепшн, мол DJANGO_SETTINGS_MODULE не определён… Но это решается просто добавлением
os.environ['DJANGO_SETTINGS_MODULE'] = 'kaexpert.settings'
в run.py (разумеется заменяем на свой модуль).Так же нужно менять порты. Т.е. для каждого сайта свой порт. Я начал нумерацию с 8081 и так далее. Далее это потребуется при настройки nginx. К слову сказать порт настраивается в
evwsgi.start("127.0.0.1", 8081)
(для тестирования можно использовать IP 0.0.0.0, чтобы можно было проверить работоспособность без nginx, в нашем же случае кроме nginx напрямую к сайту никто не обратится… это правильней)nginx
Тут тоже ничего сложного:
pacman -S nginx
. Далее настройки. Поскольку мне требовалась бесперебойная работа сервера, nginx я поставил на порт 8080, для этого находим в /etc/nginx/conf/nginx.conf строчку listen 80
и меняем 80 на 8080.Всё что требуется от nginx — проксировать динамические запросы на fapws сервера, а статику раздавать самому. Для этого делаем для каждого сайта блок server внутри http в /etc/nginx/conf/nginx.conf:
server { listen 80; server_name promex.su; location /static { root /srv/http/promex.su/; } location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov) { access_log off; expires 30d; root /srv/http/promex.su/; } location /media { root /usr/lib/python2.6/site-packages/django/contrib/admin/; } location / { proxy_pass http://127.0.0.1:8082; proxy_set_header X-Forwarded-Host $server_name; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
Здесь важна строчка proxy_pass, в ней нужно указать порт из run.py. В каких местах настроена статика, думаю ясно, не будем вдаваться в подробности, просто исправьте пути на свои.
supervisord
Поскольку fapws3 для каждого сайта — отдельный демон, нужно как-то управлять всем этим зверьём. Для этого я взял supervisord. Это что-то вроде rc.d, только написано на питоне и куда адекватней… В плане лично мне лень писать rc для каждого сайта, а потом ещё добавлять в rc.conf. С супервизорд нам требуется лишь добавить сам его в rc.d и настроить сайты в его конфигурации (очень просто). Ставится он немного сложней, через aur, но возможно в вашем дистрибутиве он есть как поддерживаемый пакет. Хотя с моим yaourt всё сводится к команде
yaourt -S supervisord
:) Советую всем arch юзерам воспользоваться.В rc.conf добавляется так:
DAEMONS=(syslog-ng network netfs crond sshd supervisord)
.Конфигурация очень проста, по виду как win-ini. Для меня было достаточно добавить такой блок:
[program:kaexpert] command=/srv/http/ka-expert.ru/src/run.py process_name=%(program_name)s user=http
command — сама команда, не забудьте только сделать run.py исполняемым
process_name — имя процесса
user — от какого пользователя будет запускаться (тот же что и веб-сервер, а nginx у меня под http а не стандартным nginx, поскольку всё заточено именно под http, т.к. апач)
Ну вот и всё. Разумеется такое нужно для каждого сайта. Лично я ещё раскомментировал секцию [inet_http_server], что даёт веб-интерфейс, но лично у меня он криво работает… Только информационную функцию выполняет, перезапустить процесс не получается, только через supervisorctl, и то с эксепшенами (видимо в них дело, но разбираться было лень).
Итог
Итого у нас освободилось более 100Мб памяти, сейчас картина выглядит так
total used free shared buffers cached Mem: 256 113 142 0 4 32 -/+ buffers/cache: 75 180 Swap: 511 27 484
После перезагрузки swap должен уйти в mem, но пока не заморочился — пусть uptime тикает :)
В общем и сложном мы получили огромную экономию памяти и увеличение скорости вообще. Субъективно, страницы стали загружаться раз в 5 быстрее, тестером не мерил, меня устраивает :)
Удачи!
Via Retta Inc.
P.S> Плюсики в карму не помешают — всегда есть хорошие люди которым нужен инвайт :)