Ну, не знаю, у нас примерно вот так все это происходит:



Конечно же все зависит от типа нагрузки, т.е. если база, cgi, cron или ssh, то пишется логин пользователя и запрос.

Если нагрузка от mod_php, то пишется только сайт.

Замечательно. А теперь давайте рассмотрим другую сторону вопроса.
Откуда вообще возникает нагрузка? Сама по себе? От изменения погоды? От типа контента или языка написания скриптов? Ответ очевиден. Нагрузка возникает в тот момент, когда на сайт клиента заходят посетители. И посещаемость сайта - это тот фактор, который находится вне зоны контроля клиента. Согласны?
Далее. Вы не ограничиваете максимальное потребление ресурсов техническими средствами. Т.е. теоретически вообще можно загрузить сервер так, что он уйдет в даун. Может ли клиент повлиять на это? Ответ, опять же, очевиден - нет. Так что вы хотите от клиента, будучи не в состоянии лимитировать используемые им ресурсы?

Теоретически загрузить сервер почти до дауна так можно на несколько секунд, дальше сработает система мониторинга и убьет процесс, потребляющий большое количество ресурсов.

Огромную нагрузку на сервер можно создать одним запросом!

Если начать все лимитировать в соответствии с тарифами, то начинаются вопли: "А почему мой сайт все время в дауне? А вот сейчас опять все тормозит. У Вас же написано, что он будет находится 99.9% времени в сети, а его опять нет. А вот у меня на таком-то хостинге все прекрасно работает." И опять же переходить на более высокий тариф отказываются, выражаясь при этом не всегда цензурной речью, после чего требуют возврат средств и съезжают.

Так что клиенту итак плохо, итак...

Кривой скрипт сам по себе не может ничего загрузить. Его еще запустить надо.



"Нормальность" - это вообще понятие относительное. Равно как и проценты загрузки. От чего эти проценты? От Cel 1200 или от 8хOpteron 2600? У вас, кстати, сервера сертифицированы? А то, может, они сами настолько криво собраны на коленке из нонеймовых деталей, что там ничего не работает как полагается?
Вам, кстати, никто не мешает указать список разрешенного ПО и просматривать скрипты пользователей на предмет глючности, как это делали хостеры лет десять назад.


Насколько я понимаю, уведомление о расторжении договора вы получили от клиента. Почему деньги не возвращаете? Закон не для вас писан?



Давайте уж говорить честно. Если начать все лимитировать в соответствии с тарифами, то не получится оверселлить. Dixi.

50% сервера.

Применительно к 8хOpteron 2600 - это 50%/8, т.е. 6.25%.

Знаете ли, потребление скриптом ресурсов - это величина абсолютная, а не относительная. Ему нужно конкретное количество памяти, конкретное количество процессорного времени, конкретное I/O диска и т.д. Так вот, я лично не знаю, что у вас там за сервер стоит - первый или второй из приведенного мной примера. А в договоре при этом пишется, скажем, ограничение 10%. Как считаете, клиент в состоянии оперировать такими данными в ходе оптимизации своего ПО или хотя бы в процессе принятия решения о том, какой тариф ему выбрать?

Не в этом дело.

Вот смотрите:
Скрипт вызывается, предположим, 5 раз в сутки и создает нагрузку на сервер 15% (разрешенная 10%).

В случае с урезаниями, все 5 раз скрипт не будет запущен, т.к. он превысил лимит в 10%.

В случае с мониторингом нагрузки, скрипт все 5 раз выполнится. Но если он вызовется, например 50 раз, и средняя нагрузка за еденицу времени превысит 10%, то система мониторинга оповестит хостера о нарушении, и клиенту будет выслано предупреждение, или аккаунт будет блокирован.

