Онлайн-форум hostobzor.ru > О нагрузке на сервер со стороны клиентов

Помощь - Поиск - Пользователи - Календарь

Полная версия: О нагрузке на сервер со стороны клиентов

Онлайн-форум hostobzor.ru > Архив (темы до 1.06.2015). Только для чтения. > Коммерческий хостинг. Общие форумы > Общие вопросы

Страницы: 1, 2

kosmohost.com

04.12.2006, 20:32

Цитата

На это я вам могу с точно такой же "достоверностью" возразить, что 95% "хостеров" - реселлеры Васи Пупкины из Пердяевки. И у них нет не только "минимального логирования", но даже и понятия о том, что это вообще такое. Ну а если серьезно, то клиенты отправляются хостерами (в частности тем, о котором идет речь в данной ветке) в пешее эротическое путешествие вообще без каких либо обоснований, да еще и анонимно - от какого-нибудь виртуального Алексея. Это нормально?

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

Цитата

Здравствуйте

Наша система мониторинга сервера выявила, что Ваш сайт domain.tld превышает допустимые системные лимиты по использованию процессора.

Ниже Вы можете видеть часть логов системы мониторинга за dd.mm.gggg, где указаны максимальные пики загруженности процессора (>90%), а также общее время пиков.

Согласно договору с нами, а также с согласия нашей администрации, аккаунт с данным сайтом был заблокирован.

Способы решения проблемы:

- воспользоваться услугой аренды сервера
- оптимизировать скрипты
- обратиться в Технический отдел для перехода на vip-тариф

Для консультации по каким-либо вопросам воспользуйтесь контактами
С уважением, Тех. поддержка КосмоХост

Контакты:

Поддержка:
support@kosmohost.com
kosmohost@mail.ru
ICQ 323-884-397
ICQ 217-962-731
тел. 8 (909) 645-29-54
------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------
| Дата | Домен | %исп. CPU | скрипт | Время запроса |
--------------------------------------------------------------------------------------------------
| [Дата и время] | [Домен] | 80% | test.php | 10сек. |
--------------------------------------------------------------------------------------------------
| [Дата и время] | [Домен] | 81% | test.php | 10сек. |
--------------------------------------------------------------------------------------------------
| [Дата и время] | [Домен] | 82% | test.php | 10сек. |
--------------------------------------------------------------------------------------------------

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

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

Marina

04.12.2006, 20:43

Цитата(kosmohost.com @ 04.12.2006, 20:32)

Ну, не знаю, у нас примерно вот так все это происходит:
Конечно же все зависит от типа нагрузки, т.е. если база, cgi, cron или ssh, то пишется логин пользователя и запрос.
Если нагрузка от mod_php, то пишется только сайт.

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

kosmohost.com

04.12.2006, 20:50

Цитата(Marina @ 04.12.2006, 20:43)

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

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

kosmohost.com

04.12.2006, 21:01

Цитата

Так что вы хотите от клиента, будучи не в состоянии лимитировать используемые им ресурсы?

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

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

Marina

04.12.2006, 21:14

Цитата(Ylich @ 04.12.2006, 20:58)

кривой скрипт и посетители это причина

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

Цитата

хотим чтобы он пользовался нормальным ПО, которое при 100 посетителях загружает сервер на 40-50 процентов

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

Цитата

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

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

Цитата(kosmohost.com @ 04.12.2006, 21:01)

Если начать все лимитировать в соответствии с тарифами, то начинаются вопли

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

kosmohost.com

04.12.2006, 21:14

Цитата

50% сервера.

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

Marina

04.12.2006, 21:21

Цитата(kosmohost.com @ 04.12.2006, 21:14)

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

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

kosmohost.com

04.12.2006, 21:23

Цитата

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

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

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

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

gylys

05.12.2006, 02:46

Цитата(Marina @ 04.12.2006, 19:43)

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

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

rustelekom

05.12.2006, 04:16

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

eSupport.org.ua

05.12.2006, 08:05

Цитата(kosmohost.com @ 04.12.2006, 21:32)

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

А ведь еще есть 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 или же к вебсерверу?

Цитата(kosmohost.com @ 04.12.2006, 22:01)

Если начать все лимитировать в соответствии с тарифами, то начинаются вопли: "А почему мой сайт все время в дауне?

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

Цитата(kosmohost.com @ 04.12.2006, 22:23)

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

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

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

kosmohost.com

05.12.2006, 09:45

Цитата

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

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

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

Цитата

