The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Лимиты использования серверных ресурсов. "
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Квоты, ограничения, QoS / Linux)
Изначальное сообщение [ Отслеживать ]

"Лимиты использования серверных ресурсов. "  +/
Сообщение от zghuladze (ok) on 12-Фев-10, 23:19 
Добрый день,



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


1. Не допускается пиковое использование процессами пользователя более чем 2,5% ресурсов сервера.
2. На пользовательские cgi-скрипты накладываются следующие ограничения:
• максимальное количество одновременно выполняемых задач - 32;
• максимальное допустимое время работы cgi-скрипта: не более 15 процессорных секунд и не более 5 минут реального времени;
• максимальное количество открытых файлов на один процесс - 32;
• максимальное использование оперативной памяти - 64Mb на процесс, при этом под данные отводится не более 32Mb
• максимальный размер файла 512Mb;

3. На процессы пользователя, выполняемые из unix shell / cron, накладываются следующие ограничения:
• максимальное количество одновременно выполняемых задач - 64;
• максимальное допустимое время работы скрипта: не более 10 процессорных минут;
• максимальное количество открытых файлов на один процесс - 128;
• максимальное использование памяти - 128Mb на процесс, при этом под данные отводится не более 64Mb
• максимальный размер файла 1024Mb;

4. На php-скрипты накладываются следующие ограничения:
• максимальное время выполнения - 30 секунд;
• максимальное использование памяти 32Мб

5. Максимальное количество одновременных соединений с сервером БД MySQL - 64.
6. Максимальное количество одновременных соединений с http-сервером –
7. Максимальное количество одновременных подключений к почтовым сервисам – не более 10, интенсивность подключения к почтовым сервисам – не более 10 соединений в минуту.


Спасибо.
Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Лимиты использования серверных ресурсов. "  +/
Сообщение от sHaggY_caT (ok) on 13-Фев-10, 23:53 
Ответила Вам на ixbt, впрочем, Вы знаете...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Лимиты использования серверных ресурсов. "  +/
Сообщение от Александр Лейн email on 14-Фев-10, 00:21 
>Ответила Вам на ixbt, впрочем, Вы знаете...

а мне ответите? тоже заинтересовался...

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Лимиты использования серверных ресурсов. "  +/
Сообщение от PavelR (??) on 14-Фев-10, 07:48 
>Ответила Вам на ixbt, впрочем, Вы знаете...

Да-да, интересно почитать, может что новое узнаем. Давайте ссылку на Ваш ответ.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Лимиты использования серверных ресурсов. "  +/
Сообщение от sHaggY_caT (ok) on 14-Фев-10, 12:06 
>>Ответила Вам на ixbt, впрочем, Вы знаете...
>
>Да-да, интересно почитать, может что новое узнаем. Давайте ссылку на Ваш ответ.

Я работала в одном из лидеров Российского рынка (название предпочитаю не называть на подиндексном пространстве):

http://forum.ixbt.com/topic.cgi?id=7:37477

Некоторые компании пишут _для_себя_ Apache модули (дорабатывают Nginx, и даже пишут ядерные модули для FreeBSD и Linux)

Альтернативой для нас, "простых смертных", кроме OVZ, может быть cgroups + (Apache suexec, можно и Nginx, но я никогда не видела, что бы кто-то такое делал не на легких VPS) + fastcgi, или что-то похожее по концепции.

Но это все не тестировалось по всему миру почти десять лет на десятках тысяч инсталляций, как OVZ/PVC, поэтому на шаред-хостинге большинство просто огранизует дежурство сотрудников с root-правами 7/24, кроме отрубов нагрузок это помогает решить кучу других проблем.

А так, limits.conf(5), login.conf(5) тоже помогают решить часть проблем, и не дать end-user'у, например, угробить сервер, растаривая архивы с миллионами файлов в прайм-тайм, делая дампы жутких баз, и так далее.

Так же они полезны, например, поставить лимиты на сам Apache, что бы дежурный администратор смог попасть на сервер, который DDoS'т, жутко нагрузили, и т д

Как резюме, что бы поставить и почти забыть про сервер, но получить хорошую плотность, советую (и сама использую) OpenVZ, или PVC, если есть деньги и нужны коммерческие гарантии и саппорт (который у Parallels, имхо, вполне адекватный)