Проблема не в потреблении ресурсов. Проблема в том, что нет грамотного общения клиента с хостёром. когда клиент заказывает услугу, он смотрит чтобы получить как можно больше ресурсов и за наименьшие деньги. Хостёр а реальном потреблении ресурсов будущего клиента не знает. С первого взгляда, иногда сайты бывает безобидные. В течении первого месяца выявляються реальные потребности сайта, на данный момент.
Дальше, после того, как сайт попадает на лучший сервер, он постепенно начинает расти. Это неизбежно. После нескольких месяцев, тот же сайт потребляет гораздо больше ресурсов. Тем более, те кто раскручивает сайты обычно нагружает разными счёчиками на третей стороне. Все эти счётчики грузит сервер на котором хоститься сайт. Вот тут начинаеться проблемы, клиент расказывает, что услуга плохая, а хостёр подсовывает какую то статистику. Клиент не понимает, что сервер имеет очень ограниченные ресурсы и конкретную себестоимость. И сервер должен нести прибыль. Также клиент не понимает, что сайт посадить на мощный Xeon, Opteron со скази и прибумбасами, должно стоить примерно 4-5 раз дороже, чем на любой пятух. При том, грамотно управляемый пятух будет лучше делать свою работу чем мощный но перегруженный Xeon, Opteron.
Когда идёт в какой то ресторан, почему тио никто не спорит, когда за кусок мяса отваливает 20 баксов, но вот когда за кусок качественного сервера отвалить 20 в месяц, тут начинаеться рыдания. А хостёры любой ценой хотят приманить себе клиента, не важно что почти даром, но главое чтобы сделка состоялась. А потом из этих клиентов отбирает себе таких, в статитике которых стоит нули.
Теперь во всём мире хостёры продают воздух, так как этого требует клиенты.

Тут очень кратко, хотя и так получилось слишком много, ни кто столько не читает

нагрузка от клиента это не только его скрипты. скажем человек может иметь и не большую посещаемость но огромную базу - пример - wikipedia.ru или его домен может привлечь по каким то причинам спамеров и на его емайлы начнуть насылать чертову тучу спама. или он разметсил большое количество мелких файлов и при архивировании его аккаунта это вызывает затык. все что угодно может быть.
суппорт может (но не обязан) указать на конкретные причины по которым возникает нагрузка в тех случаях когда это возможно без длительного исследования. обычно, правда идет по другому пути - просто переносят клиента на другой сервер - посвободнее. человеческие трудозатраты просто не могут быть оправданными при текущих ценах на хостинг. а если такого сервера нет - то просто просят клиента куда нибудь уйти. хостера за это винить нельзя - ему виднее что ему выгоднее - потерять такого клиента или пытаться разобраться в его проблеме.
винить же хостера за то что он на виртуальном хостинге не лимитирует жестко все и вся сложно. в основном виртуальный хостинг сводится сейчас к беспредельному оверселлу и это касается не только трафика и места на диске но и ресурсов сервера конечно.

А ведь еще есть mod_status

[quote name='Marina' date='04.12.2006, 21:43' post='62383']
Замечательно. А теперь давайте рассмотрим другую сторону вопроса.
Откуда вообще возникает нагрузка? Сама по себе? От изменения погоды? От типа контента или языка написания скриптов?[/quote]
Нагрузка возникает по простой причине - это глюк в одном скипте/запросе помноженный на число посетителей. Такой глюк можно отследить и указать что конкретно править.

[/quote]
Ответ очевиден. Нагрузка возникает в тот момент, когда на сайт клиента заходят посетители. И посещаемость сайта - это тот фактор, который находится вне зоны контроля клиента. Согласны?[/quote]

Не совсем. Имея на руках данные о глюках клиент вправе их исправить.

[quote]
Далее. Вы не ограничиваете максимальное потребление ресурсов техническими средствами. Т.е. теоретически вообще можно загрузить сервер так, что он уйдет в даун.
[/quote]
А вот это уже действительно интересно - это изначально так и задумывалось или просто сисадмин не умеет делать?

[quote name='kosmohost.com' date='04.12.2006, 21:50' post='62387']
Теоретически загрузить сервер почти до дауна так можно на несколько секунд, дальше сработает система мониторинга и убьет процесс, потребляющий большое количество ресурсов.
[quote]
Вообще то сработает не система мониторинга, потому что она может лежать в свопе.
При перегрузке сначала отсреливаются процессы по превышеню лимита, а если это не помогает, то ядро начинает расстрел через oom

[quote]
Огромную нагрузку на сервер можно создать одним запросом!
[/quote]
Каким? К mysql или же к вебсерверу?




Сайт от лимитов в дауне не бывает. Кроме того, человек сам увидет какие из его скриптов не отрабатываются на хостинге по превышению ресурсов и сам сможет их исправить.





Нагрузка на сервер не считается в процентах, лимитировать Вы не умеете...

