Ваше рассуждение по существу согласен. Я постараюсь составить более детальное обьяснени что зачем и почему, чтоб не возникало таких долгих рассуждений на тему "Надо ли оно вообще".
Клиент должен видеть возможности, сравнивать с своими потребностями и решать "надо" или "не надо".
Что касается дополнительного функционала, то он конечно же будет. Но судя по диалогу здесь - пока что мне не удалось донести основную мысль до аудитории.
Ну или те кто понял, просто не подали виду.
Всем еще раз спасибо за выражение ваших мыслей, они помогают построить правильный подход к клиенту.
Спасибо, ваше мнение учел. Это мне дало паро идей.
rlimit работает жестко но его использование оправдано в определенных ситуациях.
Но как я уже говорил, в случае чего по rlimit - процесс убивается, в случае с limiter - можно оставить жить процесс но не давать ему кушать весь проц. Если это прогнозируемый вариант конечно. Например процессы вроде gzip.
Что же касается аккаунтинга , то оно решает другую цель - кого выставить на деньги.
а LIMITER предназначен для борьбы с не прогнозируемой нагрузкой и для ограничения потребления cpu для прогнозируемой нагрузки.
Это не мониторинг - это средство активного реагирования. Тоесть что то произошло и тут же сразу на это что-то произошел ответ системы.
Для мониторинга лучше использовать Nagios, Zabbix и прочие подобные системы.
myhand, я обязательно в ближайшие дни разберусь с monit для определение конкретной разницы и постараюсь составить более полноценное сравнение, а не тот кусок предварительного анализа, что был постами раньше.
Всем спасибо за ваше мнение, это помогает мне применить свои знания и возможности в правильном направлении, вместо ударов головой об стенку.
Если станет популярной, и кто то напишет клон на перле - я только порадуюсь за этого студента и сообщество.
На текущий момент бесплатно получить эту утилиту на свой сервер возможно только одним способом, взять меня на админство вашего сервера.
Если кто смотрел мой топик о Админстве серверов, видел наверно пост /ru/forum/comment/5409159
Написанный 3 месяца назад. В посте упоминается некое ПО, это какраз limiter.
Если кто еще заинтересован на тестирование этой программы попасть - вполне возможно. Условия не изменились.
Каждый новый сервер с скачками лоада - это новые правила, которые потом могут использовать все. Конечно после их публикации мною.
Вы правы - публичная часть не решает. Но и я не собираюсь останавливаться на достигнутом.
Новое ядро поддерживает /proc/PID/io, с которым я успел уже немного поработать и есть наработке в ДЕВ версии. Пока правда еше не стабильные. В Январе месяце я сделаю релиз версии с поддержкой правил на основе IO.
Пока что, в случае роста нагрузки можно просто грохнуть все пользовательские процессы, что косвенно убьет ИО. Дальше пойти по логу, посмотреть что было убито и отсюда отталкиваться.
Пока только так, но и так уже не плохо.
gor- добавил 16.12.2009 в 00:09
Возможно вы правы, и мне стоит сделать акцент на владельцев серверов, вынужденных менять админов время от времени.
Никаких стандартов в борьбе с нагрузкой на сейчас нет. Каждый админ это постигает по своему, и вполне возможно что limiter получит свою нишу тут.
Сам знаю что такое смотреть скрипт на предмет понимания как оно работает, потому делаю максимальный уклон на максимальную документацию.
Плюс к этому будет доступно достаточно много готовых правил на разные случаи. Админу сервера достаточно будет подобрать подходящее и применить, или сделать на подобии.
Спасибо за ваше мнение.
Himiko для вас это велосипед, потому что вы написали уже свой, только на паскале?)
Пиплы - не нравится идея, или вы реализовали свою для себя и пользуйетесь - на здоровье.
Но давайте вместо высказывание "БУ велосипед" , вести беседу в конструктивном русле?
Есть алтернативные программы? Пишите о них - пусть о узнают и другие посетители форума.
Здоровая конкуренция - всегда хорошо.
PS мы все когда то начинали, и когда то были новичками. Вот и сейчас есть новечки в этой сфере и у них банально не хватает знаний чтоб написать "сомнительный" скрипт
Himiko, знаю что медлено, потому и писал свой limiter.
Но я решил пойти дальше, и развивать эту програму платно.
Не все админы могут писать проги, да и не должны.
Эта программа для тех кто хочет и понимает что это именно сэкономит их время.
Кто же считает что по старинце кучей крон скриптов, и самописом проще пользоваться - видимо просто не ценят свое время.
gor- добавил 15.12.2009 в 22:00
Конечно не только надо но и необходимо.
Приведите пример ограничения perl скрипта на linux машине, запускаемого из под APache через suexec. Который делает тоже что и ваше предложение - убивает винт большим ИО?
При этом учтите, что вы не знаете заранее, что пользователь %username% установит этот скрипт на сервер.
Пара отличий, SIM надо запускать по крону. И частота срабатывания зависит от того, как часто вы его запускаете.
SIM - это баш скрипт, который при большой нагрузке на системе банально не успевает толком сработать и собственно сам добавляет нагрузки.
В остальном согласен, он может многое, и часть идеи какраз взято из этого источника , а именно срабатывание от уровня нагрузки.
Главное отличие, что limiter срабатывает немедлено, висит уже в памяти и в основном не требует дополнительных ресурсов для изменения приоритета, убивания или замораживания процессов.
В случае катастрофической нехватки памяти - SIM не сработает, limiter - сработает.
PRM - работает аналогично SIM и имеет теже недостатки. Еще одно отличие - он не делает "ограничение" по CPU - он просто убивает процесс.
Есть еще SPRI от того же разработчика. С теми же недостатками. Данная утилита делает смену приоритетов ( renice) для процессов на базе нагрузки.
Идея класная, но одним изменением приоритетов у процессов, стабильность сервера не сделаешь.
LImiter - это не мониторинг система, это скорее набор правил для реагирования, отталкиваясь от loadavg, с модулем ограничения процессов ПО %cpu.
С вашим ИМХО согласен, но только в случае выделенного сервера, под выделенный проект.
Там и надо играться с конкретными процессами и настройками, ибо задача - чтоб все работало, а не , как вы сказали, палки в колеса ставить.
Спасибо за указание промаха, я постараюсь сделать на страницах продукта больше акцент на ВебХостингПанели , вместо фразы "систем, где пользователи или процессы могут создавать трудно прогнозируемую настройку."
Изначально утилита писалась под нужды шаредхостинга. Там где клиент может выполнять действия - в принципе труднопрогнозируемые, Но может использоваться и на других системах - где есть трудно прогнозируемые поведения системы.
Ну и последний контр довод, который тут никто не привел.
Вместо Лимитера можно использовать 4х админов, работающих по 8м часов.
Они будут получать сообщения от Zabbix системы, и оперативно с достаточно большой долей ИНТЕЛЕКТА - будут реагировать на проблемы на сервере.
PS за счет этой утилиты я смог за последний год свободно вздохнуть и не беспокоится что какой-то Вася Пупкин положит сервер и мне срочно прийдется бросать пиво и компанию, лезть на сервер и смотреть что там этот Пупкин учудил и почему на сервере лоад больше 50.