Вообще то сработает не система мониторинга, потому что она может лежать в свопе.
При перегрузке сначала отсреливаются процессы по превышеню лимита, а если это не помогает, то ядро начинает расстрел через oom smile.gif

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

Цитата

А вот это уже действительно интересно - это изначально так и задумывалось или просто сисадмин не умеет делать? smile.gif

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

Цитата

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

Цитата

К mysql или же к вебсерверу?

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

Цитата

А ведь еще есть mod_status rolleyes.gif

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

mchost.ru

05.12.2006, 10:44

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

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

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

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

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

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

Admin

05.12.2006, 13:35

Цитата(mchost.ru @ 05.12.2006, 10:44)

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

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

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

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

mak

05.12.2006, 14:24

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

levb

05.12.2006, 14:33

Цитата

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

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

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

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

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

eSupport.org.ua

05.12.2006, 16:55

[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]
Так купите готовый

Цитата(mchost.ru @ 05.12.2006, 11:44)

Ответ на этот вопрос даст аккаунтинг.

Цитата

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

Кто же Вам виноват если практикуете такой подход?

Поможет тем, что можно скинуть клиенту лог таких sql запросов и попросить исправить.
А вот если он не исрпавит - то тогда можно и отказать в услугах.

kosmohost.com

05.12.2006, 17:08

Цитата

Так купите готовый wink.gif

Уже усовершенствовал свой.

Цитата

denied overstep of process limit? smile.gif

Только как это к mod_php прикрутить?...

edogs

05.12.2006, 17:23

Цитата(levb @ 05.12.2006, 14:33)

Даже если и дать им спидометр - это ничего не изменит.
Клиентам, которые понимают, что такое хостинг, ресурсы, скрипты, спидометр не нужен.
А которые не понимают - им не поможет.
Скрипт, подверженный sql-injection может увести сервер в глубокий даун.
Безграмотные sql-запросы к огромным неоптимизированным базам загибают сервер.
Вот основные проблемы.
Чем здесь поможет спидометр?

Тем что измерит скорость и покажет её клиенту.
Есть объем места на тарифе, есть мерялка этого места, клиенту всё предельно понятно.
Более средняя ситуация с траффиком. Кто-то дает спидометр, кто-то заявляет что спидометр не нужен и прячется в кустах с радаром.

Крайняя ситуация с нагрузкой. Даже при ЖЕЛАНИИ клиент фиг узнает свою среднюю и максимальную нагрузку у большинства хостеров.
Если лимит скорости 10% нагрузки, а мы знаем что форум при 20к хитов дает 2% нагрузки, а при 40к хитов дает 8% нагрузки, это что, нам никак не поможет?

levb

05.12.2006, 17:37

Цитата

Если лимит скорости 10% нагрузки, а мы знаем что форум при 20к хитов дает 2% нагрузки, а при 40к хитов дает 8% нагрузки, это что, нам никак не поможет?

Чем Вам поможет знание, того, насколько Вы грузите сервер?
Нагрузка от этого не уменьшится.

Это поможет Вам рассчитать сколько можно выжать ещё, не более.

Если вернуться к гаишникам - и лимиты есть, и спидометры, а всё равно бьются, и в огромных количествах.

edogs

05.12.2006, 18:14

Цитата(levb @ 05.12.2006, 17:37)

Чем Вам поможет знание, того, насколько Вы грузите сервер?

Например это покажет насколько успешна была последняя оптимизация скриптов (не важно кем).

Цитата(levb @ 05.12.2006, 17:37)

Нагрузка от этого не уменьшится.
Это поможет Вам рассчитать сколько можно выжать ещё, не более.

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

Цитата(levb @ 05.12.2006, 17:37)

Если вернуться к гаишникам - и лимиты есть, и спидометры, а всё равно бьются, и в огромных количествах.

Правильно. Бьются. Но даже непрофессионалы (те которые не умеют определять нужную скорость на глаз) могут посмотреть на спидометр и соблюсти скоростной режим указанный на знаках и правилами). Для чего ратовать за отмену знаков, спидометров и правил?

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

) - мы бы посмотрели на него, и сделали бы вывод о смене тарифа или о смене типа отдачи файлов или еще чего-нибудь.

Admin

05.12.2006, 18:24

Цитата(levb @ 05.12.2006, 17:37)

Если вернуться к гаишникам - и лимиты есть, и спидометры, а всё равно бьются, и в огромных количествах.

Лев, ну зачем Вы делаете вид, что не понимаете о чем идёт речь?

Хорошо, вот Вам более безкровный вариант аналогичной же ситуации.

Открыли торговлю картошкой на овощебазе и запретили выносить более 5 кг, а весы на выходе не поставили. Более того, выдали авоськи неограниченного размера, куда и 1, и 5, и 500 кг влезет.

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

levb

05.12.2006, 18:28

Стоп.

Я не за отмену спидометров.
Я говорю только, что спидометр не есть панацея.

Admin

05.12.2006, 18:44

Цитата(levb @ 05.12.2006, 18:28)

Стоп.

Я не за отмену спидометров.
Я говорю только, что спидометр не есть панацея.

Не панацея от ситуации, в которую вляпалась Юля? А как тогда можно спасти свои деньги от таких хостеров, которые считают грубым нарушением правил хостинга неумышленное превышение нагрузки?

levb

05.12.2006, 18:45

Цитата

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

Пётр, я уже писал в соседней теме, что от жёстких лимитов, в первую очередь, проиграет клиент.

Цитата

А как тогда можно спасти свои деньги от таких хостеров, которые считают грубым нарушением правил хостинга неумышленное превышение нагрузки?

Напишу в третий раз - я против поступка и методов mchost.
Только не стоит валить всё в одну кучу.

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

К сожалению, у mchost своё видение ситуации.

edogs

05.12.2006, 18:47

Цитата(levb @ 05.12.2006, 18:28)

Стоп.
Я не за отмену спидометров.
Я говорю только, что спидометр не есть панацея.

А почему не панацея? При наличии головы у клиента естественно. Можете объяснить?

levb

05.12.2006, 19:01

Цитата

А почему не панацея? При наличии головы у клиента естественно. Можете объяснить?

Потому что ни какой ценности, кроме информативной, он не имеет.
Нагрузка от того, что ты знаешь её величину, не снизиться.

Применительно к данному топику - если бы был спидометр, который зафиксировал превышение, Вы бы стали говорить "топикстартер редиска"?

PS Надеюсь, Вы поняли о каком топике я пишу.

edogs

05.12.2006, 19:08

Цитата(levb @ 05.12.2006, 19:01)

Потому что ни какой ценности, кроме информативной, он не имеет.

Информация как раз наибольшая ценность из всех

Цитата(levb @ 05.12.2006, 19:01)

Нагрузка от того, что ты знаешь её величину, не снизиться.

При наличии информации о нагрузке - её возможно не придется снижать, ибо можно держать в рамках, а не ждать "пока гром".

Цитата(levb @ 05.12.2006, 19:01)

Применительно к данному топику - если бы был спидометр, который зафиксировал превышение, Вы бы стали говорить "топикстартер редиска"?

Честно говоря этой фразы не поняли. Отметим лишь что смысл спидометра не в отмечании превышения, а в измерении нагрузки.
Ага, увидели Ваше уточнение и поняли

Топикстартера редиской мы бы не назвали, но если нагрузка росла вместе с посещаемостью, и отключение было прогнозируемым, то ССЗБ и не более того.
И если нагрузка месяц от месяца растет, то хостеру не вредно было бы сказать "а вот через месяц Вам придется или снижать нагрузку или съезжать."
А если нагрузка (от старых скриптов) "вдруг" подпрыгнула (яндекс напал к примеру), то мы бы предпочли что бы хостер не отключал аккаунт, а к примеру отдавал бы 503 ошибку каждый 2,5,10 запрос и немедленно сообщил о проблеме клиенту.
А если нагрузка подросла (от нового софта например), то можно вырубить этот новый скрипт вообще, не трогая весь аккаунт и опять же послать уведомление.
Насколько это реально - без понятия, но речь не об этом?

eSupport.org.ua

05.12.2006, 19:31

Цитата(kosmohost.com @ 05.12.2006, 18:08)

Только как это к mod_php прикрутить?...

Как обычно - или учиться делать самому или заплатить тому кто умеет

kosmohost.com

05.12.2006, 20:01

Цитата(eSupport.org.ua @ 05.12.2006, 19:31)

Как обычно - или учиться делать самому или заплатить тому кто умеет

Не получится!

Если только писать какой-то модуль, который будет запускать mod_php из под обычного пользователя, как в случае с suexec или php-cgi. Или выход в Apache2.

Stas_

05.12.2006, 20:03

Цитата(eSupport.org.ua @ 05.12.2006, 19:31)

Как обычно - или учиться делать самому или заплатить тому кто умеет

eSupport.org.ua, ненавязчиво так услуги свои предлагаете?

Alexander V Fedyashov

05.12.2006, 20:14

А почему ненавяжчиво? Вполне понятный намек

ex-SavaHost

05.12.2006, 21:42

