tuxee: причем тут ваще лимиты???!!!
недобросовестный хостер раздал всю доступную память на дидеке, и на некоторых ВПС вылазят такие ошибки.
перезагрузка обычно помогает, но не надолго.
это стандратная проблема почти на всех недобросовестных OpenVZ-хостингах.
проблема в хостере 100%!!!!!!!!!!!
Не позорьтесь.
Boris A Dolgov добавил 21.09.2010 в 10:07
kmemsize - лимит, отвечающий за память ядра, которую нельзя засвопить. Там хранится информация о сокетах, файловых дескрипторах, процессах и прочая информация, с которой работает ядро. 14417734 - действительно, довольно низкое значение лимита. Просто увеличьте его в два-три раза.
Не, меньше. Я же сказал, роли. Ну какие могут быть роли у 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 @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 и прочего я обновился без проблем, и искал баги уже там.
Если можно так нижнюю грань числа воркеров поставить в 0 - это прокатит. Если нет - никакого быдлохостинга за < 1$ не получится.
>А что там не так? rpm сборки я делал сравнительно мало, но в дебиане аналогичное "под конкретную цель" - делается на ура.
Если захотелось собрать программу "ааа" с настройками, то нельзя сделать cd /usr/ports/aaa и написать make config install
>Есть такой момент. Нешто там до сих пор вовсе ничего не патчат?
почти.
>Ну, все 9999 причин перечислять было несколько влом...
>Неа. Тогда будет не "лучшее", а "идеальное" (подставьте любой синоним превосходной степени).
Я считал, что лучшее - уже превосходная степень. А у превосходной степени нет недостатков. Если хотите, можем "поиграть" в называние недостатка и "придумывание" способа, как его обходит идеальная система.
>Нагрузка другая. На массовом виртуальном хостинге может на 1000й висящий на нем сайт сегодня и вовсе не придут. На 756-м будет всего 10 обращений от пользователей за весь день (равномерно распределены). На 111-й придет пойсковик. Помучает немного, сделав 50 запросов и уйдет. И т.п.
>Т.е. нагрузка очень неравномерная. Держать ради каждого хоста или хоть клиента свой апач - немного накладно будет. Нет?
Можно считать, что нагрузка вида "rps" примерно совпадает, а дальше всё зависит от того, насколько хорошо Вы выбираете количество воркеров для каждого виртхоста в каждый момент времени в зависимости от последней посещаемости. В базовом варианте, может висеть демон, который смотрит rps за последние полчаса, делит его на константу, и выставляет такое число воркеров.
>Ну, сравнительно дешевый. От 1000+ хостов на сервере. ТП где-нить от 1-2$.
Ну, это вполне реально - главное, научить ТП крутить юзеру конфиг его апача. А дальше пусть хоть mod_php себе ставит.
myhand: Обсуждается не "бинарное распространение" в сравнении со сборкой, а убожества реализации этого самого "бинарного распространения" во фре, по сравнению с...
С тем же успехом можно обвинить rpm в убогости сборки из исходников под конкретную цель
Мне тоже "нравится slackware" :) Но, боюсь, это из разряда ностальгии по былым временам, первым попавшим в руки дистрибутивам и т.п. Объективно, кроме как "поиграться" (если не на что больше потратить время) - она сейчас ни на что не пригодна.
Использую её на трёх серверах и на ноуте 🙄
Пригодна для того, чтобы обновить gcc, ядро, и прочие глубокие компоненты до -rc, и знать, ничего не отвалится, а так же знать, что проблемы - не в патчах вендора, а у апстрима.
На хостинге в 100-1000 тазиков стоит система XXX. Геройский админ приходит и с цифрами доказывает руководству, что обновление до системы YYY даст на 20% (цифра с потолка, но скорее оптимистическая) более производительную систему и вообще "нам будет все удобнее", оно "лучшее" (все честно и объективно). Так прям и бросятся обновлять до "лучшего"? Или останутся на "хорошем", но без потенциальных проблем обновления, необходимости менять и переписывать кучу всего в инфраструктуре, и т.п.?
Ваша идея в том, что хорошее поддерживается из-за того, что переходить на лучшее - слишком криво для текущей инфраструтуры? Странно звучит.
Вообще, если переходить к идеализированному миру, то лучшее должно предоставлять способы онлаин-миграции с хорошего :)
Принципы-то те же, да нагрузка на массовом виртуальном хостинге принципиально другая, нежели на сервере с парой хорошо посещаемых сайтов. Нужно объяснять?
Нужно. Система - так же, программы - те же, цели - тоже примерно те же. Только надо ещё заботиться о том, чтобы пользователи не могли скушать слишком много ресурсов, но это можно делать уже "вне юзерспейса".
Вот и я о том, тут плюшек даже больше, чем при использовании специализированного php-fpm.
Тем не менее, для дешевого массового хостинга - это все не подходит.
Смотря что понимать под "массовым" - возможность хостеру с 10$ в кармане поставить это, или захостить пару сотен тысяч сайтов на десятке серверов.
myhand: Определенная доля субъективности, конечно, есть. Но Вы ведь не будете утверждать, что управление бинарными пакетами во фре устроено сравнительно примитивно, по сравнению с дебианом или даже центос? Это вполне объективно. И не относится к "узкой сфере задач". Но о таких вещах все, в общем-то и не спорили (подобные "споры" - это скорее "базары", где каждый расхваливает достоинства своего "товара").
Нет, это необъективно - у сборки из исходников есть свои преимущества, и у бинарного распространения тоже есть свои преимущества. Мне, вообще, нравится slackware - захотел - поставил бинарник от вендора, захотел - очень просто собрал свой пакет и поставил его себе. И, скорее, как раз это и относится к узкой сфере - преимущества пакетов видны, если надо уметь быстро развёртывать и управлять инфраструктурой, а сборки из исходников - если надо экономить миллисекунды или делать что-то совсем кастомное.
myhand:
Думал речь идет о "проблеме" с php5-gd.
Нет, я говорил о первоначальном вопросе ТС.
myhand:
Вы, я гляжу, идеалист. Если 9999 причин не пользоваться "лучшим", если есть "неплохое". Что не отметает наличия "лучшего".
Лучшее - на то и лучшее, чтобы не было 9999 причин не использовать его :)
Вот вас к тому и спросили. Это, мягко говоря, не совсем "хостинг". Под последним словом все-таки обычно подразумевается массовый виртуальный хостинг. Наверное ТС тоже имел в виду этот смысл?
Да. Но принципы работы те же, описанные в количестве "слишком" тяжелых сисколлов на запрос.
В сущности, разве это не одно и тоже (что и фастцги)? Тот же php-fpm умеет масштабироваться по-типу prefork mpm. Зачем изобретать велосипед, когда все уже есть в апаче (+ куча других mpm).
Примерно - да. Но позволяет использовать всякие mod_perl, mod_python и прочие радости apache, держа процессы для пользователя резидентно в памяти. Фактически - да, получается тот же php-fpm.
>Можно узнать, почему Вы обвинили меня в необъективности?
Я обвинил не Вас, а спор - потому что почти любое мнение по поводу операционной системы - субъективно, исходя хотя бы из того, что высказывающийся в пользу определенной системы человек либо долго работает с ней и привык к ней, либо работает в узкой сфере задач, где эта система действительно имеет некоторые преимущества. Иными словами, если бы была объективно лучшая операционная система - другие бы погибли :)
>К вам такой вопрос - сколько на ваших серверах аккаунтов (или сайтов)? тех где работает fastcgi
Обычно - около 1-2. Но зато где-нибудь c десятком миллионов хитов :)
Если убрать и эту субъективность, то, по логике, php-cgi действует по принципу "1.5 процесса на 1 запрос" (да, suexec тоже можно посчитать), mpm-itk - "1 процесс на keepalive-сессию" (что, кстати, пагубно сказывается при использовании nginx-фронтенда, так как получается 1 процесс на 1 запрос), а fcgi - 1 процесс на [любое заданное число] запросов.
Ещё я видел забавной идеей поднятие для каждого пользователя своего apache в количестве 3-4 процессов, которые балансируются одним apache или nginx. Получается тоже достаточно хорошо - совмещает плюсы php-itk и fcgi.
причем тут ваще лимиты???!!!
недобросовестный хостер раздал всю доступную память на дидеке, и на некоторых ВПС вылазят такие ошибки.
перезагрузка обычно помогает, но не надолго.
это стандратная проблема почти на всех недобросовестных OpenVZ-хостингах.
проблема в хостере 100%!!!!!!!!!!!
Не позорьтесь.
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 и прочего я обновился без проблем, и искал баги уже там.
Если можно так нижнюю грань числа воркеров поставить в 0 - это прокатит. Если нет - никакого быдлохостинга за < 1$ не получится.
А это уже зависит от умений :)
>А что там не так? 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$ в кармане поставить это, или захостить пару сотен тысяч сайтов на десятке серверов.
Определенная доля субъективности, конечно, есть. Но Вы ведь не будете утверждать, что управление бинарными пакетами во фре устроено сравнительно примитивно, по сравнению с дебианом или даже центос? Это вполне объективно. И не относится к "узкой сфере задач". Но о таких вещах все, в общем-то и не спорили (подобные "споры" - это скорее "базары", где каждый расхваливает достоинства своего "товара").
Нет, это необъективно - у сборки из исходников есть свои преимущества, и у бинарного распространения тоже есть свои преимущества. Мне, вообще, нравится slackware - захотел - поставил бинарник от вендора, захотел - очень просто собрал свой пакет и поставил его себе. И, скорее, как раз это и относится к узкой сфере - преимущества пакетов видны, если надо уметь быстро развёртывать и управлять инфраструктурой, а сборки из исходников - если надо экономить миллисекунды или делать что-то совсем кастомное.
Думал речь идет о "проблеме" с php5-gd.
Нет, я говорил о первоначальном вопросе ТС.
Вы, я гляжу, идеалист. Если 9999 причин не пользоваться "лучшим", если есть "неплохое". Что не отметает наличия "лучшего".
Лучшее - на то и лучшее, чтобы не было 9999 причин не использовать его :)
Да. Но принципы работы те же, описанные в количестве "слишком" тяжелых сисколлов на запрос.
В сущности, разве это не одно и тоже (что и фастцги)? Тот же php-fpm умеет масштабироваться по-типу prefork mpm. Зачем изобретать велосипед, когда все уже есть в апаче (+ куча других mpm).
Примерно - да. Но позволяет использовать всякие mod_perl, mod_python и прочие радости apache, держа процессы для пользователя резидентно в памяти. Фактически - да, получается тот же php-fpm.
>Можно узнать, почему Вы обвинили меня в необъективности?
Я обвинил не Вас, а спор - потому что почти любое мнение по поводу операционной системы - субъективно, исходя хотя бы из того, что высказывающийся в пользу определенной системы человек либо долго работает с ней и привык к ней, либо работает в узкой сфере задач, где эта система действительно имеет некоторые преимущества. Иными словами, если бы была объективно лучшая операционная система - другие бы погибли :)
>К вам такой вопрос - сколько на ваших серверах аккаунтов (или сайтов)? тех где работает fastcgi
Обычно - около 1-2. Но зато где-нибудь c десятком миллионов хитов :)
Если убрать и эту субъективность, то, по логике, php-cgi действует по принципу "1.5 процесса на 1 запрос" (да, suexec тоже можно посчитать), mpm-itk - "1 процесс на keepalive-сессию" (что, кстати, пагубно сказывается при использовании nginx-фронтенда, так как получается 1 процесс на 1 запрос), а fcgi - 1 процесс на [любое заданное число] запросов.
Ещё я видел забавной идеей поднятие для каждого пользователя своего apache в количестве 3-4 процессов, которые балансируются одним apache или nginx. Получается тоже достаточно хорошо - совмещает плюсы php-itk и fcgi.
fastcgi.
Второй спор - глуп, бессмысленен, необъективен.
Кажется, за ................ скрыто что--то вроде deny from all