Все написанное выше является личным опытом и имхо, написано не для холиваров (особенно про Nginx + fastcgi, попробуйте нарыть инсталляции где-нибудь хотя бы в 200 бэкэндов без Apache и под _хостинг_, когда сотрудники компании не контролируют, что там запускают end-user'ы)

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Лимиты использования серверных ресурсов. "  +/
Сообщение от Александр Лейн email on 14-Фев-10, 12:45 
очень интересно! спасибо! будем изучать! :) я почему-то всегда думал, что проще сделать это на виртуальном гипервизоре а-ля VMware ESXi. наверно я был не прав. :)
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Лимиты использования серверных ресурсов. "  +/
Сообщение от sHaggY_caT (ok) on 14-Фев-10, 12:51 
>очень интересно! спасибо! будем изучать! :) я почему-то всегда думал, что проще
>сделать это на виртуальном гипервизоре а-ля VMware ESXi. наверно я был
>не прав. :)

ESX + vsphere это лучшее(имхо), что есть на рынке виртуализации. Но контейнеры это не виртуализация, и плотность OVZ/PVC и ESX отличается, как минимум, на порядок.

И OVZ/PVC это не конкуренты Hyper-V, ESX(i), Xen, KVM, это решение из другой ниши и для других задач (обычно, более низкобюджетных). Если нужно поделить сервер на 5-10 частей, имхо, конечно, лучше использовать гипервизор: тут и выбор виртуалок не ограничен одной ОС, и свои ядерные модули для каждой виртуалки для всяких HA кластеров, и импорт LUN'ов с SAN, и т д.

Более того, контейнеры вполне можно запускать в качестве гостевой системы под гипервизором :) Для OVZ даже есть официальное ядро для Xen, но лучше, конечно, ставить на железо, так как дополнительный оверхед, и шанс наткнуться на какие-то редкие баги.


На OVZ/PVC с мощной дисковой подсистемой вполне реально использовать 60-70 легких контейнеров, постоянно находящихся под нагрузкой на достаточно средненьком сервере(x2 quard Xeon 54XX, raid10 лучше на SAS, 16-24Gb ОЗУ, цифры не с потолка, а из личного опыта), и еще с сотню просто запущенных.


Но мне, правда, для _виртуализации_ все равно больше нравится KVM/Xen через Libvirt просто даже из ценовых соображений, и по тому, что это свободное, в отличае от VmWare, решение, которое можно пилить в удобную для себя сторону :)
Мы Libvirt интегрировали с Puppet, он генерит XML-ки доменов.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Лимиты использования серверных ресурсов. "  +/
Сообщение от metacom (ok) on 19-Фев-10, 15:14 
Частично еще может помочь Limiter http://it-patrol.ru/limiter/details/п╫п╟я│я┌я─п╬п╧п╨п╟-rules-cpulimit

только прога платная, неужели действительно нету бесплатных аналогов ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Лимиты использования серверных ресурсов. "  +/
Сообщение от sHaggY_caT (ok) on 19-Фев-10, 18:07 
>Частично еще может помочь Limiter http://it-patrol.ru/limiter/details/п╫п╟я│я┌я─п╬п╧п╨п╟-rules-cpulimit
>
>только прога платная, неужели действительно нету бесплатных аналогов ?

С их сайта:

>ограничить процессорное время для бекап процесса,

Бесплатный cpulimit и, опять же, pam ограничения

> - изменить приоритет процессов ftp сервиса,

за renice уже просят денег? ну-ну

>- уничтожить все процессы php при load avg > 10

И за Kill?

>- поднять или остановить службу в зависимости от  load avg

Аналогично

===============

Итого, ничего нового: обычный набор костылей, который _ничего_ (имхо) не решает, и не дает для изоляции пользователей друг от друга, и который можно написать за несколько дней на bash, интегрировав, например, с Zabbix.

А можно просто поставить мониторинг, и посадить за него на посменное дежурство четырех человек на круглосуточное дежурство, получится гораздо(!) эффективнее


