- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Приведите пример ограничения perl скрипта на linux машине, запускаемого из под APache через suexec. Который делает тоже что и ваше предложение - убивает винт большим ИО?
При этом учтите, что вы не знаете заранее, что пользователь %username% установит этот скрипт на сервер.
man rlimit
Есть сервера, которые я обслуживаю не первый год. И до меня был админ, и после меня, наверное, будет. И не возникало подобных вопросов.
И как вы думаете, разобраться админу с неизвестным ему софтом - это быстро?
Или вы будете искать админа, который на 100% согласен с вами и сам всё настраивает 1 в 1 точно так же + использует тот же софт?
Такого админа вы будете тоже не один месяц искать. Смена админа - это всегда не лёгкий и не быстрый процесс. Купите ли вы ПО или не купите, разницы тут не будет, имхо.
Быстро или нет разбираться админу - это его проблемы. Вы серьёзно считаете, что каждый новый админ получит разрешение ставить свой любимый софт? Ну тогда корпоративный рынок не для Вас. Вообще есть администрирование систем, и есть хакерство. Ваш путь - это хакерство.
Смена админа - лёгкий и безболезненный процесс, если админ нормальный и не носит с собой уникальный софт. А вот Ваш случай - это болезненный долгий процесс с неизвестными потерями.
Смена админа - лёгкий и безболезненный процесс, если админ нормальный и не носит с собой уникальный софт. А вот Ваш случай - это болезненный долгий процесс с неизвестными потерями.
Вы немного не о том говорите.
Есть общее ПО, которое используется на серверах. А есть "сомнительные" скрипты для мониторинга. Эти скрипты нужны только админу, т.к. они ему будут помагать и информировать его.
Andreyka, одним rlimit-ом на оверселленой хостинговой машине не напасешся. дело в том,
что проблемы (у пользователей) начинаются _задолго_ до того, как все станет раком.
т.е. обычно что-то типа (как заметил Борис) acct + скрипты, которые
откручивают "плохим" пользователям определенные услуги и/или меняют тарифный план.
либо (как делают практически на любом нормальном хостинге) - саппорт, который
ловит нагрузку и делает аналогичное вручную.
а для выделенного сервера limiter нафиг не сдался, это уже выяснили. другое дело, что
и задачи виртуального хостинга он не решает (только в "планах" определение характера утилизации CPU и т.п.).
думаю, нишу этого limit'ера занимает как-раз monit - может автору имеет смысл просто
предлагать платные услуги настройки monit + доработать его, если возникнут хорошие идеи?
Есть общее ПО, которое используется на серверах. А есть "сомнительные" скрипты для мониторинга. Эти скрипты нужны только админу, т.к. они ему будут помагать и информировать его.
видимо, вы никогда не работали в большой команде сисадминов. там это самое "сомнительное" ПО
является критической частью инфраструктуры. попробуйте снести настроенный nagios и
установить zabbix - это задачка на много человекочасов и оччень болезненная для поддержания
работы того самого "общего ПО".
ваше замечание имеет смысл только если "уходя" - вы нафиг убираете за собою все подобное служебное ПО, и клиент о подобной политике в курсе.
Мониторинг из юзерспейса, на мой взгляд, это вообще глупо. От некритичной периодической нагрузки спасет аккаунтинг, который, помимо всего, устранит ее причину или переведет ее на новый тариф :)
А при критической нагрузке Ваш демон ничего не сможет сделать. Зато rlimit и прочее от нее спасет.
rlimit работает жестко но его использование оправдано в определенных ситуациях.
Но как я уже говорил, в случае чего по rlimit - процесс убивается, в случае с limiter - можно оставить жить процесс но не давать ему кушать весь проц. Если это прогнозируемый вариант конечно. Например процессы вроде gzip.
Что же касается аккаунтинга , то оно решает другую цель - кого выставить на деньги.
а LIMITER предназначен для борьбы с не прогнозируемой нагрузкой и для ограничения потребления cpu для прогнозируемой нагрузки.
Это не мониторинг - это средство активного реагирования. Тоесть что то произошло и тут же сразу на это что-то произошел ответ системы.
Для мониторинга лучше использовать Nagios, Zabbix и прочие подобные системы.
myhand, я обязательно в ближайшие дни разберусь с monit для определение конкретной разницы и постараюсь составить более полноценное сравнение, а не тот кусок предварительного анализа, что был постами раньше.
Всем спасибо за ваше мнение, это помогает мне применить свои знания и возможности в правильном направлении, вместо ударов головой об стенку.
является критической частью инфраструктуры. попробуйте снести настроенный nagios и
установить zabbix - это задачка на много человекочасов и оччень болезненная для поддержания
работы того самого "общего ПО".
В комманде работал почти год. Но мы работали с разными клиентами, т.е. это не комманда, которая обслуживала сервера одной компании.
Разговор сейчас немного не в то русло ушёл.
Я говорю о том, что это ПО выбирают устанавливают админ/админы, которые производят настройку сервера. Клиент обычно мало в этом понимает, чтобы отдавать предпочтения конкретному ПО.
Я говорю о том, что это ПО выбирают устанавливают админ/админы, которые производят настройку сервера. Клиент обычно мало в этом понимает, чтобы отдавать предпочтения конкретному ПО.
Нет, всё это совсем не так. И ПО выбирает не админ, и клиент понимает, и иногда больше админа. И год - это не срок.
В комманде работал почти год. Но мы работали с разными клиентами, т.е. это не комманда, которая обслуживала сервера одной компании.
и что? небыло никакого стандартного мониторинга? никаких стандартов по
документированию, поддерживаемому ПО? у коли стоит freebsd 4.11 а у васи Debian/4.0
и все мониторятся по-разному? и на каждом свой набор самописных утилит "активного реагирования" ((с) gor-)? надеюсь, что нет.
еще раз. если вы уходя _удаляете все_ свои утилиты, о чем клиент
предупреждается заранее - возражений нет.
штука в том, что даже на отдельном сервере снести подобные
"скрипты" часто представляется невозможным, без нарушения нормальной работы.
вот удалили вы свой аналог limiter'а - и злые пользователи у клиента-хостера начнут
жестоко драться за ресурсы, в результате чего - для большинства из них это выразится
во мнении хостинг XYZ - "тормозит".
Andreyka, одним rlimit-ом на оверселленой хостинговой машине не напасешся.
Раскрою секрет - ненадо оверселить тачки :)
Andreyka добавил 16.12.2009 в 19:06
Но как я уже говорил, в случае чего по rlimit - процесс убивается, в случае с limiter - можно оставить жить процесс но не давать ему кушать весь проц.
Дурацкая идея. Процессы будут работать медленно, запускаться новые до завершения старых - и так пока не заберут всю память со свопом. И придет oom.
Дурацкая идея. Процессы будут работать медленно, запускаться новые до завершения старых - и так пока не заберут всю память со свопом. И придет oom.
Спасибо, ваше мнение учел. Это мне дало паро идей.