Комментарии 27
Это конечно хорошо, но не лучше бы убрать SQLite и сделать отдельно часть, которая бы слушала UDP и складывала данные в БД, а вторая часть посылала бы от апача данные?
Что-то подобное используется в Badoo, но т.к. это было про php, поэтому слушал в полуха.
Что-то подобное используется в Badoo, но т.к. это было про php, поэтому слушал в полуха.
Не совсем понятен вопрос. Сейчас модуль так и работает — одна часть посылает данные от апач(только не через UDP, а через сокет) отдельному демону, который и пишет в БД. А вот какая база — здесь можно выбрать SQLite, MySQL, Postgresql или вообще в лог. Демон может коннектится к любой. Или что-то другое имеется ввиду? А если имеется ввиду посылка статистики по сети на какую-то отдельную машину, например централизированный сервер хранения статистики, так это в планах. Т.к. такая задача предусматривает множество подзадач типа шифрование пересылаемых данных, постановка запросов в очередь при перегрузке централизированного сервера и т.д. Это планируется на 0.3 веху. Не все же сразу. Пока локальная модель.
а почему просто не взять munin?
<режим паранойи>
mysql> create database perf;
mysql> CREATE USER 'perf'@'localhost' IDENTIFIED BY 'perf';
mysql> GRANT ALL PRIVILEGES ON perf.* TO 'perf'@'localhost' WITH GRANT OPTION;
</режим паранойи>
mysql> create database perf;
mysql> CREATE USER 'perf'@'localhost' IDENTIFIED BY 'perf';
mysql> GRANT ALL PRIVILEGES ON perf.* TO 'perf'@'localhost' WITH GRANT OPTION;
</режим паранойи>
IMHO 3-ий тест очень короткий по времени получился (меньше секунды), что бы оценить влияение модуля. Можно чуть-чуть больше запросов сделать, что бы было более реальное?
Я бы еще -k добавил (keep-alive) что бы ближе к реальному миру, но это, пожалуй, дело вкуса.
Я бы еще -k добавил (keep-alive) что бы ближе к реальному миру, но это, пожалуй, дело вкуса.
поставил на один сервер эту плюху, пока вроде все отлично =) Посмотрим что мунин скажет, на сколько оно больше стало чего хавать.
Такой вопрос, какие размеры SQLite Бд примерно получаются за время использования? ее иногда бы чистить =)
Такой вопрос, какие размеры SQLite Бд примерно получаются за время использования? ее иногда бы чистить =)
тесты никакие вообще, что такое сотня запросов?
оно на каждый запрос в базу/лог лезет или есть какой-то буфер?
оно на каждый запрос в базу/лог лезет или есть какой-то буфер?
Сохраняет в базу на каждый запрос. Буферизация — это дело самой базы данных. Буферизация запрасов — это на 0.3 веху, когда модуль по сети данные гонять начнет. А для локальной версии — смысла в этом не вижу. ИМХО база и сама неплохо с этим(буферизация) справится.
Немногочисленные тесты выложил лишь с одной целью — непосредственно на цифрах продемонстировать, что модуль на сам запрос фактически не влияет, т.к. в самом запросе кроме считывания CPU данных и посылки этой информации демону ничего не делает. Причем от mod_performanсe ожидается минимальное влияние на запрос, даже если демон по како-то причине не может принять данные. Вот другой вопрос сам демон — он может грузить систему, но исследование его деятельности я оставлю на следующую статью. К тому же я б был благодарен, если будут находится желающие потестирвать, к тому же для этих целей специально поднята система поддержки на сайте модуля. Если обнаружите баг или аномалии — пишите.
Немногочисленные тесты выложил лишь с одной целью — непосредственно на цифрах продемонстировать, что модуль на сам запрос фактически не влияет, т.к. в самом запросе кроме считывания CPU данных и посылки этой информации демону ничего не делает. Причем от mod_performanсe ожидается минимальное влияние на запрос, даже если демон по како-то причине не может принять данные. Вот другой вопрос сам демон — он может грузить систему, но исследование его деятельности я оставлю на следующую статью. К тому же я б был благодарен, если будут находится желающие потестирвать, к тому же для этих целей специально поднята система поддержки на сайте модуля. Если обнаружите баг или аномалии — пишите.
ну тогда этот модуль скорее зло, а не добро :)
я такое никогда в жизни не поставлю, чтобы на каждый запрос к серверу он мне еще и лишний раз в базу лазил. Вообще смысла особого в этой статистике не вижу, профайлить нужно приложение, а не смотреть сколько памяти сожрал воркер апача при том, что сожрать ее мог кто угодно и это скорее всего никак не взаимосвязано с конкретным запросом.
я такое никогда в жизни не поставлю, чтобы на каждый запрос к серверу он мне еще и лишний раз в базу лазил. Вообще смысла особого в этой статистике не вижу, профайлить нужно приложение, а не смотреть сколько памяти сожрал воркер апача при том, что сожрать ее мог кто угодно и это скорее всего никак не взаимосвязано с конкретным запросом.
Ну не стоит сразу ярлыки вешать. Давайте тогда его нейтральным назовем :). И никто не говорит «Ставьте обработку на все запросы!!!». Я вообще не рекомендую на обработку статического контента его настраивать. Потому как статика не приносит много проблем. ИМХО его будет полезно использовать для вычисления проблемного хоста или еще точнее скрипта. Я вижу тенденцию, что сейчас стала очень актуальна тема — лимитирование ресурсов отдельного сайта, а также мониторинг.
И я не говорю категоричного нет буферизации — если ее отсутсвтие в самом модуле окажется проблемным местом — допишу и ее. Проект-то развиается.
И я не говорю категоричного нет буферизации — если ее отсутсвтие в самом модуле окажется проблемным местом — допишу и ее. Проект-то развиается.
Да кто же статику на апач вешает? Я просто не вижу реальных юзкейсов для данного продукта.
Лет 10 или 11 назад, будучи студентом, я хотел устроиться в одно большую, по тогдашним меркам, контору и писал IDS модуль для java-фреймворка и тоже все писал в базу, вот тогда-то меня от этого и отучили :)
Лет 10 или 11 назад, будучи студентом, я хотел устроиться в одно большую, по тогдашним меркам, контору и писал IDS модуль для java-фреймворка и тоже все писал в базу, вот тогда-то меня от этого и отучили :)
Ну если статистика неинтересна, то никто силой не заставляет ее вешать.
Насчет БД — у каждой конторы свой подход к написанию ПО.
И опять же повторюсь — если отсутствие буфиризации окажется узким местом, то сделаю ее. Просто буферизация порождает другую проблему — увеличение использования памяти модулем(точнее демоном), этот вопрос нужно аккуратно решать.
Насчет БД — у каждой конторы свой подход к написанию ПО.
И опять же повторюсь — если отсутствие буфиризации окажется узким местом, то сделаю ее. Просто буферизация порождает другую проблему — увеличение использования памяти модулем(точнее демоном), этот вопрос нужно аккуратно решать.
I am use %CPU% — неверная форма
Модуль вроде полезный. Скажите, а есть более наглядные виды подачи результатов анализа для этого модуля? То, что показано в первой статье совершенно не наглядно. То есть к примеру чтобы просуммировались данные за день/неделю и показались скрипты отсортированные по cpu time.
К сожалению таких данных пока не могу выложить. Модуль стоит на нескольких моих продакшн-системах, но с них данных я публиковать не могу, разве что графики. Кстати постараюсь консолидировать накопленную информацию по модулю и следующей статьей выложить рекомендации по использованию и примеры использования, методы анализа, а также обновленный интерфейс и дополненный функционал.
Как указать скрипту, что постгрес висит на произвольном порту? Пробовал через PerformanceDBHost, не содаёт таблицы :(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Apache 2.x под наблюдением или как узнать еще больше