Вместо этого можно использовать бесплатный OpenVZ, если нет проблем с религией и Linux (как, увы, есть у многих посетителей OpenNet, "предпочитающих" FreeBSD, если что, у меня нет религиозных проблем с использованием BSD там, где она, в свою очередь сильна): десятки стабильно работающих нагруженных окружений даже на самом слабом сервере (на P4 плотность может быть больше, чем у, например, ESX на dual Нехалемах с десятками гигабайт ОЗУ, если только не запускать под ESX те же OpenVZ системы с контейнерами :) Изврат, но в некоторых случаях вполне можно использовать, если очень не хватает железа, ноды под виртуализацию достаточно мощные, а хостинга в компании сравнительно с остальным бизнесом мало)

Виртуализация, имхо, не подходит для хостинга, а вот контейнеры решают проблему изоляции конечных клиентов друг от друга, как бонус давая свой набор ПО в каждый контейнер, и имеет возможности, очень близкие к виртуализации (как Вам, например, возможность без всякого изврата с перекомпиляцией по другим путям использовать на одном сервере Plesk, Cpanel, и WebMin в зависимости от того, к чему привык end-user, или из экономических соображений? А так же live-migration без дорогих полок с дисками, просто между локальными дисками серверов?)

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Лимиты использования серверных ресурсов. "  +/
Сообщение от metacom (ok) on 19-Фев-10, 19:23 
Костыль согласен, но у меня например в данный момент ситуация такова что мой хостинг сервер крутится на VDS с 400Mhz CPU и 256 Mb ОЗУ, разумеется об OVZ в данном случае речь не идет вообще, что касается написания этого костыля на bash`е то сколько это все сожрет ресурсов? (особенно в прайм тайм, когда скрипту надо будет реагировать чтобы сбалансировать нагрузку, или что еще хуже в момент атаки…)  Остается только си, но на си его ежу понятно за пять минут не родить, неделя убьётся как минимум, со всеми отладками. А тут (я про Limiter) готовый вариант, но редиски бабла хотят…
Такая нужная вещ, а аналогов нету.

Кстати сам apache, имеет директивы лимитов RLimitMEM и RLimitCPU  

И еще Cpulimit тоже не сахар, каждый раз его запускать с отдельным PID`ом, это и время и память, а Limiter с конфигом, и резидентом одна копия висит.

А уж про ресурсопотребление Zabbix`а я вообще молчу.

Вообще конечно большое вам спасибо sHaggY_caT, на некоторые вещи глаза вы мне приоткрыли, т.к. в юниксах я человек новый, но в своей песочнице придется таки искать другие пути :)

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Лимиты использования серверных ресурсов. "  +/
Сообщение от Егор email(??) on 30-Янв-11, 02:20 
Не столкнусь что костыль, так как позволяет очень многое, что обычными баш сериалами , особенно запускаемых по крону -не решить.
А 4ре человека в смене -будут стоить дороже.

Limiterd. Написан на С и работает как очень легкий демон. Память и процессор практически по минимуму потребляет.

И вот задачка, как баш скриптом не убивая процесс, ограничить время потребления проца?
Лимитер решает этот вопрос. Например при достижении 10% процессорного времени, процесс будет приостановлен и восстановлен позже. Очень удобно для поддержания долгоиграющих процессов.
ренайс тут не поможет кстати.

Если кого серьезно заинтересовала программа, пишите через форму контакта на сайте it-patrol.ru может сможем договорится на каких то условиях.

С уважением, Егор

>[оверквотинг удален]
> А тут (я про Limiter) готовый вариант, но редиски бабла хотят…
> Такая нужная вещ, а аналогов нету.
> Кстати сам apache, имеет директивы лимитов RLimitMEM и RLimitCPU
> И еще Cpulimit тоже не сахар, каждый раз его запускать с отдельным
> PID`ом, это и время и память, а Limiter с конфигом, и
> резидентом одна копия висит.
> А уж про ресурсопотребление Zabbix`а я вообще молчу.
> Вообще конечно большое вам спасибо sHaggY_caT, на некоторые вещи глаза вы мне
> приоткрыли, т.к. в юниксах я человек новый, но в своей песочнице
> придется таки искать другие пути :)

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру