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

В том числе,

1) кластерная организация хостинга - насколько понимаю, надо очень постараться, чтобы хостер был вынужден срочно отключать за перегрузку кластера - или все-так в рассматриваемой плоскости это не имеет значения

2) автоматически действующие ограничения, накладываемые на время испольнения скриптов и тп - насколько это эффективнно в рассматриваемом разрезе

3) самый интересный для меня вопрос - насколько понимаю, все-таки можно разделить сервер между аккаунтами виртуального хостинга, типа как между ВДС (кстати, делают ли так и где - например, в Русониксе не так сделано на хостинговых аккаунтах?) - в этом случае, по идее, клиент никому не должен помешать (хотя и он не сможет получить пиковой производителоьности за счет других аккаунтов)

Заранее благодарю знающих людей за высказанные мнения

P.S. Эта тема ни в коей мере не заменяет намечающегося голосования, предлагаемого edogs - надеюсь, они его сами откроют

Очень давно, когда Антон Нехороших еще работал в VH, а наша компания там держала сайт loi.ru, там была реализована система автоматического оповещения клиентов. Мне очень нравилась. При мудренных запросах к БД присылалось автоматическое извещение (какой скрипт, каким запросом пожирает ресурсы) с просьбой оптимизировать его или обратиться в службу поддержки за консультацией. Сейчас об этом не слышу, похоже, с уходом АН умерла и система.

Мне пока ещё не встречались примеры, когда кластерный хостинг или виртуальные серверы спасали от перегрузок.

Для PHP и MySQL объем памяти выделяем в пределах мощности сервера. Еще можно за превышение времени скрипт обрубать.

Интересно как такую систему организовать? Кто знает напишите в личку

Знает Антон, кроме него там некому было такую муть замутить, но боюсь, что готовое решение Вам вряд ли кто-то даст. Идею я Вам розболтал, дальше сами.

Кстати, у такой системы очень сильный психологический эффект. При каждом просмотре страницы - письмо. Триста посетителей - триста писем, обвиняющих в криворукости программиста. Любой клиент невольно будет через два дня готов к тому, что сайт погасят за перегрузку.

Антон, может всё же поделишься?

почему-то подумались... "серверу плохо от сайта, давайте добьем сервак мощной емыл рассылкой что бы не мучался":)

У VH в то время был уже далеко не один сервер . Почтой, подозреваю, был занят кто-то другой.

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

Как уже сказали выше, кластеризация существенно не поможет. Вообще использовать в хостинге кластеризацию, ориентированную на сбор большой мощности в одном месте - это только тешить самолюбие админов и давать им тратить время и деньги на пустое. Классическую отказоустойчивую кластеризацию делать - из пушки стрелять по воробьям. Перейти с отказоустойчивостью железа с трех девяток на семи девяток - за счет многократного удорожания, для дешевого шаред хостинга такая надежность совсем не нужна. Тем более, это решает вопрос с железом, но не решает вопрос с падением каналов аплинков. И тем еще более, что большой кластер без учета и разграничения ресурсов забьет под завязку несколько "убежавших" в цикл скриптов одного юзера. Можно использовать всякие фронтенд/бэкенд схемы, которые стоят уже у многих хостеров, но все-равно без учета и лимитов от перегрузок это тоже не спасет.

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

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

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

Результатами учета можно использовать для распределения ресурсов. Начиная от решения в лоб: превысил лимит - аккаунт заблокирован (может быть просто на некоторое время), до расстановки лимитов, приоритетов процессов и запросов на лету. Последнее, конечно, достигается ценой очень большого кол-ва доработок.

Лучший вариант, как водится, является компромисом между точность и стоимостью внедрения.

Проблема найти пару часов и написать самому, что ли?
Или сделать рунет зависимым от Антона единственный выход?

Люди, я не поверю чтобы ну максимум за 3-4 часа с учетом пересборки ядра и знаниями системы это было невозможно. Пишется ведь всего 1 скрипт который берет инпут с системных ресурсов либо через sa либо напрямую из /proc и дальше часть скрипта для реагирования тем или иным способом. Куда уж проще?

Mik-, зачем делать велосипед если он уже был изобретен?

Не только изобретен, но и сделан