форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Квоты, ограничения, 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. "Лимиты использования серверных ресурсов. "	+/–
	Сообщение от Александр Лейн 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. "Лимиты использования серверных ресурсов. "	+/–
	Сообщение от Александр Лейн 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. "Лимиты использования серверных ресурсов. "	+/–
	Сообщение от Егор (??) on 30-Янв-11, 02:20
	Не столкнусь что костыль, так как позволяет очень многое, что обычными баш сериалами , особенно запускаемых по крону -не решить. А 4ре человека в смене -будут стоить дороже. Limiterd. Написан на С и работает как очень легкий демон. Память и процессор практически по минимуму потребляет. И вот задачка, как баш скриптом не убивая процесс, ограничить время потребления проца? Лимитер решает этот вопрос. Например при достижении 10% процессорного времени, процесс будет приостановлен и восстановлен позже. Очень удобно для поддержания долгоиграющих процессов. ренайс тут не поможет кстати. Если кого серьезно заинтересовала программа, пишите через форму контакта на сайте it-patrol.ru может сможем договорится на каких то условиях. С уважением, Егор >[оверквотинг удален] > А тут (я про Limiter) готовый вариант, но редиски бабла хотят… > Такая нужная вещ, а аналогов нету. > Кстати сам apache, имеет директивы лимитов RLimitMEM и RLimitCPU > И еще Cpulimit тоже не сахар, каждый раз его запускать с отдельным > PID`ом, это и время и память, а Limiter с конфигом, и > резидентом одна копия висит. > А уж про ресурсопотребление Zabbix`а я вообще молчу. > Вообще конечно большое вам спасибо sHaggY_caT, на некоторые вещи глаза вы мне > приоткрыли, т.к. в юниксах я человек новый, но в своей песочнице > придется таки искать другие пути :)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

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

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