админы хостера - нам бы еще сервачок поставить .
фин директор - а нафига?
админы - там нагрузка уже большая, сайты клиентов будут медленно работать!
фин директор - так это у Васи 500 клиентов на таком сервере, каждый по 7$ - а у нас 450 и по 6 - непорядок !
админы - а мы что, мы сказали...
фин директор - надо что - то делать! Давайте выгоним тех кто грузит сервер?
саппорт - а мож не надо, они же не специально.
директор - а зарплату хотите вовремя ?, админам: передайте саппорту список из 10 им сайтов, кто больше всех грузит и молча отключаем на основании пункта 100.204.007 оферты - все равно проверить не смогут.
_________
через 5 мин
админы сапппорту - вот вам список
саппорт отключает по списку
___________-
через 10 мин
директор по маркетингу - А какого ляда, не грузится моя домашняя страничка, и сайт нашего хостинга!
саппорт - мда, сейчас включим ... а может еще вот этих 5- х они хорошие, давние, не обижают, и вот этого - это вообще сайт сотрудника. ...
админы, директора, пробегающий мимо бухгалтер - ну ладно, но больше никого из этих не включать!
фин директор - может цену на услуги повысить ..

P.S. новый хостинг уже найден

Было бы смешно, если бы не было так близко к жизни...

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

хорошо бы в cpanel эту информацию отображать...

Тогда появится объективный параметр оценки хостера... не, не пойдет на это никто.
Есть ещё один "+" момент в этом. Если четко известно что перегруз от 5% начинается, то ничто не помешает считывать этот параметр скриптом и часть запросов не пропускать при достижении нагрузки почти критической. Выводить банальное "подождите" и саморегулироваться так сказать.

А реально ли для этих целей переписать или дописать top?
Бредовая идея, конечно, но интересно...

В cpanel отображать это удел разработчиков панели, а вот в биллинге отображать все гораздо проще. Впринципе я думаю ничего сложного нет написать пару функции для запроса и вывода данной информации. Жаль у меня биллинг в зенде, а то можно было бы попробовать.
Спасибо за отличную идею, будем думать как ее реализовать.

top -u Serzer

Это если php как cgi... с модулем сложнее.
На самом деле можно парсить dcpumon в cpanel и выводить в биллинг допустим. Там будет и cpu и mem. Другое дело, что он не всегда правду показывает, зато хоть какая-то ориентировочная цифра будет. Разработчикам биллингов на заметку

А мы именно в Cpanel какое-то время это отображаем Среднесуточную по CPU за последние 10 суток, плюс уведомления на емайл - например если клиент поставит кривой модуль после чего подскочит нагрузка, клиент об этом узнает сразу, вместо того что бы потом гадать из-за чего его сайт грузит

P.S. Поскольку модуль работает в тестовом режиме, громких (официальных) заявлений пока не делали, просто запустили и собираем отзывы клиентов - в принципе клиенты новой возможностью довольны

P.P.S. Модуль писал собственноручно.

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

PS.
Подчеркнул, ибо нефиг. Сильно против бесплатного распространения. И так уже "нагрузка" стала инструментом шантажа на фоне пятикопеечных затрат на вхождение в бизнес хостинга. Пусть хоть на это тратятся. А у Вас будет какая-никакая компенсация затрат.

Мы будем с нетерпением ждать этого момента, так как вещь очень нужная.

На ProstoHost.ru нагрузку можно посмотреть через биллинг, панель, top или свой скрипт.

Вот это мои личные сайты:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28504 tanya 16 0 45384 12m 6500 S 2 0.3 0:01.29 php5
22069 tanya 16 0 45384 12m 6500 S 2 0.3 0:01.27 php5
18941 tanya 15 0 44864 15m 9620 S 0 0.4 0:00.09 php5
9406 tanya 15 0 44864 15m 9620 S 0 0.4 0:00.07 php5
12525 tanya 15 0 44884 15m 9620 S 0 0.4 0:00.04 php5
10476 tanya 25 0 45384 12m 6508 S 0 0.3 0:01.27 php5
4051 tanya 16 0 45384 12m 6500 S 0 0.3 0:01.20 php5
8115 tanya 15 0 45404 12m 6532 S 0 0.3 0:04.79 php5
29929 tanya 16 0 47132 14m 7012 S 0 0.4 0:04.93 php5

Девятая колонка - % от CPU а десятая - % от RAM.

Tanysha, в таком виде информация доступна любому Вашему клиенту шаред-хостинга?

