Comments 61
Вместо Апача стоит поставить Энженикс или Лайти…
Если рассматривать в ключе данной статьи, то по моему мнению ngnix стоит ставить уже на следующем уровне развития проекта, по достижению определенной нагрузки на имеющиеся решение. И ставить в качестве фронтенда, а не на замену апачу. Будет более красивое решение с большей совместимостью. Если же мы сразу ожидаем большую нагрузку, тогда да, действительно стоит применить другой подход. Но ведь нагрузки может и не быть.
Тогда зачем вы поставили php-eaccelerator? :)
php-eaccelerator в данном случае не столько средство снижения нагрузки, а еще и средство увеличения юзабилити.
На данный момент на VPS принято ограничивать CPU. И на дешевых тарифах при тех же 400-500Mhz разница в скорости генерации странички, например друпалом, с php-eaccelerator и без него весьма ощутимая. Т.е. сайт с акселератором шевелится ощутимо лучше.
На данный момент на VPS принято ограничивать CPU. И на дешевых тарифах при тех же 400-500Mhz разница в скорости генерации странички, например друпалом, с php-eaccelerator и без него весьма ощутимая. Т.е. сайт с акселератором шевелится ощутимо лучше.
У вас, судя по конфигурации, апач работает в prefork режиме. Не слишком-то это эффективно для eaccelerator, мне кажется. Не хотите переключить Apache в worker режим? В CentOS для этого нужно отредактировать файл
/etc/sysconfig/httpd и поставить там HTTPD=/usr/sbin/httpd.worker
php.net/manual/en/install.unix.apache2.php
We do not recommend using a threaded MPM in production with Apache 2. Use the prefork MPM, which is the default MPM with Apache 2.0 and 2.2. For information on why, read the related FAQ entry on using Apache2 with a threaded MPM
We do not recommend using a threaded MPM in production with Apache 2. Use the prefork MPM, which is the default MPM with Apache 2.0 and 2.2. For information on why, read the related FAQ entry on using Apache2 with a threaded MPM
Верно говорят, nginx+php-fpm сразу надо осваивать. Скорость, низкое потребление ресурсов, кэши разных уровней, гибкость в настройках. Апач — это страшный сон.
А что, у Nginx есть какие-то недостатки, которые не позволяют его использовать на малопосещаемых сайтах?
А что, у Nginx есть какие то проблемы с работой без Apache, но с php-fpm? насколько я знаю — наоборот. Хотя бы возможность запуска каждого сайта из под отдельного юзера.
А что, у Nginx есть какие то проблемы с работой без Apache, но с php-fpm? насколько я знаю — наоборот. Хотя бы возможность запуска каждого сайта из под отдельного юзера.
Есть цели и есть инструменты. Одни инструменты лучше подходят под одни цели другие под другие. Тема nginx vs apache — весьма обширна и холиварна. Не спорю что у Nginx есть объективные преимущества, но не стоит забывать и о некоторых недостатках. В рассмотренном мной ключе (не получить дополнительных проблем в последствии) основным недостатком является то что разработчики разного рода CMS и т.п. дают в документации рекомендации именно по работе с апачем. Не стоит так же забывать, что решения «из коробки» опять таки обычно комплектуются под apache.
Соответственно в данном контексте установка Nginx ведет к повышению производительности (что не является в данном контексте основной целью) и увеличению времени затрачиваемого на поддержку и поиск решений того как портировать какой-либо конфиг с апача на nginx.
В данном случае ситуация в чем-то сродни скачиванию последних версий софта «make && make install». Да, мы получаем самые свежие версии софта с новыми фитчами, но в последствии берем на себя всю дальнейшую работу по обновлению. Здесь же ставя Nginx мы получаем более быстрый сервер, но получаем дополнительную работу по адаптации конфигов.
Соответственно в данном контексте установка Nginx ведет к повышению производительности (что не является в данном контексте основной целью) и увеличению времени затрачиваемого на поддержку и поиск решений того как портировать какой-либо конфиг с апача на nginx.
В данном случае ситуация в чем-то сродни скачиванию последних версий софта «make && make install». Да, мы получаем самые свежие версии софта с новыми фитчами, но в последствии берем на себя всю дальнейшую работу по обновлению. Здесь же ставя Nginx мы получаем более быстрый сервер, но получаем дополнительную работу по адаптации конфигов.
Для тех кто не хочет напрягаться есть куча shared-хостингов.
Если вы не хотите пользоваться Nginx из-за того, что нужно осваивать новое — то я вам сочувствую. Конфиги там гораздо проще чем у Apache, есть даже конвертер из .htaccess www.anilcetin.com/convert-apache-htaccess-to-nginx/
Выставлять на сервер один Apache НЕЛЬЗЯ. Учить этому новичков тем более.
Если вы его так обожаете — все равно нужно спереди поставить Nginx.
Хотя бы вот, почему:
habrahabr.ru/blogs/infosecurity/127029/
habrahabr.ru/blogs/infosecurity/127199/
Если вы не хотите пользоваться Nginx из-за того, что нужно осваивать новое — то я вам сочувствую. Конфиги там гораздо проще чем у Apache, есть даже конвертер из .htaccess www.anilcetin.com/convert-apache-htaccess-to-nginx/
Выставлять на сервер один Apache НЕЛЬЗЯ. Учить этому новичков тем более.
Если вы его так обожаете — все равно нужно спереди поставить Nginx.
Хотя бы вот, почему:
habrahabr.ru/blogs/infosecurity/127029/
habrahabr.ru/blogs/infosecurity/127199/
Боюсь это уже перерастает в холивар.
Я не говорил что не хочу пользоваться Nginx. Так же я не говорил, что я им не умею пользоваться или даже, что я им не пользуюсь. :-)
Просто я считаю, что для данной задачи nginx — излишество которое потом потребует больше времени на поддержку и адаптацию. Повторяю — именно в рассматриваемом случае. Если мы ждем существенную нагрузку — тогда либо ставим nginx фронтэндом (что довольно легко вписывается в данную концепцию), либо делаем все с нуля на nginx php-fpm. Но это уже будут решения другого уровня.
На этом я тему обсуждения «почему тут нет nginx» заканчиваю.
Я не говорил что не хочу пользоваться Nginx. Так же я не говорил, что я им не умею пользоваться или даже, что я им не пользуюсь. :-)
Просто я считаю, что для данной задачи nginx — излишество которое потом потребует больше времени на поддержку и адаптацию. Повторяю — именно в рассматриваемом случае. Если мы ждем существенную нагрузку — тогда либо ставим nginx фронтэндом (что довольно легко вписывается в данную концепцию), либо делаем все с нуля на nginx php-fpm. Но это уже будут решения другого уровня.
На этом я тему обсуждения «почему тут нет nginx» заканчиваю.
Окей. Покажите, пожалуйста, скриншот htop вашей vps.
Желательно при нагрузке, и без. Мне не верится, что вам хватает 256 памяти, на 64 битной системе с Apache. А спорить да, больше не будем.
Желательно при нагрузке, и без. Мне не верится, что вам хватает 256 памяти, на 64 битной системе с Apache. А спорить да, больше не будем.
top или htop имеет принципиальную разницу?
Если нет — данные тестирования имеются в конце статьи.
Если нужны другие данные — с удовольствием их предоставлю, только попрошу описать условия тестирования. Или сами можете развернуть аналогичную систему и протестировать. Все описанное выше делается в течении 30 минут копипастом из статьи в ssh клиент.
Если нет — данные тестирования имеются в конце статьи.
Если нужны другие данные — с удовольствием их предоставлю, только попрошу описать условия тестирования. Или сами можете развернуть аналогичную систему и протестировать. Все описанное выше делается в течении 30 минут копипастом из статьи в ssh клиент.
htop наглядно показывает сколько кушается памяти, сколько лежит в свопе, загрузку проца и основных процессов.
А еще там видно uptime.
По моему, это очень важно, так как после старта и тестов у меня на виртуалке скушано 150 мб ОЗУ, а через неделю — уже под 350.
А еще там видно uptime.
По моему, это очень важно, так как после старта и тестов у меня на виртуалке скушано 150 мб ОЗУ, а через неделю — уже под 350.
Справедливости ради стоит заметить, что потребление памяти, как и своппинг, управляются настройками в sysctl.conf, так что расход ОЗУ на системе на большом промежутке времени ни о чём не говорит.
У меня лично VPS с 512Мб с lighttpd. Настроено так, что кэш забивает практически полностью всю свободную память (оставил резерв = 32Мб), учитывая то, что редких прожорливых php-скриптов у меня на сайтах нет.
p.s. сам подумывал статью написать про настройку голого vps, только не уверен надо ли. Вроде и так всё разжевано везде.
У меня лично VPS с 512Мб с lighttpd. Настроено так, что кэш забивает практически полностью всю свободную память (оставил резерв = 32Мб), учитывая то, что редких прожорливых php-скриптов у меня на сайтах нет.
p.s. сам подумывал статью написать про настройку голого vps, только не уверен надо ли. Вроде и так всё разжевано везде.
Откуда больше времени на адаптацию? Настроить nginx как reverse proxy это такое непостижимое занятие? Apache использует модель которая годится только для отдачи контента быстрым клиентам — nginx, локальные клиенты, сайт с 8 посещениями в час. Выставлять Apache на улицу с ТАКИМ-ТО объемом памяти имеет смысл только если никто кроме вас не будет им пользоваться.
> либо делаем все с нуля на nginx php-fpm.
Если вы используете cms которая не обновлялась уже несколько лет — да это проблема. Все остальное спокойно заводится под php-fpm, и не важно, apache + php-fpm или nginx + php-fpm.
> либо делаем все с нуля на nginx php-fpm.
Если вы используете cms которая не обновлялась уже несколько лет — да это проблема. Все остальное спокойно заводится под php-fpm, и не важно, apache + php-fpm или nginx + php-fpm.
Поправьте меня если я не прав:
1. Вы считаете, что Apache со своей армией потомков нормально без nginx может обслуживать медленные соединения и это не отразится на занимаемой памяти? Если так, то вы ошибаетесь. Nginx стоит поставить перед apache как минимум для того, чтобы процесс apache быстро отдал ответ nginx-у и освободил память для следующего запроса, а nginx уже разберется с медленным клиентом без затрат дорогого ресурса.
2. Вы не стали использовать nginx потому, что не нашли в репозиториях, а «make делает любой дистрибутив… и дальше по тексту»? Тогда это просто лень, чреватая проблемами именно в ситуации ограниченных ресурсов VDS
1. Вы считаете, что Apache со своей армией потомков нормально без nginx может обслуживать медленные соединения и это не отразится на занимаемой памяти? Если так, то вы ошибаетесь. Nginx стоит поставить перед apache как минимум для того, чтобы процесс apache быстро отдал ответ nginx-у и освободил память для следующего запроса, а nginx уже разберется с медленным клиентом без затрат дорогого ресурса.
2. Вы не стали использовать nginx потому, что не нашли в репозиториях, а «make делает любой дистрибутив… и дальше по тексту»? Тогда это просто лень, чреватая проблемами именно в ситуации ограниченных ресурсов VDS
Хотя ваши предположения не верны(т.е. я так не считаю и я не настолько ленюсь), хочу сказать спасибо — потому что своим первым вопросом натолкнули меня на правильное понимание проблемы.
Пожалуйста. А еще задумайтесь над тем, чтобы к своему apache (раз уж вы не собираетесь отходить от .htaccess) привязать один (по числу доступных ядер) постоянно висящий в памяти процесс php-fpm вместо модуля mod_php, который дублируется в памяти с каждым запросом. вы так тоже много сэкономите и по памяти и по производительности.
>Хотя бы возможность запуска каждого сайта из под отдельного юзера.
Не холивара ради, но: www.suphp.org/Home.html
Не холивара ради, но: www.suphp.org/Home.html
Про бэкап БД, сделать можно чуть красивее.
Листаем список всех БД, и бэкапим каждую в отдельный файл.
#!/bin/bash
USER="root"
PASSWORD="myRootPWD"
mkdir /var/backup/database/`date +%F`;
for DB in `mysql -u$USER -p$PASSWORD -N -e 'show databases' | awk '{print $1}'`; do
mysqldump --user=$USER --host=$HOST --password=$PASSWORD ${DB} | gzip > /var/backup/database/`date +%F`/${DB}.sql.gz;
echo "${DB} Backup";
done
Листаем список всех БД, и бэкапим каждую в отдельный файл.
Хотелось бы видеть еще пару строк по поводу настройки мыльного сервера, почту-то все же надо принимать/отправлять и почему-то в статьях про lamp все об этом забывают.
«php — PHP 5.3.2»
забываем про дырки в PHP до 5.3.8?
забываем про дырки в PHP до 5.3.8?
Это Centos. т.е. почти RHEL у которго несколько специфичным подход к устранению уязвимостей.
Если кратко — устранение уязвимости не означает перехода на другую версию, а наличие обновленного PHP 5.3.2 не означает наличие дырок которые были и до 5.3.8 и будут после. Поэтому стоит регулярно делать «yum update» а остальную работу сделают за вас в RedHat.
Если кратко — устранение уязвимости не означает перехода на другую версию, а наличие обновленного PHP 5.3.2 не означает наличие дырок которые были и до 5.3.8 и будут после. Поэтому стоит регулярно делать «yum update» а остальную работу сделают за вас в RedHat.
«После таких действий phpMyAdmin будет доступен по пути /phpMyAdmin/»
забываем про web ботов и дырки в phpMyAdmin'e
забываем про web ботов и дырки в phpMyAdmin'e
Чуть ниже «Теперь один нюанс ».
На мой взгляд перенос на другой домен — ничуть не хуже перекладывания в другую директорию.
На мой взгляд перенос на другой домен — ничуть не хуже перекладывания в другую директорию.
Боты не знают про другой домен. И имя его не угадают, и не узнают — если самому ссылок не давать в паблике.
А на phpmyadmin, PhpMyAdmin и подобные они долбятся постоянно.
По этой же причине админы отключают доступ root по ssh — ибо это известное имя, для которого можно подбирать пароль. А в других случаях нужно подобрать и логин и пароль.
А на phpmyadmin, PhpMyAdmin и подобные они долбятся постоянно.
По этой же причине админы отключают доступ root по ssh — ибо это известное имя, для которого можно подбирать пароль. А в других случаях нужно подобрать и логин и пароль.
Хорошо посещаемые сайты, 256 ОЗУ и Apache.
Мне одному кажется что-то странное в этой строке? Где nginx?
Мне одному кажется что-то странное в этой строке? Где nginx?
Centos-6 86_x64
на минимальных ресурсах VPSА вот тут-то Штирлиц и просчитался…
Use <code>, Luke!
Все таки настоятельно рекомендую сразу смотреть в сторону NGINX(без Apache) + php-fpm.
Аргумент что примеров для Apache больше чем для nginx очень слабый, а плюсы в будущем очевидны.
За примерами в крайнем случае можно сходить к ведору или комунити.
Аргумент что примеров для Apache больше чем для nginx очень слабый, а плюсы в будущем очевидны.
За примерами в крайнем случае можно сходить к ведору или комунити.
Посмотрите хотя бы как люди спасаются от нагрузки простым переходом с Apache + mod_php на nginx + php-fpm http://freehabr.ru/blog/freehabr/410.html
Вопрос.
Почему eaccelerator, а не APC или Xcache
Сайт eaccelerator уже давно не работает.
Я как то спрашивал у знатоков habrahabr.ru/qa/10728/
Почему eaccelerator, а не APC или Xcache
Сайт eaccelerator уже давно не работает.
Я как то спрашивал у знатоков habrahabr.ru/qa/10728/
eaccelerator теперь живет тут sourceforge.net/projects/eaccelerator/, и даже иногда обновляется, правда редко.
Лично у меня была проблема на MODX Revolution, когда я написал очень замороченный класс, в нем включил еще один и в одном методе то работало, то не работало. Пропарился несколько дней, пока допетрил, что ошибка не в коде, а в APC. Заменил его на eaccelerator — ошибок больше нет.
Наверняка я сам что-то намудрил, но вот такой случай у меня в практике был.
Лично у меня была проблема на MODX Revolution, когда я написал очень замороченный класс, в нем включил еще один и в одном методе то работало, то не работало. Пропарился несколько дней, пока допетрил, что ошибка не в коде, а в APC. Заменил его на eaccelerator — ошибок больше нет.
Наверняка я сам что-то намудрил, но вот такой случай у меня в практике был.
Не намудрили. Была такая точно такая же тема, при чем именно при включении классов друг в друга. При чем забавно, первый раз заливаешь, пока файл свежий, он 1-2 раза может даже выполниться (скорее 1), а потом сразу оппа и «белый экран» без признаков ошибок вообще. В следующих версиях это уже было поправлено, но осадочек остался.
Предпочитаю разумный минимализм. eaccelerator довольно хорошо работает, есть в репозитории epel для Centos6 и работает «из коробки».
В случае необходимости — можно подключить еще CentALT (http://centos.alt.ru) там есть довольно много интересного включая apc, xcache и свежий nginx.
В случае необходимости — можно подключить еще CentALT (http://centos.alt.ru) там есть довольно много интересного включая apc, xcache и свежий nginx.
А все-таки вы знаете где взять пакет со свежим nginx. Тогда отговорки больше не принимаются. :)
Уболтали. :-)
Фронтендом.
[root@test ~]# rpm -ihv centos.alt.ru/pub/repository/centos/6/x86_64/centalt-release-6-1.noarch.rpm
[root@test ~]# yum install mod_realip2 nginx-stable
+ немного настройки.
чуть позже (ориентировочно завтра) допишу апдейт к посту.
Фронтендом.
[root@test ~]# rpm -ihv centos.alt.ru/pub/repository/centos/6/x86_64/centalt-release-6-1.noarch.rpm
[root@test ~]# yum install mod_realip2 nginx-stable
+ немного настройки.
чуть позже (ориентировочно завтра) допишу апдейт к посту.
Еще один все понял [x]
Посмотрите в сторону BitrixEnv3 который можно развернуть на чистом CentOS 5/6 и получить настроенную систему.
BitrixEnv3
BitrixEnv3 Forum
BitrixEnv3
BitrixEnv3 Forum
Это такой тонкий юмор?
Нет :)
Продукт бесплатный, сразу устанавливает 2-х уровневую конфигурацию с nginx в качестве front-end и ZendServer (apache) в качестве back-end. Для кеширования есть возможность использовать memcached.
Есть консольное меню позволяющее выполнить ряд типовых операций, в том числе добавление нового сайта.
Использовать можно как для запуска Битрикс, так и для любых других проектов на php.
На мой взгляд намного проще использовать чем повторить все вышеописанное, да и результат точно будет не хуже.
Продукт бесплатный, сразу устанавливает 2-х уровневую конфигурацию с nginx в качестве front-end и ZendServer (apache) в качестве back-end. Для кеширования есть возможность использовать memcached.
Есть консольное меню позволяющее выполнить ряд типовых операций, в том числе добавление нового сайта.
Использовать можно как для запуска Битрикс, так и для любых других проектов на php.
На мой взгляд намного проще использовать чем повторить все вышеописанное, да и результат точно будет не хуже.
заменить гайд на lamp + nginx и ещё вместо чистого mysql поставить percona DB — будет замечательно.
файл подкачки корректнее активировать через fstab, а не дергать swapon
[(15:43):artem@28321-1:~ ] grep swap /etc/fstab
/swap swap swap defaults 0 0
поддерживаю
Плюсик, к сожалению, не могу поставить.
Плюсик, к сожалению, не могу поставить.
Первый раз то можно) Вдруг она еще долго не перезагрузится. Хотя, с такой конфигурацией надо по крону ребутить раз в полчаса))))
в первый раз можно
swapon -aПо поводу ребута раз в полчаса — это очень сильное преувеличение. Весь мир довольно долгое время жил на апаче и никто не ребутил сервера раз в пол часа. На данный момент проблем с памятью в данной конфигурации не наблюдается. Хотя нагрузки впрочем тоже.
Если я не учел какого-то фактора — прошу указать на него. Но на данный момент я не понимаю куда может утечь память.
Насчет подключения swap — учту и поправлю.
Насчет необходимости nginx — критика справедливая и правильная. Он необходим. Собственно пониманию проблемы помог комментарий masterbo, за что ему отдельная благодарность. Я как-то считал что на не нагруженных конфигурациях вполне нормально и без него. В секции описания установки nginx сделаю теоретическое отступление.
21:38:23 up 7 days, 3:16, 2 users, load average: 0.03, 0.03, 0.00
Mem: 244856k total, 207776k used, 37080k free, 17508k buffers
Swap: 262136k total, 22112k used, 240024k free, 76164k cached
Если я не учел какого-то фактора — прошу указать на него. Но на данный момент я не понимаю куда может утечь память.
Насчет подключения swap — учту и поправлю.
Насчет необходимости nginx — критика справедливая и правильная. Он необходим. Собственно пониманию проблемы помог комментарий masterbo, за что ему отдельная благодарность. Я как-то считал что на не нагруженных конфигурациях вполне нормально и без него. В секции описания установки nginx сделаю теоретическое отступление.
Ну кто вот минусует. и карму снизили. Первый раз то понятно, что свапоном подключаем, в дальнейшем имеется в виду не писать swapon в rc.local, а использовать идеологически правильный для этого fstab.
А почему не показали benchmark после установки и настройки nginx?
Sign up to leave a comment.
LAMP +Nginx на VPS стабильно и без лишней головной боли