Собствено вот о чем я говорю http://www.freebsd.org/doc/ru/books/handbo...accounting.html
Кто пользуется? Есть ли другие методы учета CPU у пользователей, просто меня испугало что этот метод будет жрать очень много места на диске

Я пользуюсь
Места не жрет

Никаких проблем с ним нет.
Я распарсиваю файл раз в 15 минут. За это время на достаточно высоконагруженном сервере набирается около 1.5-2.5 мегабайт.
Только два обидных "но" - он никак не считает MySQL, и для подсчета требуется, чтобы php выполнялся от имени пользователя.

ясно вобщем фигня походу. А других способов нет?

Видеозаписи с XII ФОрума Хостинг-Провайдеров
Немного сумбурно, но как бы я считаю таки неплохой обзор.

Есть другой вариант
Не перегружать сервак сайтами
А в случае проблема просить админа найти кто грузит и решить с клиентом все полюбовно

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

Ну так становитесь сами сисадмином, или бросайте это дело, раз оно такое невыгодное

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

Вот так выглядят обработанные результаты

Как видно, "тяжелые" пользователи выявляются без проблем. И при этом необязательно знать, сколько ресурсов mysql каждый пользователь ест, так как косвенно это показывает статистика (обращение к mysql идут через php или другие скрипты, которые в статистике подсчитаны). А я полагаю, что основная задача подсчета статистики - выявлять процентное соотношение использования пользователем ресурсов сервера, а не просто любопытство, сколько он скушал mysql. Именно поэтому sa можно назвать идеальным способом для аккаунтинга.

Никакого жрания ресурсов в результате подсчета нет.
Что не нравится?

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

Ну а универсальной кнопки седлайте мне за№бись еще не изобрели...

Ошибочный путь, имхо.

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

Гиг в час. Парсинг. Опять гиг в час.
А что делать ?

Кстати, прямой корреляции между PHP и mySQL нэту. Проверено эмпирически.
И жаль что нету.

Если в этом фале больше 50 строчек в сутки то 2 варианта - выпрямлять руки или в магазин за новым сервером.

Если у вас стоит slow_query_time=60s - таки да.

А если нет - запросы очень разные бывают. В том числе и такие, которые даже на незагруженном сервере выполняются за ощутимое время. У меня был запросик, который и на абсолютно пустой машине выполнялся 3 минуты. А запрос-то в сущности простой - 3 миллиона записей, 1.5Gb данных, select из 2х таблиц + сортировка.

Да и у обычных CMS есть "тяжелые" запросы, вроде пересчета статистики или массового обновления данных. А какие из этого вырастают логи написали двумя постами выше.

Упс.
Проглядел, что речь идёт только о "slow_query_log".
Его действительно парсить можно вообще раз в месяц.

посмотрите доклад который выложили немного выше.

Это чревато отстрелом всех при возрастании загрузки CPU до значений близких к 100%. Поскольку медленными тогда станут все запросы.
Я считаю, что MySQL не нужно ограничивать. Мониторить можно и, в случае нахождения "тяжелого" клиента, предлагать ему перейти на VPS, а ограничивать не стоит.


А я думал мы про шаред-хостинг говорим

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

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

mod_php = rlimit в apache

ПХП как модуль и хостинг понятия несовместимые. Это как групповой секс без презерватива

Лолшто? А как надо? CGI? php-fpm?
Просто надо уметь его готовить.

Ну, Максим, Вы загнули!

Смотря кто организатор групповухи. Так и в хостинге

Два стандартных решения меня полностью удовлетворяют ЦГИ и фаст ЦГИ. Другие солюшены не побывал если честно.

А мне казалось, что php в режиме cgi даёт некислый прирост прожорливости, что явно не гуд.

А в режиме fastcgi экономит память