Петр, я отписал Вам на емайл.



Так понял это вывод команды top (или ps aux)? т.е. вывод в реальном времени на момент выполнения команды?
Некоторые скрипты клиентов в top'е (или в результатах ps aux) могут показывать скажем 50% cpu в течение нескольких секунд, однако среднесуточная статистика клиента при этом не поднимается выше 2%CPU, т.е. глядя в top в течение какого-то времени можно заметить размеры "пиковых" нагрузок, но делать выводы о том, превышает ли сайт допустимые лимиты реально сложно.

P.S. Вывод команд top и ps aux обычно доступен всем клиентам имеющим доступ к SSH, а также всем клиентам имеющим доступ к cron.

WebXL, нагрузка от mysql тоже учитывается? Если да, то можно в 2 словах как, ведь в отличии от php который можно в cgi запуститЬ, mysql в нем не запустишь, а нагрузка как раз туда идет нередко. Или мы что-то не так понимаем?

Мне кажется, от учёта используемых ресурсов на общем хостинге пострадают сами потребители. Общий хостинг предназначен для сайтов - визиток, а не ресурсоёмких порталов. Я лично клиентам рекомендую количество хитов/посещений для конкретного плана. Если действительно нужен учёт, клиент всегда в праве переходить на VPS, где этот учёт ведётся грамотно.
Прикрутить к cpanel, это пустая трата ресурсов того же сервера. cPanel и так сама на себя жрёт много....

Да, если еще считать и логгировать нагрузку и от мускуля (допустим mytop), то боюсь, что сервер иногда ~40-50% процентов ресурсов будет отдавать учету того, что же он сам делает.
Есть вариант проще - не жадничать на железе и брать с запасом...

Это информация доступна всем клиентам. Ее можно получить через php или perl прямо на сайте.
Для итогового учета используется dcpumon от cpanel.

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

В модуле, о котором идет речь - нет, мускуль не показывает, только процент CPU от скриптов.


Ну, вероятно зависит от того, какой хостинг, как он организован и какова политика хостера.
Сайт-визитка - это ноль потребляемых ресурсов. Практически абсолютный ноль. Сайтов визиток можно разместить на сервере практически бесконечное количество (разумеется всему есть пределы, но тем не менее). Что же касается реалий - ну сравнение vds и shared это отдельная большая тема, в обоих вариантах есть как свои преимущества, так и свои недостатки.


Опять же, зависит от того как и куда прикрутить


Согласен. Но тут тоже нужна середина - не жадничать на железе, означает подорожание себестоимости хостинга, а как результат увеличение итоговой стоимости. Бывают же клиенты, которые за 8$ хотят чтобы без лишних телодвижений с их стороны хостился сайт, съедающий до 30% CPU (четырехядерный Dual Xeon 3.0 надо заметить) среднесуточно. И совершенно не понимают почему к ним лезут с какими-то дурацкими рекомендациями, тычут какими-то непонятными логами... И возмущаются что мол они много платят, а их еще беспокоят. И я сейчас без всякого негатива описываю ситуацию, наоборот, даже с полуулыбкой, вспоминая недавние "переговоры" с клиенткой
В последнем случае, после того как доходчиво объяснили клиентке что такое сервер, сколько он стоит и сколько сайтов на него надо вместить, что бы хотя бы окупить стоимость аренды, клиентка решила прислушаться к рекомендациям и совместными усилиями выяснили, что на сайте есть функция кеширования, которая в разы снизила нагрузки

В общем, если не пытаться выжать из бедного сервера все до капли и еще чуть-чуть, то проще от этого всем
Что же касается модуля который в Cpanel отображает среднесуточные нагрузки - ценность его конечна спорна, но вероятно она все же есть. Практические примеры:
У человека несколько заданий по крону, работающие таким образом:
GET http://адрессайта/скрипт > /dev/null
Запускаются ежеминутно.

Причем запускаемые скрипты на другом сервере. И не поверите вот - эти несложные задачки крона, в среднем создавали очень немаленькое значение по среднесуточным нагрузкам.
А теперь самое интересное:
Написали такой вот скрипт:

а в кроне прописали
/usr/bin/php /home/юзер/скрипт > /dev/null
И модуль показал, что нагрузка снизилась в пять раз
Не верится? Проверьте Хотя бы яндекс на одном аккаунте открываейте кроном через GET, а на втором аккаунте кроном чере php-скрипт

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