Именно в процентах она считается, просто они пишутся в виде долей.

Но я действительно говорил о процентах процессора.



Это у Вас она может лежать в свопе, а у нас она все время запускается через определенные промежутки времени (используется небольшой демон). И убивает или рестартит в случае чего вполне нормально.
А за свопом следить надо, во время оперативку добавляя или клиентов не прибавляя.



Это Вы вырезали не правильно.



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



К обоим, но при условии, что у них в настройках не стоит "шаг в лево, шаг в право - расстрел!".






Согласен, руки не доходят парсинг усовершенствовать.

Замечательно. А теперь давайте рассмотрим другую сторону вопроса.
Откуда вообще возникает нагрузка? Сама по себе? От изменения погоды? От типа контента или языка написания скриптов? Ответ очевиден. Нагрузка возникает в тот момент, когда на сайт клиента заходят посетители.

- Не всегда. Скрипт можно запускать кроном.

И посещаемость сайта - это тот фактор, который находится вне зоны контроля клиента. Согласны?

- Полный бред, даже расписывать лень.

Далее. Вы не ограничиваете максимальное потребление ресурсов техническими средствами. Т.е. теоретически вообще можно загрузить сервер так, что он уйдет в даун. Может ли клиент повлиять на это? Ответ, опять же, очевиден - нет. Так что вы хотите от клиента, будучи не в состоянии лимитировать используемые им ресурсы?

- Если мы ограничим максимальное потребление ресурсов процентов 50 клиентов взвоют в первый же день. Только клиент отвественнен за свой сайт и скрипты и никто кроме него.

Как относятся пользователи форума-автомобилисты к гаишникам с радаром в кустах? Думаю, что все примерно одинаково. А теперь представьте, что эти же самые гаишники ещё и заставили всех ездить на машинах без спидометра!, потом попрятались в кустах и периодически радостные выскакивают оттуда, как черт из табакерки с радостными воплями: "Превысил, превысил!"

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

хороший пример
однако как сказали, якобы "Спидометр" клиенту не нужен

Получается как в анекдоте: я им и унитаз приносил и задницу показывал, а бумагу мне так и не продали.

Даже если и дать им спидометр - это ничего не изменит.
Клиентам, которые понимают, что такое хостинг, ресурсы, скрипты, спидометр не нужен.
А которые не понимают - им не поможет.

Скрипт, подверженный sql-injection может увести сервер в глубокий даун.
Безграмотные sql-запросы к огромным неоптимизированным базам загибают сервер.

Вот основные проблемы.
Чем здесь поможет спидометр?

[quote name='kosmohost.com' date='05.12.2006, 10:45' post='62467']
Именно в процентах она считается, просто они пишутся в виде долей.
[/quote]

Это не так. Загрузка может быть учтена системой (в данный момент речь о FreeBSD):
avio Average number of I/O operations per execution

cp Sum of user and system time, in minutes

cpu Same as cp

k CPU-time averaged core usage, in 1k units

k*sec CPU storage integral, in 1k-core seconds

re Real time, in minutes

s System time, in minutes

tio Total number of I/O operations

u User time, in minutes

Вот например кусок аккаутинга:

trumpe 912 2.66cpu 8344tio 9328704k*sec
jesus2 77 0.08cpu 39tio 493613k*sec
facult 2257 0.83cpu 8048tio 5702099k*sec
magell 96 0.15cpu 66tio 468658k*sec
medhte 55 0.01cpu 12tio 470800k*sec
admixr 11487 0.16cpu 1829tio 576022k*sec

Покжите мне тут проценты

[quote]
Но я действительно говорил о процентах процессора.
Это у Вас она может лежать в свопе, а у нас она все время запускается через определенные промежутки времени (используется небольшой демон). И убивает или рестартит в случае чего вполне нормально.
[/quote]

Демон так же может быть в свопе и уже ничего не кильнет

[quote]
Не фига себе новость. Это Вы хотите поставить лимит на запросы к апачу, и при этом не убить процесс, глупость. Это не к лимитированию тогда относится, а к защите апача от перегрузки, ито тормоза в работе появятся.
[/quote]

Нет, именно к лимиту. Или для Вас секрет что само ядро умеет denied overstep of process limit?

[/quote]
Согласен, руки не доходят парсинг усовершенствовать.
[quote]
Так купите готовый