Цитата(edogs @ 05.12.2006, 16:08)

И если нагрузка месяц от месяца растет, то хостеру не вредно было бы сказать "а вот через месяц Вам придется или снижать нагрузку или съезжать."

А если этому хостеру невыгодно предупреждать заранее? Удобнее забрать деньги, а клиента выбросить вон.

eSupport.org.ua

05.12.2006, 21:45

Ну во-первых такой модуль есть, а во-вторых он ненужен - если простоставить лимиты

edogs

05.12.2006, 22:06

Цитата(SavaHost.com @ 05.12.2006, 21:42)

А если этому хостеру невыгодно предупреждать заранее? Удобнее забрать деньги, а клиента выбросить вон.

Дык, мы об этом и говорим, клиентам нужны и полезны эти спидометры. И кстати, если бы появился хостер который эти спидометры будет выдавать (не корявые), то нам почему-то кажется народ к нему потянется.
Вот посмотрите например http://www.mediatemple.net/webhosting/gs/ (мы не предлагаем обсуждать этого хостера, речь только о технологии и принципе организации). Хостер просто тупо предлагает платить за "реально скушанные ресурсы", рекламирует неотключение и масштабируемость в хороших масштабах. Будет ли такой хостинг дорог для грузящих сайтов - наверняка будет очень дорог, но для растущих сайтов с неопределёнными потребностями - ничего плохого не видим в таком подходе.

kosmohost.com

05.12.2006, 22:10

Цитата

Ну во-первых такой модуль есть, а во-вторых он ненужен - если простоставить лимиты smile.gif

Ну, так поделитесь названием модуля с общественностью, а то тут народ апач статус парсит, чтобы за mod_php следить.

eSupport.org.ua

06.12.2006, 09:41

Цитата(kosmohost.com @ 05.12.2006, 23:10)

В апаче есть встроенные директивы для управления лимитами по числу процессорного времени и памяти. Смысл что-то парсить если проще поставить разумный минимум и забыть о перегрузке?

kosmohost.com

06.12.2006, 11:18

Цитата(eSupport.org.ua @ 06.12.2006, 09:41)

Во-первых: эти лимиты не всегда срабатывают.
Во-вторых: на mod_php они не действуют, можете проверить.

eSupport.org.ua

06.12.2006, 21:39

Мои - срабатывают, можно не проверять

Я по мимо апачевых еще и системными добиваю

gylys

06.12.2006, 21:43

Нравиться иметь сообщение "Internal Server Error" ? Мне лично нет, так как эти записи пользователи трактует как 'левый сервер' и 'левая услуга'...

ultrasparc

07.12.2006, 00:26

Цитата(eSupport.org.ua @ 06.12.2006, 22:39)

Мои - срабатывают, можно не проверять

Я по мимо апачевых еще и системными добиваю

Может тогда поделитесь своими

или это коммерческая тайна?

eSupport.org.ua

07.12.2006, 01:53

Цитата(gylys @ 06.12.2006, 22:43)

Эти надписи можно заменить на "Превышение ресурсов"

Цитата(ultrasparc @ 07.12.2006, 01:26)

Может тогда поделитесь своими

или это коммерческая тайна?

Я уже писал на dedic.ru

kosmohost.com

07.12.2006, 02:16

Цитата(ultrasparc @ 07.12.2006, 00:26)

Может тогда поделитесь своими

или это коммерческая тайна?

Вот директивы:

Код

RLimitCPU директива

Синтаксис: RLimitCPU # или 'max' [# или 'max']
Значение по умолчанию: Возврат к исходному состоянию используя значения по умолчанию операционной системы
Контекст: конфигурация сервера, virtual host
Состояние: основное
Совместимость: RLimitCPU доступен только в Apache 1.2 и выше

Получает 1 или 2 параметра. 1-й параметр устанавливает ограничение ресурса программного обеспечения для всех процессов и 2-й параметр устанавливает максимальное ограничение ресурса. Любой параметр может быть числовой или "max", чтобы указать серверу, что ограничение должно быть установлено к максимуму, позволенному конфигурацией операционной системы. Подъем максимального ограничения ресурса требует, чтобы сервер выполнилась под root, или в начальной фазе запуска.

Ограничения ресурса ЦЕНТРАЛЬНОГО ПРОЦЕССОРА сказываются на процессе.

См. также RLimitMEM или RLimitNPROC.
RLimitMEM директива

Синтаксис: RLimitMEM # или 'max' [# или 'max']
Значение по умолчанию: Возврат к исходному состоянию используя значения по умолчанию операционной системы
Контекст: конфигурация сервера, virtual host
Состояние: основное
Совместимость: RLimitMEM доступен только в Apache 1.2 и выше