Пока-что, этому модулю не хватает возможности обсчитывать пиковые нагрузки. А так же оптимально тяжелые запросы к мускулу (но это уже на грани фантастики). Обсчитывать нагрузки в пике - это процесс уже сам по себе ресурсоемкий. Когда подпрыгивает LA, весьма редко бывает так, что бы нагруз создавал один процесс - чаще это множество небольших процессов в совокупности, а иногда тяжелый запрос к мускулю (есть у нас пара phpBB у которых таблицы по 300мб) и т.п.
Хотя.., и в этом направлении работаем, скоро тестировать буду

P.S. А вообще моя мечта - это сделать модуль, который скажет клиенту какой именно скрипт создает нагрузку и надо сказать что на самом деле, это не так уж не реально

А теоретическое обоснование сможете привести?

Не могу - вдруг глупость ляпну Просто попробуйте и убедитесь сами

Мы и так на слово верим. Нам теоретическое обоснование любопытно было бы узнать.

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

Команда GET выполняет следующие действия:

1. открывает соединение и запрашивает указанный файл
2. считывает вывод (контент) файла полностью (причем процесс висит пока не будет загружено все содержимое)
3. закрывает соединение
4. выводит полученный контант

PHP скрипт делает следующее:

1. открывает соединение (fopen).
2. закрывает соединение (fclose).

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

Вот если по поводу пункта "а" моя мысль подтвердится (все руки не дойдут проверить) то тогда понятно откуда берется средняя нагрузка - процесс php-скрипта будет висеть гораздо меньше.

И есть еще одно. Если наблюдать за процессами, то можно заметить, что команда GET, запускаемая в кроне фактически выполняется перлом, выглядит это примерно так:
perl опции GET адрес

Учитывая вышеприведенные рассуждения, можно делать выводы. Все только домыслы конечно

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

Уже давно основная составляющая цены на услугу хостинга, это человеческие ресурсы. Железо само по себе стоит копейки. Если заниматся изобретением велосипеда для того, чтобы якобы выгодно было за 8 доларов держать клиента, который съедает около 30% CPU, то мне кажется сперва искать безплатную раб силу. Но чем дальше, тем меньше люди желают работать по идейным соображениям Если и держать такого клиента, то только для партнёрства. То есть, как бы рекламные вложения.

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

Спасибо, интересно.
То что fopen/fclose не считывает по крайней мере весь файл это мы уверены в достаточной степени. Насколько мы поняли основной смысл сводится к тому, что нагрузка идет от того, что процесс долго висит? А не от того что он кушает много ресурсов? Или то и другое вместе?
Раз так, то нельзя ли потребление ресурсов списать на вызов пёрл, особенно если пхп с которым он сравнивается на сервере установлен как модуль?

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

Отсюда кстати ещё вопрос. Насколько цифирки потребляемого процессора зависят от загрузки сервера? Т.е. допустим нам разрешено 5% и мы их потребляли, сервер был полупустой... а потом нагнали людей на сервер по полной, во что превратятся наши 5%?

Петр, попробую разьяснить на примере, к хостингу большого отношения не имеющему.
В транспорте появилось такое понятие и вид деятельности, как логистика. За счет оптимизации схемы перевозок, использования возможности консолидации грузов, совмещения перевозок и оптимизации загрузок на основе совместного планирования, компьютеризованного учета и использования... ну и так далее.
Есть другое понятие, вроде бы к первому (логистике) отношения не имеющее - reputable company. Перевод наверное не нужен?
Так вот - одна и та же компания с трудом может быть логистической (простите за словестный оборот) и "reputable".
Ибо первая оптимизирует расходы, складирует товары, пока не подвернётся попутный рейс, поверх бочек грузит коробки (экономия!) и т.д.
Вторая же (reputable) просто берёт дороже (она же reputable) и везёт.
Логистика приносит большие обороты (и прибыль тоже), эти компании перевозят миллионы пар обуви, продукты, одежну, станки и т.д..
Но когда надо из пункта А в пункт Б перевести двигатель самолёта стоимостью 4-5 млн. звонят догадайтесь куда?

Так наверное и в хостинге - можно по крону каждые 3 мин считать нагрузку, а можно не впихивать просто клиентов как сельдь. И если через 3 года какому то клиенту всё же придётся сказать, что у него "перебор" и надо доплатить - вопросы и возражения вряд ли последуют...

P.S. А скрипт (когда он научится хорошо считать) сам приобрету с удовольствием - чтобы было что людям показать и самому посмотреть.

