Нормально ли уходит оперативная память на VPS?

да я разве спорю... Но этот VPS не отдаёт тонны статики (так говорят мои телепатические способности). Я не сторонник, когда ставят только потому, что "где-то слышали". Нет, на полном серьёзе подоплёка здесь только одна. Поэтому я здесь снёс бы мемкеш и nginx - памяти сразу стало бы больше. Ну и потом подкрутил апач, поставил бы нормальное max_clients, уменьшил бы размер стека (я еще с этим не задрал? :)), подкрутил мыскл... ну и запихал бы ОС в ~ 150 метров памяти.

Даже без статики, префорк будет держать процессы, пока посетитель не получит данные от web-сервера. В случае с nginx такого не будет и отдавать контент будет уже nginx с его 1-2 процессами.

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

Но всякие тюнинги типа memcached, кэши и буфферы mysql - глупо использовать, если память хочется экономить.

Тут либо уж память жалеть, либо производительность пытаться увеличить. Можно и в 100Mb ОСь запихать с web-сервером, а надо ли?

Хотя отключение innodb хорошо освободит памяти + тюнинг apache.

С этой экономией блин... хочется и быстро и дёшево... Что-то одно стоит выбирать.

Естественно nginx не универсальное лекарство от потребления, когда речь о слабом сервере без нагрузки.

Да кто вам такое сказал?! :). Ну да, если поставить буферов у джинкса поболее - ну будет толк, но не на одном (!) хосте в час. И, кроме того, префорк не прибивает процессы после того, как они запущены! На то он и prefork (предварительно создаёт форки процессов, чтобы не создавать их при запросе). Но для джинксовых буферов тоже нужна память (!). Кстати, перевод PHP в режим CGI в данном случае сделает то же самое, что делает Nginx (представьте, ведь когда пых отработает - апачу останется только раздать страничку, т.к. пых из памяти выгрузится после генерации). Зачем плодить ещё одну точку отказа?

Да и такую штуку, как выгрузка ненужных модулей... Знаете, тоже хорошо и память и процессор экономит.

Стрельба из пушки по воробьям, блин. Будто от Nginx он сэкономит больше 10 мегабайт... Пичаль... А то, что он сам по себе эти же 10 метров отожрет никто не задумывается.

---------- Добавлено 06.02.2012 в 10:24 ----------

Вот-вот. И я о том же, что одним Nginx сыт не будешь.

У меня есть средненагруженный форум vbulletin 4 на vps. Debian+apache+nginx+xcache. На nginx висит вся статика, остальное он проксирует апачу. Форк апача оптимизирован до 15-18мб, основная загрузка озу идет от mysql. Итого все занимат в пике 320мб озу.

Всё зависит от настроек.

Вот как раз "остаётся раздать страничку" и заставляет процесс висеть в спамяти. Одно - это лёгкий nginx, а другое - отдельный процесс apache с кучей модулей.

Я не спорю, что apache нельзя облегчить, но nginx - это самое простое "лекарство", поэтому им и пользуются. В том же ISPManager достаточно одного клика для установки.

Сэкономит и в разы больше при достаточной посещаемости. Потому как процессы apache будут висеть ровно столько, сколько потребуется для выполнения скрипта. В обычном случае прибавляется ещё и время на передачу контента посетителю.

Можете представить цифры при 30-50 одновременных подключениях к web-серверу.

Чем должен висит каждый процесс, тем больше их будет висеть одновременно. Думаю понятно, что количество одновременно висящих процессов влияет на потребление памяти.

Если умеете обходиться без nginx - ваше право. Но для рядового человека nginx действительно является самым простым решением.

Не всегда он даст эффект, но вариант самый простой, который можно опробовать. Чем разбираться в тюнинге apache, mysql и т.п.

Левые модули из апача убить. И остаётся лёгкий апач... Я серьёзно... Всякие mod_proxy и иже с ними вообще не нужны обычно. А самое жрущее - mod_php, который вынесен в CGI... У меня один воркер апача кушает 2 Мбайта памяти, правда там нифига не префорк. Если серьёзно - даже апач ставится перед апачем же (!) для достижения того же эффекта, что и с nginx (!). Вот таки дела... Просто далеко не везде эта прокся нужна.