Получает 1 или 2 параметра. 1-й параметр устанавливает ограничение ресурса программного обеспечения для всех процессов и 2-й параметр устанавливает максимальное ограничение ресурса. Любой параметр может быть числовой, или max, чтобы указать серверу, что ограничение должно быть установлено к максимуму, допустимому конфигурацией операционной системы. Подъем максимального ограничения ресурса требует, чтобы сервер выполнился с полномочиями root, или в начальной фазе запуска.

Ограничения ресурса Памяти выражены в байтах на процесс.

См. также RLimitCPU или RLimitNPROC.
RLimitNPROC директива

Синтаксис: RLimitNPROC # или 'max' [# или 'max']
Значение по умолчанию: Возврат к исходному состоянию используя значения по умолчанию операционной системы
Контекст: конфигурация сервера, virtual host
Состояние: основное
Совместимость: RLimitNPROC доступен только в Apache 1.2 и выше

Получает 1 или 2 параметра. 1-й параметр устанавливает ограничение ресурса программного обеспечения для всех процессов и 2-й параметр устанавливает максимальное ограничение ресурса. Любой параметр может быть число, или max, чтобы указать серверу, что ограничение должно быть установлено к максимуму, допустимому конфигурацией операционной системы. Подъем максимального ограничения ресурса требует, чтобы сервер работал с root-полномочиями, или в начальной фазе запуска.

Управляет ограничением процессов числом процессов на пользователя.

Обратите внимание: Если CGI процессы выполняются под тем же userids что и сервер, эта директива будет ограничивать число процессов, которые сервер непосредственно может создавать. Доказательством этой ситуации будет cannot fork сообщения в error_log.

См. также RLimitMEM или RLimitCPU.

eSupport.org.ua, не надоело своей рекламой здесь все закидывать?...

eSupport.org.ua

07.12.2006, 10:26

Я не рекламирую ничего.
А директивы немного не те

Вот более другие (пример):

LIMITS(5) LIMITS(5)

NAME
limits - Resource limits definition

DESCRIPTION
The limits file (/etc/limits by default or LIMITS_FILE
defined config.h) describes the resource limits you wish
to impose. It should be owned by root and readable by
root account only.

By default no quotas are imposed on 'root'. In fact, there
is no way to impose limits via this procedure to root-
equiv accounts (accounts with UID 0).

Each line describes a limit for a user in the form:

user LIMITS_STRING

The LIMITS_STRING is a string of a concatenated list of
resource limits. Each limit consists of a letter identi-
fier followed by a numerical limit.
The valid identifiers are:

A: max address space (KB)
C: max core file size (KB)
D: max data size (KB)
F: maximum filesize (KB)
M: max locked-in-memory address space (KB)
N: max number of open files
R: max resident set size (KB)
S: max stack size (KB)
T: max CPU time (MIN)
U: max number of processes
K: file creation mask, set by umask(2).
L: max number of logins for this user
P: process priority, set by setpriority(2).

kosmohost.com

07.12.2006, 12:37

Это тоже самое, только RLimit в Apache вшиты.

rustelekom

07.12.2006, 19:00

limits - работает в окружении командной строки (перл к примеру или просто bash)
rlim* - работает в среде апача.

eSupport.org.ua

07.12.2006, 19:52

Цитата(kosmohost.com @ 07.12.2006, 13:37)

Это тоже самое, только RLimit в Apache вшиты.

limits работает на уровне ядра и влияет на любой процесс, изучайте матчасть.

kosmohost.com

07.12.2006, 23:49

Цитата(eSupport.org.ua @ 07.12.2006, 19:52)

limits работает на уровне ядра и влияет на любой процесс, изучайте матчасть.

Я, итак, ее знаю, применительно к апач говорил.

eSupport.org.ua

08.12.2006, 08:21

А кто тогда писал - "Во-вторых: на mod_php они не действуют, можете проверить." ?

kosmohost.com

08.12.2006, 12:26

Цитата(eSupport.org.ua @ 08.12.2006, 08:21)

А кто тогда писал - "Во-вторых: на mod_php они не действуют, можете проверить." ?

Если Keep-Alive включить, то точно Rlimit не действуют, процессы часами начинают висеть.

А на mod_php, mod_cgi и т.п. тоже действуют не всегда, иногда заметно, что процессы висят.

Это текстовая версия — только основной контент. Для просмотра полной версии этой страницы, пожалуйста, нажмите сюда.