Только если у вас так же есть закон о не раскрытии источников.
Не стоит автоматически переносить американские нормы на другие страны. Так можно и очень неприятно попасться.
Хотя ваши предположения не верны(т.е. я так не считаю и я не настолько ленюсь), хочу сказать спасибо — потому что своим первым вопросом натолкнули меня на правильное понимание проблемы.
По поводу ребута раз в полчаса — это очень сильное преувеличение. Весь мир довольно долгое время жил на апаче и никто не ребутил сервера раз в пол часа. На данный момент проблем с памятью в данной конфигурации не наблюдается. Хотя нагрузки впрочем тоже.
Если я не учел какого-то фактора — прошу указать на него. Но на данный момент я не понимаю куда может утечь память.
Насчет подключения swap — учту и поправлю.
Насчет необходимости nginx — критика справедливая и правильная. Он необходим. Собственно пониманию проблемы помог комментарий masterbo, за что ему отдельная благодарность. Я как-то считал что на не нагруженных конфигурациях вполне нормально и без него. В секции описания установки nginx сделаю теоретическое отступление.
В который раз уже убеждаюсь — не надо смешивать продакшен и тестовые сайты.
Правильно — отладка ведется на одном сайте, потом изменения коммитятся на рабочий. Тогда таких «огрызков тестовых данных» в открытом доступе не останется.
Предпочитаю разумный минимализм. eaccelerator довольно хорошо работает, есть в репозитории epel для Centos6 и работает «из коробки».
В случае необходимости — можно подключить еще CentALT (http://centos.alt.ru) там есть довольно много интересного включая apc, xcache и свежий nginx.
Если нет — данные тестирования имеются в конце статьи.
Если нужны другие данные — с удовольствием их предоставлю, только попрошу описать условия тестирования. Или сами можете развернуть аналогичную систему и протестировать. Все описанное выше делается в течении 30 минут копипастом из статьи в ssh клиент.
Боюсь это уже перерастает в холивар.
Я не говорил что не хочу пользоваться Nginx. Так же я не говорил, что я им не умею пользоваться или даже, что я им не пользуюсь. :-)
Просто я считаю, что для данной задачи nginx — излишество которое потом потребует больше времени на поддержку и адаптацию. Повторяю — именно в рассматриваемом случае. Если мы ждем существенную нагрузку — тогда либо ставим nginx фронтэндом (что довольно легко вписывается в данную концепцию), либо делаем все с нуля на nginx php-fpm. Но это уже будут решения другого уровня.
На этом я тему обсуждения «почему тут нет nginx» заканчиваю.
Есть цели и есть инструменты. Одни инструменты лучше подходят под одни цели другие под другие. Тема nginx vs apache — весьма обширна и холиварна. Не спорю что у Nginx есть объективные преимущества, но не стоит забывать и о некоторых недостатках. В рассмотренном мной ключе (не получить дополнительных проблем в последствии) основным недостатком является то что разработчики разного рода CMS и т.п. дают в документации рекомендации именно по работе с апачем. Не стоит так же забывать, что решения «из коробки» опять таки обычно комплектуются под apache.
Соответственно в данном контексте установка Nginx ведет к повышению производительности (что не является в данном контексте основной целью) и увеличению времени затрачиваемого на поддержку и поиск решений того как портировать какой-либо конфиг с апача на nginx.
В данном случае ситуация в чем-то сродни скачиванию последних версий софта «make && make install». Да, мы получаем самые свежие версии софта с новыми фитчами, но в последствии берем на себя всю дальнейшую работу по обновлению. Здесь же ставя Nginx мы получаем более быстрый сервер, но получаем дополнительную работу по адаптации конфигов.
php-eaccelerator в данном случае не столько средство снижения нагрузки, а еще и средство увеличения юзабилити.
На данный момент на VPS принято ограничивать CPU. И на дешевых тарифах при тех же 400-500Mhz разница в скорости генерации странички, например друпалом, с php-eaccelerator и без него весьма ощутимая. Т.е. сайт с акселератором шевелится ощутимо лучше.
Это Centos. т.е. почти RHEL у которго несколько специфичным подход к устранению уязвимостей.
Если кратко — устранение уязвимости не означает перехода на другую версию, а наличие обновленного PHP 5.3.2 не означает наличие дырок которые были и до 5.3.8 и будут после. Поэтому стоит регулярно делать «yum update» а остальную работу сделают за вас в RedHat.
Если рассматривать в ключе данной статьи, то по моему мнению ngnix стоит ставить уже на следующем уровне развития проекта, по достижению определенной нагрузки на имеющиеся решение. И ставить в качестве фронтенда, а не на замену апачу. Будет более красивое решение с большей совместимостью. Если же мы сразу ожидаем большую нагрузку, тогда да, действительно стоит применить другой подход. Но ведь нагрузки может и не быть.
Если бы как Microsoft то потребляли бы 1000 литров на 100км.
Не стоит автоматически переносить американские нормы на другие страны. Так можно и очень неприятно попасться.
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 сделаю теоретическое отступление.
Правильно — отладка ведется на одном сайте, потом изменения коммитятся на рабочий. Тогда таких «огрызков тестовых данных» в открытом доступе не останется.
Фронтендом.
[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
+ немного настройки.
чуть позже (ориентировочно завтра) допишу апдейт к посту.
В случае необходимости — можно подключить еще CentALT (http://centos.alt.ru) там есть довольно много интересного включая apc, xcache и свежий nginx.
Если нет — данные тестирования имеются в конце статьи.
Если нужны другие данные — с удовольствием их предоставлю, только попрошу описать условия тестирования. Или сами можете развернуть аналогичную систему и протестировать. Все описанное выше делается в течении 30 минут копипастом из статьи в ssh клиент.
Я не говорил что не хочу пользоваться Nginx. Так же я не говорил, что я им не умею пользоваться или даже, что я им не пользуюсь. :-)
Просто я считаю, что для данной задачи nginx — излишество которое потом потребует больше времени на поддержку и адаптацию. Повторяю — именно в рассматриваемом случае. Если мы ждем существенную нагрузку — тогда либо ставим nginx фронтэндом (что довольно легко вписывается в данную концепцию), либо делаем все с нуля на nginx php-fpm. Но это уже будут решения другого уровня.
На этом я тему обсуждения «почему тут нет nginx» заканчиваю.
Соответственно в данном контексте установка Nginx ведет к повышению производительности (что не является в данном контексте основной целью) и увеличению времени затрачиваемого на поддержку и поиск решений того как портировать какой-либо конфиг с апача на nginx.
В данном случае ситуация в чем-то сродни скачиванию последних версий софта «make && make install». Да, мы получаем самые свежие версии софта с новыми фитчами, но в последствии берем на себя всю дальнейшую работу по обновлению. Здесь же ставя Nginx мы получаем более быстрый сервер, но получаем дополнительную работу по адаптации конфигов.
На данный момент на VPS принято ограничивать CPU. И на дешевых тарифах при тех же 400-500Mhz разница в скорости генерации странички, например друпалом, с php-eaccelerator и без него весьма ощутимая. Т.е. сайт с акселератором шевелится ощутимо лучше.
Особенно с учетом того что в статье такого не говорится.
На мой взгляд перенос на другой домен — ничуть не хуже перекладывания в другую директорию.
Если кратко — устранение уязвимости не означает перехода на другую версию, а наличие обновленного PHP 5.3.2 не означает наличие дырок которые были и до 5.3.8 и будут после. Поэтому стоит регулярно делать «yum update» а остальную работу сделают за вас в RedHat.