А теперь переводим апач в режим Worker, ставим fcgi и получаем ту же картину, что и при nginx. Даже ещё выгоднее... ;). Зачем плодить еще один веб-сервер с отдельными конфигами, о которых надо помнить (!), о которых надо знать, а в случае с панелью возникают неописуемые фейлы время от времени благодаря разработчикам... ? Я даже больше хочу. Хотите на большую посещаемость и остаться с rewrite - ставьте lighttpd - вот это штука. Причём довольно большая преемственность инструкций и синтаксиса от апача (даже переписывать часто ничего не нужно).

Олег, самое простое - потому, что куча манов написана. А когда делают "по мануалу", не понимая истоков - получается не всегда то, что надо. И это, между прочим, очень распространённое явление. так, например, без должного конфига Nginx в качестве reverse-proxy просто не даёт никакого эффекта в большинстве случаев. В случае же перенаправления обработки статики на него - потребуются дополнительные "прыжки с бубном", а если еще и доменов черти-сколько - это уже превращается в весьма неприятную задачу (если домены периодически добавляются). Ну и опять же дополнительная софтина, которая может заглючить, которую нужно обновлять, у которой может оказаться неожиданное "непереваривание" другого софта и т.п. Оно надо? Боюсь, в продакшн далеко не каждому. Это хорошо, что люди, которые ставят что-то только потому, что "где-то что-то слышали" не занимаются серьёзными проектами, могущими причинить при простое вред жизни людей или еще чего. Вот в CERN к примеру, админы бы так ставили софт... Было бы весело :)..

60 запросов в секунду с более чем 300 сайтами - достаточная нагрузка, для объективности? Я не пожалею один из своих хостинговых серверов в продакшне, только для того, чтобы вы убедились в бесполезности nginx в самом простом случае.

Да. Писать конфиг для nginx и апача - довольно просто... А я думал, проще сконфигурировать только апач. да, на уровне "наш1л конфиг в интернете под другую систему, скопировал к себе и исправил пути" - просто. Но эффективность такого решения - нуль. Тем более, что разбираться потом, кто виноват и почему - с nginx сложнее. А ещё из-за этого оооочень часто возникают ошибки 502/504 (потому, что конфиг для большого сервака копируют к себе на ВПС или наоборот бездумно).

Т.е. "че тут думать, трясти надо", так чтоли?

Почти 6 лет с ним работаю - ни единой проблемы. А вот у apache достаточно было разных.

Просто нажать "включить" напротив nginx'а в ispmanager'е.

И что проще, прописать виртуалхост в nginx'е по мануалу или разбираться, какие вам модули нужны в apache или нет? Рядовой человек понятия не имеет, что там и для чего предназначено. Причём один модуль зависит от другого и если отключать по одному, то ещё нарвёшься на отключение нужных модулей или вообще web-сервер не запустится, т.к. другой модуль требует отключённый.

Тоже самое с переводом Apache в режим worker. Делается это часто не просто, да и потребует смены режима работы php и другие манипуляции.

Там не придётся настройки php менять у каждого(!) виртхоста? Это он может сделать?

А панель управления позволит легко пересобрать apache и сможет с ним нормально работать?

Так задайте себе вопрос, что проще? Включить nginx в панели (или поставить через yum install и прописать по мануалам виртхосты) или иметь опыт в определении "лишних" модулей, режимах работы apache/php ?

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

Мне начинать перечислять баги ISP? Или уж остановимся... А подсчёт трафика там сколько, полгода вроде (или больше даже) не работал? ))). Ну и ещё наберётся всяких "несрастушек". Я тоже не на бейсике написан ;).

Ну и хренли он туда тогда лезет? Если понятия не имеет? А, понял. Чтобы сначала самому обжечься, а потом нанять админа. Не проще сразу нанять?

А пример можно? Боюсь, сразу станет ясно, что в рядовом случае все эти модули не нужны.

Угу. В CentOS делается просто: редактированием двух файлов (/etc/sysconfig/httpd и /etc/httpd/conf.d/php.conf). И менять там надо ну совсем чуточку. манов в интернете тоже полно. Подозреваю, что в Debian ситуация на одну команду сложнее (да поправит меня myhand).

