Limiter - инструментарий системного администратора

"Нормальный" админ сам себе такой скрипт напишет, если он ему потребуется, имхо.

Я думаю, что вы не верно выбрали целевую аудиторию скрипта.

Himiko добавил 15.12.2009 в 12:38

Да и писать скрипты для админов - это как-то странно:)

для решения задач, перечисленных ТС есть нормальные инструменты

_разные_

1) системные лимиты (например, pam_limits)

2) скрипты инициализации демонов (где также можно выставить определенные приоритеты, ограничения - включая cpulimit, ionice)

3) мониторинг (monit, zabbix, etc). уже monit умеет делать все

то, что вы заявили.

закапывайте

myhand, ТС видимо не понимает, у потребителей, на которых он расчитывает (админы), в таком софте просто нет необходимости.

Лично моё имхо - ТС изобрёл велосипед и пытается его продать создателям мопеда с педалями:)

необходимость - есть.

просто ТС стоит начать с перечисления приемуществ

своей системы перед открытыми конкурентами.

пока их не видно. потому запускать посторонний бинарник из

под рута нет ровно никакого резону.

Лично мне проще написать свой скрипт под свои нужды.

Это удобнее (знаю, что он делает и зачем) и не нужно никаких денег платить за лицензию.

Либо воспользуюсь бесплатными аналогами. Свой скрипт предпочтительнее.

Спасибо за ответы.

Сейчас постараюсь детально ответить после каждого поста с вопросами.

gor- добавил 15.12.2009 в 16:11

Да вы перечислили хороший набор.

Например из этого набора сам использую ionice (для ограничения приоритета доступа к диску процессом бекапа, напрямую зависит от новых ядер линукса), zabbix (все мои собственные сервера и сервера клиентов стоят на этом мониторинге, и все уведомления я получаю своевременно, в том числе ввиде СМС)

За ссылку на monit - спасибо, не видел данной утилиты ранее.

cpulimit - я использовал очень давно и изначально именно он подарил мне идею. Но в отличии от cpulimit, который присоединяется к конкретному процессу , limiter может работать сразу с многими процессами.

Перечислю преимущества limiter перед cpulimit:

- Возможность ограничивать процессоры не по pid а по username, имени программы (/bin/gzip например)

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

- есть возможность указания % как для единичного процесса, так и для группы процессов подпадающее под правило (например суммарный %CPU для всех процессов /bin/gzip не должен превышать 80%CPU)

- limiter не ограничивается только этой возможностью, есть возможность применять правила к процессам, в зависимости от loadavg, а именно - изменять приоритет задачи, убивать задачу, запускать скрипт (смотрите документацию на примере файлов rules.d/danger и rules.d/critical).

Прочитал обзор monit, к сожалению не готов привести столь подробный анализ в разнице. Обязательно попробую поработать с этой программой и составить более детальное сравнение.

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

Монит больше конкурирует с zabbix чем с моим продуктом.

Мне конкурировать с zabbix, nagios нет смысла - совершенно разные цели работы.

Вот такой предварительный анализ сравнения.

Однозначно нет и не ожидается в моей утилите:

- мониторинг файловой системы

- система уведомления, прицепить можно через внешний скрипт, но лучше использовать zabbix

- тестирование сервисов на предмет работоспособности

Чего нет в monit (возможно что то упустил, сужу только по manual-у)

- все тоже что было написано в сравнении с cpulimit

- при дописывании собственных скриптов, можно ,как пример, останавливать апач при loadavg например 30, и поднимать его обратно при loadavg 10. (сам использую)

- согласно правилам - убивать скрипты, процессы, задачи. Например можно выставить что при loadavg >= 20 - убить все php скрипты.

Если у вас лично возникли какие то еще вопросы, задавайте - обязательно отвечу.

Еще раз спасибо за идею сравнения.

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

gor- добавил 15.12.2009 в 16:16

Отмечу только что это не скрипт, а бинарная программа.

И в ближайшее время на сайте будут выложены готовые правила для таких популярных панелей как:

- cpanel

- plesk

- directadmin

В будущем возможно будут охвачены и другие целевые аудитории. На сейчас согласен - еще сложно увидеть преимущества перед самописным вариантом. Но я постараюсь это исправить. Задавайте более детальные вопросы, с удовольствием отвечу.

открытых мониторингов не так много, чтобы не знать их _все_.

если честно, не могу привести реального примера - где это могло бы быть полезно. pam_limits помогут для ограничения по CPU конкретных пользователей. что-то типа cpulimit нужно

разве для конкретных программ.

ограничения по бинарнику типа /bin/gzip - вообще сомнительные. а если /home/user/bin/gzip ? :)

все это умеет и monit и любой более функциональный мониторинг, типа zabbix.

monit - ориентирован на автоматизацию обработки исключительных ситуаций. именно,

что подобно limiter - только умеет в несколько раз больше. в zabbix такое тоже можно сделать через внешние скрипты по триггерам. только в monit это более децентрализовано.

это вообще не дело мониторинга - это задача статических правил.

вообще, мое сугубое ИМХО - планировщику помогать нужно, а не палки в колеса ставить всякими cpulimit/limiter. для того, чтобы управлять планировщиком - есть приоритеты. то же самое

касается I/O шедулера.

ну можно, конечно :) все уже украдено до нас :D

LImiter - это не мониторинг система, это скорее набор правил для реагирования, отталкиваясь от loadavg, с модулем ограничения процессов ПО %cpu.

С вашим ИМХО согласен, но только в случае выделенного сервера, под выделенный проект.

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

Спасибо за указание промаха, я постараюсь сделать на страницах продукта больше акцент на ВебХостингПанели , вместо фразы "систем, где пользователи или процессы могут создавать трудно прогнозируемую настройку."

Изначально утилита писалась под нужды шаредхостинга. Там где клиент может выполнять действия - в принципе труднопрогнозируемые, Но может использоваться и на других системах - где есть трудно прогнозируемые поведения системы.

Ну и последний контр довод, который тут никто не привел.

Вместо Лимитера можно использовать 4х админов, работающих по 8м часов.

Они будут получать сообщения от Zabbix системы, и оперативно с достаточно большой долей ИНТЕЛЕКТА - будут реагировать на проблемы на сервере.

PS за счет этой утилиты я смог за последний год свободно вздохнуть и не беспокоится что какой-то Вася Пупкин положит сервер и мне срочно прийдется бросать пиво и компанию, лезть на сервер и смотреть что там этот Пупкин учудил и почему на сервере лоад больше 50.

sim и prm от rfxn делают тоже самое

Пара отличий, SIM надо запускать по крону. И частота срабатывания зависит от того, как часто вы его запускаете.

SIM - это баш скрипт, который при большой нагрузке на системе банально не успевает толком сработать и собственно сам добавляет нагрузки.

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

Главное отличие, что limiter срабатывает немедлено, висит уже в памяти и в основном не требует дополнительных ресурсов для изменения приоритета, убивания или замораживания процессов.

В случае катастрофической нехватки памяти - SIM не сработает, limiter - сработает.

PRM - работает аналогично SIM и имеет теже недостатки. Еще одно отличие - он не делает "ограничение" по CPU - он просто убивает процесс.

Есть еще SPRI от того же разработчика. С теми же недостатками. Данная утилита делает смену приоритетов ( renice) для процессов на базе нагрузки.

Идея класная, но одним изменением приоритетов у процессов, стабильность сервера не сделаешь.