eServer.ru, да я это понимаю :( Это и обидно - что при одной цене расходы в России идут на взятки и площадь, а в том же США - на обрудование и персонал. Ведь если делать что-то совсем качественное, то цена получится такая, что никто не будет это брать.
eServer.ru, всё-таки, цены не сопоставимы. Если в говнодц в европе можно снять сервер за 30 евро, и он будет лежать пару часов в месяц, то в России одно около 3000р, и не факт, что оно не будет лежать пару часов в месяц.
Ну хоть почитайте тогда исходники OpenVZ в части return -ENOMEM.
Память и kmemsize - разные вещи, я выше расписал, что такое kmemsize.
При отказе создания ресурса по kmemsize всё равно возвращается ENOMEM.
Не позорьтесь.
Boris A Dolgov добавил 21.09.2010 в 10:07
kmemsize - лимит, отвечающий за память ядра, которую нельзя засвопить. Там хранится информация о сокетах, файловых дескрипторах, процессах и прочая информация, с которой работает ядро. 14417734 - действительно, довольно низкое значение лимита. Просто увеличьте его в два-три раза.
>Под N модулей -- 2^n пакетов
Не, меньше. Я же сказал, роли. Ну какие могут быть роли у nginx? Прозрачный прокси (только HTTP, аналог для imap+pop можно вынести отдельно) и/или кеширующий - один/два пакета. Бакенд (там встроенный перл есть, не забыли?). Какой-нить специализированный тип хостинга, например "свой ютуб". И т.п. Наборы модулей будут встроенны перекрывающиеся в чем-то, естественно. Наконец, сборка где "все-все-все".
Но не будете же Вы говорить, что это - удобнее, чем make config?
>Из перечисленного только стабильный ABI является реальной "проблемой" для nginx. Вытекающий из сказанного выше про то, что он вечная бета (или альфа - на вкус и цвет...).
0) Вообще, Вы нашли достаточно старый пост. Было в англ. рассылке недавно.
1) ABI меняется даже от ключей конфигурации - например, функции для openssl/pcre/md5, члены структур для них же, и из-за этого не получается бинарной совместимости.
2) И, наконец, архитектура заточена именно под такое использование. Не надо делать из nginx apache, достаточно взять apache (c) кто-то.
>А это меняется на ура в дебиане, например. Бинарником, который "немного умеет быть конфигурируемым" (пакет apache2-suexec-custom).
А откуда он берёт конфигурацию? Если из какого-то файла, то это - потенциальная уязвимость.
Если он, как предложил himiko, пишет по какому-то оффсету нужное значение, то это костыль, а не конфигурируемый бинарник.
>Как прибить такого апача под пользователем - понятно, по бездействию. А вот как запустить - менее очевидно. Есть гипотеза, что сработает какой-то вариант на proxy_next_upstream. Т.е. если апач у юзера прибит - направляем запрос сначала на универсальный upstream, который "пускает" нужный бакенд (судя по виртуалхосту), затем снова на этот бакенд. Но это вариант как-то, того... Не поделитесь что Вы имели в виду?
Мне виделся вариант с
location / { proxy_pass user_backend; error_page 402 = @start_backend; }
location @start_backend { fastcgi_pass starter; fastcgi_param USER username; fastcgi_param URI $request_uri; }
starter.pl:
...
start_backend($user)
print "X-Accel-Redirect: ${uri}"
Но можно придумать и более красивые варианты и работающие с POST варианты, используя всякие фичи вроде ssi, или простой модуль.
Можно сделать какой-нибудь простой враппер, который будет слушать все вхосты, тупо проксировать бит-в-бит и проверять запущенность/нагрузку на какой-то сокет, и лично я, скорее всего, так бы и сделал.
>1) Технически можно, конечно. Собрать несколько разных пакетов nginx с кастомными наборами модулей (под работу nginx разными ролями). Уж такой он nginx - вечная бета, что с него взять. Надеюсь, что со временем может быть поддержка подгружаемых модулей. Хотя есть большая вероятность, что до релиза оно никогда и не доживет, будет вечное 0.xxxx.
Под N модулей -- 2^n пакетов :) Разработчик весьма ясно объясняет в рассылке, почему на данный момент нет возможности делать выносные модули.
>2) Немного непонятно, зачем кому-то "путь до suexec" менять?
А путь до suexec, например, нужно менять, если хочется держать сайты не /var/www, а в /home. (точнее, это не путь до suexec, а путь внутри него).
Давайте уже перестанем заниматься снисхождением от абстрактного к конкретному, а займёмся восхождением от конкретного к абстрактному :)
>Я имел в виду - знаете ли Вы готовое решение, которое это "умеет"?
>Если брать предложенное - "запустить своего апача под каждого клиента", то там такого нету.
Если брать готовый апач, то он и не умеет разбиваться на несколько пользователей, и балансироваться между ними :) Всегда придётся писать конфиги или скрипты. В данном случае я даже представляю, как это делать без модификации кода апача или nginx.
Некоторые пакеты нельзя сконфигурить, будучи собранными - например, модули nginx, путь до suexec, и так далее.
Тем не менее, до gcc-4.5.1-vanilla, linux-2.6.35-vanilla и прочего я обновился без проблем, и искал баги уже там.
А это уже зависит от умений :)
>А что там не так? rpm сборки я делал сравнительно мало, но в дебиане аналогичное "под конкретную цель" - делается на ура.
Если захотелось собрать программу "ааа" с настройками, то нельзя сделать cd /usr/ports/aaa и написать make config install
>Есть такой момент. Нешто там до сих пор вовсе ничего не патчат?
почти.
>Ну, все 9999 причин перечислять было несколько влом...
>Неа. Тогда будет не "лучшее", а "идеальное" (подставьте любой синоним превосходной степени).
Я считал, что лучшее - уже превосходная степень. А у превосходной степени нет недостатков. Если хотите, можем "поиграть" в называние недостатка и "придумывание" способа, как его обходит идеальная система.
>Нагрузка другая. На массовом виртуальном хостинге может на 1000й висящий на нем сайт сегодня и вовсе не придут. На 756-м будет всего 10 обращений от пользователей за весь день (равномерно распределены). На 111-й придет пойсковик. Помучает немного, сделав 50 запросов и уйдет. И т.п.
>Т.е. нагрузка очень неравномерная. Держать ради каждого хоста или хоть клиента свой апач - немного накладно будет. Нет?
Можно считать, что нагрузка вида "rps" примерно совпадает, а дальше всё зависит от того, насколько хорошо Вы выбираете количество воркеров для каждого виртхоста в каждый момент времени в зависимости от последней посещаемости. В базовом варианте, может висеть демон, который смотрит rps за последние полчаса, делит его на константу, и выставляет такое число воркеров.
>Ну, сравнительно дешевый. От 1000+ хостов на сервере. ТП где-нить от 1-2$.
Ну, это вполне реально - главное, научить ТП крутить юзеру конфиг его апача. А дальше пусть хоть mod_php себе ставит.
С тем же успехом можно обвинить rpm в убогости сборки из исходников под конкретную цель
Использую её на трёх серверах и на ноуте 🙄
Пригодна для того, чтобы обновить gcc, ядро, и прочие глубокие компоненты до -rc, и знать, ничего не отвалится, а так же знать, что проблемы - не в патчах вендора, а у апстрима.
Ваша идея в том, что хорошее поддерживается из-за того, что переходить на лучшее - слишком криво для текущей инфраструтуры? Странно звучит.
Вообще, если переходить к идеализированному миру, то лучшее должно предоставлять способы онлаин-миграции с хорошего :)
Нужно. Система - так же, программы - те же, цели - тоже примерно те же. Только надо ещё заботиться о том, чтобы пользователи не могли скушать слишком много ресурсов, но это можно делать уже "вне юзерспейса".
Смотря что понимать под "массовым" - возможность хостеру с 10$ в кармане поставить это, или захостить пару сотен тысяч сайтов на десятке серверов.