Проще в последствии - изучить матчасть и уже настроить так настроить. В противном случае один хрен ничего толкового не выйдет (ну разве что проекты не очень важны - так хоть научиться быстро гуглить и эксперименты ставить). Кстати, нифига Nginx втыкать не проще. А включить в панели - я не знаю, но было дело, потом уже выключить его не получалось. Или получалось так, что включался с пустыми конфигами. Ну и еще всякой дряни там бывало... То он стаивлся как прокся и ничего более, то он обрабатывал статику. Ну да, я тогда так матерился помню на эту панель, ух... Человек просто нажал кнопочку "включить" и всех виртхостов как небывало. Ну да, уповаем на панель... Которая тоже далеко не панацея.

Короче я к чему: не умеешь играть на гитаре - нехрен на площадь выходить и бренькать. А если уж что-то делать - так делать качественнос полным пониманием всего, а не "как попало". Вот как-то так. А посему нужно учиться жить не по мануалам и чьим-то советам "до буковки", а учиться пользоваться справочной документацией и расширять кругозор.

---------- Добавлено 06.02.2012 в 14:36 ----------

Мне начинать перечислять баги ISP? Или уж остановимся... А подсчёт трафика там сколько, полгода вроде (или больше даже) не работал? ))). Ну и ещё наберётся всяких "несрастушек". Я тоже не на бейсике написан ;).

Ну и хренли он туда тогда лезет? Если понятия не имеет? А, понял. Чтобы сначала самому обжечься, а потом нанять админа. Не проще сразу нанять?

А пример можно? Боюсь, сразу станет ясно, что в рядовом случае все эти модули не нужны.

Угу. В CentOS делается просто: редактированием двух файлов (/etc/sysconfig/httpd и /etc/httpd/conf.d/php.conf). И менять там надо ну совсем чуточку. манов в интернете тоже полно. Подозреваю, что в Debian ситуация на одну команду сложнее (да поправит меня myhand).

Проще в последствии - изучить матчасть и уже настроить так настроить. В противном случае один хрен ничего толкового не выйдет (ну разве что проекты не очень важны - так хоть научиться быстро гуглить и эксперименты ставить). Кстати, нифига Nginx втыкать не проще. А включить в панели - я не знаю, но было дело, потом уже выключить его не получалось. Или получалось так, что включался с пустыми конфигами. Ну и еще всякой дряни там бывало... То он стаивлся как прокся и ничего более, то он обрабатывал статику. Ну да, я тогда так матерился помню на эту панель, ух... Человек просто нажал кнопочку "включить" и всех виртхостов как небывало. Ну да, уповаем на панель... Которая тоже далеко не панацея.

Короче я к чему: не умеешь играть на гитаре - нехрен на площадь выходить и бренькать. А если уж что-то делать - так делать качественнос полным пониманием всего, а не "как попало". Вот как-то так. А посему нужно учиться жить не по мануалам и чьим-то советам "до буковки", а учиться пользоваться справочной документацией и расширять кругозор.

---------- Добавлено 06.02.2012 в 14:37 ----------

У него webmin, а не isp. Там это сделано более рпавильно ;).

Вы здесь, в теме?

Давно мы стали обсуждать ispmanager? Мы обсудили, как проще сделать клиенту в общем случае.

Я сказал "проще", а не "лучше". Уже много лишнего написали.

Всё можно сделать, но самый простой вариант - поставить nginx, чем и пользуются. Имеют на это право.

У вас своё видение - делайте как нравится вам.

Если ставится вдс для себя, для пары своих сайтов - то почему бы не осилить lighttpd ? конфиг и настройка реально интуитивно понятные и простые, сам по себе потребляет меньше чем апач с нгинксом, да и полностью заменяет по функционалу их обоих - и статику отдает не хуже чем Nginx (а скорее даже лучше будет работать, я например так и не осилил волшебный конфиг Nginx, чтоб в моих условиях он в тестах обогнал настроенный мной lighttpd), с динамикой lighttpd тоже отлично работает, все настройки и прочие реврайты апачеподобные...