Если пики у 20и клиентов не совпадут - то всё останется как есть. Но с увеличением числа клиентов вероятность такого совпадения растёт.

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


Факт - такого клиента держать не выгодно. А вот что в этой ситуации делать - это и есть "организация процесса".



Вы правильно поняли - здесь ведь речь идет именно о средней статистике за сутки. Вот запустился у кого-то скрипт на 0,5 секунды с нагрузкой 15% CPU, но работал он всего пол секунды, за сутки он запустился N раз и если усреднить все его запуски и разделить на сутки, средний показатель будет гораздо ниже 15% (он будет зависить от трех параметров - %CPU, частота и продолжительность запусков).
А запускаемые процессы GET в моем примере показывали значение 5%CPU, но висели по 2-4 секунды. Пиковая нагрузка ниже, а вот средний показатель увеличивается в разы.
Таким образом получается, что ресурсов сам по себе аккаунт потребляет не много, заметных нагрузок нет (да и откуда они возмуться), но средние показатели варьировались от 1 до 2 %СPU, а после перевода на PHP упали до 0,2-0,3 %CPU.

В общем полагаю, что это работает примерно так.

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

P.S. Это все копейки конечно.., но если взять для примера хостингового гиганта с десятками тысяч клиентов, представить что 30% (ну к примеру 3000) клиентов используют запуск по крону с помощью GET и пересчитать, сколько ресурсов можно было бы сэкономить - то вместо
3000*1,5%=4500% (прибл 45 серверов)
получаем
3000*0,3%=900% (прибл 9 серверов)
экономия на стоимости размещения прибл (45-9) = 36 серверов.

Это все утрировано конечно, в жизни далеко не все так сладко, но тем не менее, вот Вам и копейки



Возможно, потому я и отметил свое наблюдение, что GET вызывается фактически перловым процессом.



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

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


Дмитрий, а вот то, что Вы описали, если не ошибаюсь, именно "Английская" модель бизнеса Ну как есть "бизнесс по русски", а есть вот "бизнесс по английски" :~)

В админ панели нашего биллинга уже есть:
Общая нагрузка от аккаунта в DA, которая сопоставляется с тарифом.

Можно посмотреть:
Логи 30 пиков по Apache.
Логи 30 пиков по MySQL.
Логи 30 пиков по процессам, отличным от apache и mysql.

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

На данном этапе роста компании включать эту систему считаем не совсем правильным шагом, экономичней докупать оборудование, поэтому большинство клиентов не знают о том, что используют больше, чем отведено тарифом.

Посчитаем сколько человеческих ресурсов потратим на обучение клиентов что надо именно так, а не так как они привыкли Эти 36 серверов обойдётся дешевле



Смысл заданного вопроса был в том, на сколько отличается потребление ресурсов тем же скриптом при свободном сервере, от того, если сервер нагружен. Ответ - в несколько раз, а возможно несколько десятков раз тот же скрипт будет выполнятся медленее, естественно будет жрать больше ресурсов. Парадоксально, но резвость работы сервера зависит даже от того, на сколько загружен канал связи....
То есть, чем больше нагрузка сервера, тем больше будет показывать нагрузку скрипта. Автоматика может только тупо считать обращения к процесору и на то, сколько есть памяти, IO, сети конкретный скрипт и тупо отрубать если скажем клиент превысил разрешимое значение на единицу.... На такое распределение ресурсов и существует виртуализация....

Говоря человеческим языком, такие распределения ресурсов должны делатся на уровне ядра....

А если вычесть отсюда то время которое ТП тратит на объяснение почему нагрузка выше нормы без отсутствия показателей на которые можно сослаться.

Да, Дмитрий, я это отлично понимаю. Более того, готов съесть свою шляпу, если ошибаюсь, но думаю, что как раз у "reputable"-хостеров этот инструмент и появится в первую очередь. У тех, кто не запихивает клиентов, как килек в банку, и на кого мы никогда не видели жалоб об отключении за "перегрузку". Ведь вопрос-то не технический, а политический, если можно так выразиться. Думаю, Вы понимаете, о чем я говорю. Тот же, WebXL - яркое подтверждение... Ему-то это зачем было нужно?

Так я не спорю - я обязательно куплю скрипт.
Хотя мне он и не совсем нужен.
А Виктору предлагаю встроить фичу - скрипт продавать только с регистрацией на емайл тех.руководства хостингов и при продолжительном LA>3 по крону отсылать "Просьба срочно расширить парк серверов. Доброжелатель..."

