Если простои сервера некритичны, то можно попробовать дописать эти команды с суффиксом ">> /root/logfile" в /etc/rc.local и из rescue посмотреть, что написалось :)
Я правда это вчера сделал. Работать только лучше стало после yum reinstall (rpmdb уцелел, так как наст.оящий Одмин должен знать меру - во время нажать Ctrl+C).
gor-: rlimit работает жестко но его использование оправдано в определенных ситуациях.
Но как я уже говорил, в случае чего по rlimit - процесс убивается, в случае с limiter - можно оставить жить процесс но не давать ему кушать весь проц. Если это прогнозируемый вариант конечно. Например процессы вроде gzip.
Что же касается аккаунтинга , то оно решает другую цель - кого выставить на деньги.
а LIMITER предназначен для борьбы с не прогнозируемой нагрузкой и для ограничения потребления cpu для прогнозируемой нагрузки.
Это не мониторинг - это средство активного реагирования. Тоесть что то произошло и тут же сразу на это что-то произошел ответ системы.
Для мониторинга лучше использовать Nagios, Zabbix и прочие подобные системы.
Касательно такого подхода Фил Кулин когда-то читал доклад на ХостОбзоре. Если кратко - чем больше мы тормозим использование ресурсов в узких местах, тем больше нагрузки мы получим. Ведь когда мы тормозим приоритет процесса, мы заставляем его выполняться дольше. Это значит, что io будет более размазано по времени (больше долгих seek'ов), что память будет использоваться в несколько раз дольше, чем нужно, будет тратится cpu на переключения и планировщик. В совокупности и плохом случае мы получим засвопвшийся сервер со сдохшими дисками :)
Подобный limiter, по идее, должен уметь не ренайсить процессы в зависимости от нагрузки, а устранять причину этой самой нагрузки - например, отслеживать ботов/посетителей, которые вызывают слишком много нагрузки, и блокировать их. Как вариант - отслеживать наиболее грузящий скрипт или URL и блокировать его. Как более плохой вариант - отслеживать грузящий виртхост и блокировать его. Как еще большее плохой вариант - блокировать всего юзера, правда я не знаю, сколько клиентов останется у такого хостера и имеет ли это смысл на собственном дедике.
Таким образом, я не разделяю высокие нагрузки на прогнозируемые и непрогназируемые. На мой взгляд, есть только "в пределах нормы" и "ненормально высокая".
Аккаунтинг не пытается развести клиента на деньги, а смотрит динамику роста нагрузки в пределах нормы, пытаясь не допустить ненормально высоких нагрузок и пытается гарантировать равенство всех пользователей :) Иными словами, он используется как раз как мониторинг. Я вот аккаунтинг уже год делаю, он уже претерпел три полных переделывания, но все равно не могу понять, что надо считать и как, чтобы видеть и прошлое, и возможное будущее 😮
Ну а rlimit же помогает решать внезапные проблемы, когда под угрозой сама работа сервера, то есть - быстро реагирует на проблему. Лучше уж десяток необработанных запросов, чем тысяча тормозящих.
Кстати, у меня есть подозрения, что по LA считать текущую нагрузку не очень адекватно - ему на пересчет требуется время, которого иногда нет, и он не всегда показывает адекватную нагрузку - все зависит от задач. Есть сервера (при одинаковых физических конфигурациях), которые при LA 50 чувствуют себя нормально, а другие - дохнут уже при >8.
Мониторинг из юзерспейса, на мой взгляд, это вообще глупо. От некритичной периодической нагрузки спасет аккаунтинг, который, помимо всего, устранит ее причину или переведет ее на новый тариф :)
А при критической нагрузке Ваш демон ничего не сможет сделать. Зато rlimit и прочее от нее спасет.
myhand: о чем и речь :) ну чем здесь апач хуже? написать для него простенький модуль, зависящий от mod_dbd. prefork здесь не нужен - лучше worker. нагрузка не та, чтобы серьезно заморачиваться с асинхронщиной.
1) при использовании mpm_prefork, на обработку одного запроса будет тратиться 1 процесс. Это - расточительство.
2) при использовании mpm_worker, думаю, все равно останется достаточно явный вопрос производительности и сложности написания. Хотя, я не пробовал апач с mpm_worker, так как не вижу в этом смыслаю. Там все на тредах?
Ага, перечитал тему, где-то половина ее ускользнула от меня при первом прочтении :((
В принципе, мне тоже кажется, дергать php нецелесообразно, и можно написать модуль для nginx, который будет делать это. Правда, там придется писать асинхронный коннектор к БД, что очень бажно и затянется.
Если простои сервера некритичны, то можно попробовать дописать эти команды с суффиксом ">> /root/logfile" в /etc/rc.local и из rescue посмотреть, что написалось :)
А KVM есть?
Есть возможность показать после ребута, когда сеть не работает:
ifconfig -a
brctl show
?
Я правда это вчера сделал. Работать только лучше стало после yum reinstall (rpmdb уцелел, так как наст.оящий Одмин должен знать меру - во время нажать Ctrl+C).
Я сегодня на ноуте сделал rm -rf /*
Работает что надо!
rlimit работает жестко но его использование оправдано в определенных ситуациях.
Но как я уже говорил, в случае чего по rlimit - процесс убивается, в случае с limiter - можно оставить жить процесс но не давать ему кушать весь проц. Если это прогнозируемый вариант конечно. Например процессы вроде gzip.
Что же касается аккаунтинга , то оно решает другую цель - кого выставить на деньги.
а LIMITER предназначен для борьбы с не прогнозируемой нагрузкой и для ограничения потребления cpu для прогнозируемой нагрузки.
Это не мониторинг - это средство активного реагирования. Тоесть что то произошло и тут же сразу на это что-то произошел ответ системы.
Для мониторинга лучше использовать Nagios, Zabbix и прочие подобные системы.
Касательно такого подхода Фил Кулин когда-то читал доклад на ХостОбзоре. Если кратко - чем больше мы тормозим использование ресурсов в узких местах, тем больше нагрузки мы получим. Ведь когда мы тормозим приоритет процесса, мы заставляем его выполняться дольше. Это значит, что io будет более размазано по времени (больше долгих seek'ов), что память будет использоваться в несколько раз дольше, чем нужно, будет тратится cpu на переключения и планировщик. В совокупности и плохом случае мы получим засвопвшийся сервер со сдохшими дисками :)
Подобный limiter, по идее, должен уметь не ренайсить процессы в зависимости от нагрузки, а устранять причину этой самой нагрузки - например, отслеживать ботов/посетителей, которые вызывают слишком много нагрузки, и блокировать их. Как вариант - отслеживать наиболее грузящий скрипт или URL и блокировать его. Как более плохой вариант - отслеживать грузящий виртхост и блокировать его. Как еще большее плохой вариант - блокировать всего юзера, правда я не знаю, сколько клиентов останется у такого хостера и имеет ли это смысл на собственном дедике.
Таким образом, я не разделяю высокие нагрузки на прогнозируемые и непрогназируемые. На мой взгляд, есть только "в пределах нормы" и "ненормально высокая".
Аккаунтинг не пытается развести клиента на деньги, а смотрит динамику роста нагрузки в пределах нормы, пытаясь не допустить ненормально высоких нагрузок и пытается гарантировать равенство всех пользователей :) Иными словами, он используется как раз как мониторинг. Я вот аккаунтинг уже год делаю, он уже претерпел три полных переделывания, но все равно не могу понять, что надо считать и как, чтобы видеть и прошлое, и возможное будущее 😮
Ну а rlimit же помогает решать внезапные проблемы, когда под угрозой сама работа сервера, то есть - быстро реагирует на проблему. Лучше уж десяток необработанных запросов, чем тысяча тормозящих.
Кстати, у меня есть подозрения, что по LA считать текущую нагрузку не очень адекватно - ему на пересчет требуется время, которого иногда нет, и он не всегда показывает адекватную нагрузку - все зависит от задач. Есть сервера (при одинаковых физических конфигурациях), которые при LA 50 чувствуют себя нормально, а другие - дохнут уже при >8.
Мониторинг из юзерспейса, на мой взгляд, это вообще глупо. От некритичной периодической нагрузки спасет аккаунтинг, который, помимо всего, устранит ее причину или переведет ее на новый тариф :)
А при критической нагрузке Ваш демон ничего не сможет сделать. Зато rlimit и прочее от нее спасет.
Оффтоп: лучше не формулировать в вопросе опроса и содержании темы вопросы, требующие противоположного ответа :)
На самом деле, некоторые переводы сделаны так, что английский вариант намного понятнее.
Если Вы пообещаете себе 2 месяца редактировать только vi, то потом жить без него не сможете :)
о чем и речь :) ну чем здесь апач хуже? написать для него простенький модуль, зависящий
от mod_dbd. prefork здесь не нужен - лучше worker. нагрузка не та, чтобы серьезно заморачиваться
с асинхронщиной.
1) при использовании mpm_prefork, на обработку одного запроса будет тратиться 1 процесс. Это - расточительство.
2) при использовании mpm_worker, думаю, все равно останется достаточно явный вопрос производительности и сложности написания. Хотя, я не пробовал апач с mpm_worker, так как не вижу в этом смыслаю. Там все на тредах?
Ага, перечитал тему, где-то половина ее ускользнула от меня при первом прочтении :((
В принципе, мне тоже кажется, дергать php нецелесообразно, и можно написать модуль для nginx, который будет делать это. Правда, там придется писать асинхронный коннектор к БД, что очень бажно и затянется.