Ага, что бы добить почтовой очередью У нас кстати на сервере где основные сайты LA ниже 15 опускается только если момент сразу после перезагрузки поймать.
А вообще, согласимся с одним из уже выступавших ораторов. Если обвесить вирт.хостинг всякими дорогими мониторами, разгрузить сервера от клиентов и т.д. и т.п., то цена вирт.хостинга вырастет до цены вдс. И кому нужен будет такой вирт.хостинг? Почему-то у нас стало появлятся ощущение, что все эти приблуды к вирт.хостингу это как тюнинг оки. Дороже становится, по параметрам становится лучше, но камазом не станет.

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

А кто бы спорил. Только тогда пусть уберут из своих правил отключение за перегрузку сервера скриптами и перестанут отключать. И не надо мне высылать в подтверждение какие-то там логи, я только вчера ХТМЛ с помощью родителей еле освоил... Вот так вот. Это к вопросу, а нужно ли обвешивать. Извините за невольный каламбур, но если меня обвиняют в том, что я себе "перевесил", то очень хочется видеть те весы.

Вся нужная статистика для клиента есть уже в привычных инструментах, которые входят в комплект практически любой панели. Это Webalizer и Phpmyadmin. Ещё есть Java которая кушает ресурсы, но это пока довольно редкие случаи. Пробование объяснить клиентам что и как, обычно приводит к тому, что мол "у меня на другом хостинге всё работало и ни кто не жаловался"....
А в Webalizer и Phpmyadmin есть вся нужная информация для нормирования типичного хостинга. Дальше идёт Crontab, но его тоже не сложно нормировать. Но я лично не вижу смысла продавать ведро песка, и делать учёт по одной составляющей. Песок то по объёму покупаем - кубами и к стати никому в голову не приходит посчитывать поштучно...
К стати, мне кажется prohosting.com одни из первых лет пять шесть тому назад ввели в оборот посчёт http хитов, обращений к mysql и так далее. В результате потом отказались и оставили понятие 500 000 http hit как разумный предел для общего хостинга. Из своей же практики, я уже пришёл к похожему выводу.
Дальше каждый хостёр своей политикой распределения ресурсов делает своё лицо. У одного сайты крутятся нормально почти всегда, у другого почти всегда тормозит. Неговорю про статистический аптайм сервисов...
Лично я придерживаюсь того мнения, что лучше ресурсы отдавать клиентам, а нетратить на посчёт и лимиты....



Отключать не надо, выставил лимиты для конкретного пользователя и столько то делов. Хотя для Российских хостёров хуже, так как они почти все дают безлимитный трафик. Но с другой стороны, у многих сильно обрезан Apache, при том, для всех планов одинакого

Забыл об этом топике.
О топе:
Имел в виду сделать из топа демон (ведь это демоном называется? ), который бы при достижении нагрузки больше какого-то предела бы делал алерт, а не парсить топ сторонним скриптом.

В нашем случае top не парсится.А вот алерты есть



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



Есть запас?


Ока или камаз?




Верхний - это лидирующий по потреблению ресурсов клиентский аккаунт.
Второй - это аккаунт на котором обсчитывается статистика (тот самый модуль). Не велика растрата, при правильном подходе, верно?

И к слову о "грузящих приблудах".
Одна "приблуда" разгружает МТА. Вторая вот показывает клиентам их %CPU. Третья.. четвертая... ну да ладно - нагрузка видна в топе выше (ну она бывает прыгает конечно, кудаже без этого )
Я собственно к чему - сервер не пустой

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

К слову о дискусии по вопросу нужности и возможности посмотреть нагрузку на сайт.
Искали тут хостинг для проблемного сайта ( хитов не много, но скрипты и БД тяжелые).
Взяли тестовый у Четырех известных провайдеров, ответ одного из них ( без упоминания кто это )
"
У нас нету такого понятия, как пиковая
нагрузка. Сейчас ваш сайт не нагружает
сервер. Если он будет очень сильно
нагружать сервер и это отразится на других
клиентах, то мы вам сообщим.
"
это не Вася Пупкин с рессерством, это известных хостинг.

лишь один, после написания прямого письма большому начальнику сказал "сейчас на пределе, лучше Вам, если не можете оптимизировать - VPS" - насколько понимаю специально что - т водружали на серер для этих замеров.
еще два посоветовали перечитать сколько "попугаев" я имею право съесть за определенный отрезок времени

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